pytorch-cn
diff --git a/‎.gitignore
Lines changed: 2 additions & 0 deletions b/‎.gitignore
Lines changed: 2 additions & 0 deletions
diff --git a/‎_config.yml
Lines changed: 12 additions & 2 deletions b/‎_config.yml
Lines changed: 12 additions & 2 deletions
diff --git a/‎_data/wizard.yml
Lines changed: 187 additions & 113 deletions b/‎_data/wizard.yml
Lines changed: 187 additions & 113 deletions
diff --git a/‎_includes/primary-nav.html
Lines changed: 1 addition & 1 deletion b/‎_includes/primary-nav.html
Lines changed: 1 addition & 1 deletion
diff --git a/‎_layouts/post.html
Lines changed: 1 addition & 0 deletions b/‎_layouts/post.html
Lines changed: 1 addition & 0 deletions
diff --git a/‎docs/tensors.html renamed to ‎_layouts/redirect.html
Lines changed: 3 additions & 3 deletions b/‎docs/tensors.html renamed to ‎_layouts/redirect.html
Lines changed: 3 additions & 3 deletions
diff --git a/‎_posts/2017-5-11-Internals.md
Lines changed: 29 additions & 24 deletions b/‎_posts/2017-5-11-Internals.md
Lines changed: 29 additions & 24 deletions
@@ -0,0 +1,2 @@
+_site/
+Gemfile.lock
@@ -9,11 +9,10 @@ sass:
     sass_dir: _sass # default
     style: compressed
 safe: true
-highlighter: rouge
-markdown: kramdown
 future: true
 include:
     - _static
+    - _images
     - _modules
     - _sources
     - _tensor_str.html
@@ -30,3 +29,14 @@ exclude:
 
 plugins:
   - jekyll-feed
+
+highlighter: rouge
+markdown: kramdown
+kramdown:
+    # Use GitHub flavored markdown, including triple backtick fenced code blocks
+    input: GFM
+    # Jekyll 3 and GitHub Pages now only support rouge for syntax highlighting
+    syntax_highlighter: rouge
+    syntax_highlighter_opts:
+        # Use existing pygments syntax highlighting css
+        css_class: 'highlight'
@@ -4,4 +4,4 @@
     <li><a {% if page.id == 'blog' %}class="active"{% endif %} href="/blog/">博客</a></li>
     <li><a {% if page.id == 'support' %}class="active"{% endif %} href="/support/">支持</a></li>
     <li><a {% if page.id == 'apps' %}class="active"{% endif %} href="http://bbs.pytorch.cn">论坛</a></li>
-</ul>
+/ul>
@@ -11,6 +11,7 @@
         integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" 
         crossorigin="anonymous">
     <link rel="stylesheet" href="/static/css/main.css">
+    <link rel="stylesheet" href="/static/css/jekyll-github.css">
 </head>
 <body id="{{ page.id }}">
 
 
@@ -2,14 +2,14 @@
 <html lang="en-US">
   <head>
     <meta charset="UTF-8">
-    <meta http-equiv="refresh" content="1; url=master/tensors.html">
+    <meta http-equiv="refresh" content="1; url={{ page.redirect_url }}">
     <script type="text/javascript">
-      window.location.href = "master/tensors.html"
+      window.location.href = "{{ page.redirect_url }}"
     </script>
     <title>Page Redirection</title>
   </head>
   <body>
-    If you are not redirected automatically, follow this <a href='master/tensors.html'>link to the latest documentation</a>.
+    If you are not redirected automatically, follow this <a href='{{ page.redirect_url }}'>link to the latest documentation</a>.
     <br />
     If you want to view documentation for a particular version, follow this <a href='versions.html'>link</a>.
   </body>
 
@@ -56,7 +56,7 @@ typedef struct {
 The `PyObject_HEAD` is a macro that brings in the code that implements an object's reference counting, and a pointer to the corresponding type object. So in this case, to implement a float, the only other "state" needed is the floating point value itself.
 
 Now, let's see the struct for our `THPTensor` type:
-```
+```cpp
 struct THPTensor {
     PyObject_HEAD
     THTensor *cdata;
@@ -65,7 +65,7 @@ struct THPTensor {
 Pretty simple, right? We are just wrapping the underlying `TH` tensor by storing a pointer to it.
 
 The key part is defining the "type object" for a new type. An example definition of a type object for our Python float takes the form:
-```
+```cpp
 static PyTypeObject py_FloatType = {
     PyVarObject_HEAD_INIT(NULL, 0)
     "py.FloatObject",          /* tp_name */
@@ -97,16 +97,16 @@ The type object for our `THPTensor` is `THPTensorType`, defined in `csrc/generic
 
 As an example, let's take a look at the `tp_new` function we set in the `PyTypeObject`:
 
-```
+```cpp
 PyTypeObject THPTensorType = {
   PyVarObject_HEAD_INIT(NULL, 0)
   ...
   THPTensor_(pynew), /* tp_new */
 };
 ```
-The `tp_new` function enables object creation. It is responsible for creating (as opposed to initializing) objects of that type and is equivalent to the `__new()__` method at the Python level. The C implementation is a static method that is passed the type being instantiated and any arguments, and returns a newly created object.
+The `tp_new` function enables object creation. It is responsible for creating (as opposed to initializing) objects of that type and is equivalent to the `__new__()` method at the Python level. The C implementation is a static method that is passed the type being instantiated and any arguments, and returns a newly created object.
 
-```
+```cpp
 static PyObject * THPTensor_(pynew)(PyTypeObject *type, PyObject *args, PyObject *kwargs)
 {
   HANDLE_TH_ERRORS
@@ -117,7 +117,7 @@ static PyObject * THPTensor_(pynew)(PyTypeObject *type, PyObject *args, PyObject
 ```
 The first thing our new function does is allocate the `THPTensor`. It then runs through a series of initializations based off of the args passed to the function. For example, when creating a `THPTensor` *x* from another `THPTensor` *y*, we set the newly created `THPTensor`'s `cdata` field to be the result of calling `THTensor_(newWithTensor)` with the *y*'s underlying `TH` Tensor as an argument. Similar constructors exist for sizes, storages, NumPy arrays, and sequences.
 
-** Note that we solely use `tp_new`, and not a combination of `tp_new` and `tp_init` (which corresponds to the `__init()__` function).
+** Note that we solely use `tp_new`, and not a combination of `tp_new` and `tp_init` (which corresponds to the `__init__()` function).
 
 The other important thing defined in Tensor.cpp is how indexing works. PyTorch Tensors support Python's **Mapping Protocol**. This allows us to do things like:
 ```python
@@ -136,7 +136,7 @@ The most important methods are `THPTensor_(getValue)` and `THPTensor_(setValue)`
 ---
 
 We could spend a ton of time exploring various aspects of the `THPTensor` and how it relates to defining a new Python object. But we still need to see how the `THPTensor_(init)()` function is translated to the `THPIntTensor_init()` we used in our module initialization. How do we take our `Tensor.cpp` file that defines a "generic" Tensor and use it to generate Python objects for all the permutations of types? To put it another way, `Tensor.cpp` is littered with lines of code like:
-```
+```cpp
 return THPTensor_(New)(THTensor_(new)(LIBRARY_STATE_NOARGS));
 ```
 This illustrates both cases we need to make type-specific:
@@ -149,15 +149,15 @@ In other words, for all supported Tensor types, we need to "generate" source cod
 One component building an Extension module using Setuptools is to list the source files involved in the compilation. However, our `csrc/generic/Tensor.cpp` file is not listed! So how does the code in this file end up being a part of the end product?
 
 Recall that we are calling the `THPTensor*` functions (such as `init`) from the directory above `generic`. If we take a look in this directory, there is another file `Tensor.cpp` defined. The last line of this file is important:
-```
+```cpp
 //generic_include TH torch/csrc/generic/Tensor.cpp
 ```
 Note that this `Tensor.cpp` file is included in `setup.py`, but it is wrapped in a call to a Python helper function called `split_types`. This function takes as input a file, and looks for the "//generic_include" string in the file contents. If it is found, it generates a new output file for each Tensor type, with the following changes:
 
 - The output file is renamed to `Tensor<Type>.cpp`
 - The output file is slightly modified as follows:
 
-```
+```cpp
 # Before:
 //generic_include TH torch/csrc/generic/Tensor.cpp
 
@@ -166,7 +166,8 @@ Note that this `Tensor.cpp` file is included in `setup.py`, but it is wrapped in
 #include "TH/THGenerate<Type>Type.h"
 ```
 Including the header file on the second line has the side effect of including the source code in `Tensor.cpp` with some additional context defined. Let's take a look at one of the headers:
-```
+
+```cpp
 #ifndef TH_GENERIC_FILE
 #error "You must define TH_GENERIC_FILE before including THGenerateFloatType.h"
 #endif
@@ -192,21 +193,22 @@ Including the header file on the second line has the side effect of including th
 #undef TH_GENERIC_FILE
 #endif
 ```
+
 What this is doing is bringing in the code from the generic `Tensor.cpp` file and surrounding it with the following macro definitions. For example, we define real as a float, so any code in the generic Tensor implementation that refers to something as a real will have that real replaced with a float. In the corresponding file `THGenerateIntType.h`, the same macro would replace `real` with `int`. 
 
 These output files are returned from `split_types` and added to the list of source files, so we can see how the `.cpp` code for different types is created.
 
-There are a few things to note here: First, the `split_types` function is not strictly necessary. We could wrap the code in `Tensor.cpp` in a single file, repeating it for each type. The reason we split the code into separate files is to speed up compilation. Second, what we mean when we talk about the type replacement (e.g. replace real with a float) is that the C preprocessor will perform these subsitutions during compilaiton. Merely surrounding the source code with these macros has no side effects until preprocessing. 
+There are a few things to note here: First, the `split_types` function is not strictly necessary. We could wrap the code in `Tensor.cpp` in a single file, repeating it for each type. The reason we split the code into separate files is to speed up compilation. Second, what we mean when we talk about the type replacement (e.g. replace real with a float) is that the C preprocessor will perform these substitutions during compilation. Merely surrounding the source code with these macros has no side effects until preprocessing. 
 
 ### Generic Builds (Part Two)
 ---
 
 Now that we have source files for all the Tensor types, we need to consider how the corresponding header declarations are created, and also how the conversions from `THTensor_(method)` and `THPTensor_(method)` to `TH<Type>Tensor_method` and `THP<Type>Tensor_method` work. For example, `csrc/generic/Tensor.h` has declarations like:
-```
+```cpp
 THP_API PyObject * THPTensor_(New)(THTensor *ptr);
 ```
 We use the same strategy for generating code in the source files for the headers. In `csrc/Tensor.h`, we do the following:
-```
+```cpp
 #include "generic/Tensor.h"
 #include <TH/THGenerateAllTypes.h>
 
@@ -216,26 +218,28 @@ We use the same strategy for generating code in the source files for the headers
 This has the same effect, where we draw in the code from the generic header, wrapped with the same macro definitions, for each type. The only difference is that the resulting code is contained all within the same header file, as opposed to being split into multiple source files.
 
 Lastly, we need to consider how we "convert" or "substitute" the function types. If we look in the same header file, we see a bunch of `#define` statements, including:
-```
+```cpp
 #define THPTensor_(NAME)            TH_CONCAT_4(THP,Real,Tensor_,NAME)
 ```
 This macro says that any string in the source code matching the format `THPTensor_(NAME)` should be replaced with `THPRealTensor_NAME`, where Real is derived from whatever the symbol Real is `#define`'d to be at the time. Because our header code and source code is surrounded by macro definitions for all the types as seen above, after the preprocessor has run, the resulting code is what we would expect. The code in the `TH` library defines the same macro for `THTensor_(NAME)`, supporting the translation of those functions as well. In this way, we end up with header and source files with specialized code.
-####Module Objects and Type Methods
+
+#### Module Objects and Type Methods
+
 Now we have seen how we have wrapped `TH`'s Tensor definition in `THP`, and generated THP methods such as `THPFloatTensor_init(...)`. Now we can explore what the above code actually does in terms of the module we are creating. The key line in `THPTensor_(init)` is:
-```
+```cpp
 # THPTensorBaseStr, THPTensorType are also macros that are specific 
 # to each type
 PyModule_AddObject(module, THPTensorBaseStr, (PyObject *)&THPTensorType);
 ```
 This function registers our Tensor objects to the extension module, so we can use THPFloatTensor, THPIntTensor, etc. in our Python code.
 
 Just being able to create Tensors isn't very useful - we need to be able to call all the methods that `TH` defines. A simple example shows calling the in-place `zero_` method on a Tensor.
-```
+```python
 x = torch.FloatTensor(10)
 x.zero_()
 ```
 Let's start by seeing how we add methods to newly defined types. One of the fields in the "type object" is `tp_methods`. This field holds an array of method definitions (`PyMethodDef`s) and is used to associate methods (and their underlying C/C++ implementations) with a type. Suppose we wanted to define a new method on our `PyFloatObject` that replaces the value. We could implement this as follows:
-```
+```cpp
 static PyObject * replace(PyFloatObject *self, PyObject *args) {
 	double val;
 	if (!PyArg_ParseTuple(args, "d", &val))
@@ -245,12 +249,12 @@ static PyObject * replace(PyFloatObject *self, PyObject *args) {
 }
 ```
 This is equivalent to the Python method:
-```
+```python
 def replace(self, val):
-	self.ob_fval = fal
+	self.ob_fval = val
 ```
 It is instructive to read more about how defining methods works in CPython. In general, methods take as the first parameter the instance of the object, and optionally parameters for the positional arguments and keyword arguments. This static function is registered as a method on our float:
-```
+```cpp
 static PyMethodDef float_methods[] = {
 	{"replace", (PyCFunction)replace, METH_VARARGS,
 	"replace the value in the float"
@@ -261,9 +265,10 @@ static PyMethodDef float_methods[] = {
 This registers a method called replace, which is implemented by the C function of the same name. The `METH_VARARGS` flag indicates that the method takes a tuple of arguments representing all the arguments to the function. This array is set to the `tp_methods` field of the type object, and then we can use the `replace` method on objects of that type.
 
 We would like to be able to call all of the methods for `TH` tensors on our `THP` tensor equivalents. However, writing wrappers for all of the `TH` methods would be time-consuming and error prone. We need a better way to do this.
+
 ### PyTorch cwrap
 ---
-PyTorch implements its own cwrap tool to wrap the `TH` Tensor methods for use in the Python backend. We define a `.cwrap` file containing a series of C method declarations in our custom YAML format (http://yaml.org). The cwrap tool takes this file and outputs `.cpp` source files containing the wrapped methods in a format that is compatible with our `THPTensor` Python object and the Python C extension method calling format. This tool is used to generate code to wrap not only `TH`, but also `CuDNN`. It is defined to be extensible.
+PyTorch implements its own cwrap tool to wrap the `TH` Tensor methods for use in the Python backend. We define a `.cwrap` file containing a series of C method declarations in our custom [YAML format](http://yaml.org). The cwrap tool takes this file and outputs `.cpp` source files containing the wrapped methods in a format that is compatible with our `THPTensor` Python object and the Python C extension method calling format. This tool is used to generate code to wrap not only `TH`, but also `CuDNN`. It is defined to be extensible.
 
 An example YAML "declaration" for the in-place `addmv_` function is as follows:
 ```
@@ -284,7 +289,7 @@ An example YAML "declaration" for the in-place `addmv_` function is as follows:
 ```
 The architecture of the cwrap tool is very simple. It reads in a file, and then processes it with a series of **plugins.** See `tools/cwrap/plugins/__init__.py` for documentation on all the ways a plugin can alter the code.
 
-The source code generation occurs in a series of passes. First, the YAML "declaration" is parsed and processed. Then the source code is generated piece-by-piece - adding things like argument checks and extractions, defining the method header, and the actual call to the underlying library such as `TH`. Finally, the cwrap tool allows for processing the entire file at a time. The resulting output for `addmv_` can be explored here: https://gist.github.com/killeent/c00de46c2a896335a52552604cc4d74b.
+The source code generation occurs in a series of passes. First, the YAML "declaration" is parsed and processed. Then the source code is generated piece-by-piece - adding things like argument checks and extractions, defining the method header, and the actual call to the underlying library such as `TH`. Finally, the cwrap tool allows for processing the entire file at a time. The resulting output for `addmv_` can be [explored here](https://gist.github.com/killeent/c00de46c2a896335a52552604cc4d74b).
 
 In order to interface with the CPython backend, the tool generates an array of `PyMethodDef`s that can be stored or appended to the `THPTensor`'s `tp_methods` field.
 
@@ -322,4 +327,4 @@ This is just a snapshot of parts of the build system for PyTorch. There is more
 ### Resources:
 ---
 
- - https://docs.python.org/3.7/extending/index.html is invaluable for understanding how to write C/C++ Extension to Python
+ - <https://docs.python.org/3.7/extending/index.html> is invaluable for understanding how to write C/C++ Extension to Python