complete merge: resolve conflicts from origin/develop

Author: liangqi520

_typos.toml

@@ -29,25 +29,15 @@ feeded = "feeded"
 
 # These words need to be fixed
 Learing = "Learing"
-Moible = "Moible"
 Operaton = "Operaton"
 Optimizaing = "Optimizaing"
 Optimzier = "Optimzier"
 Setment = "Setment"
 Simle = "Simle"
 Sovler = "Sovler"
 libary = "libary"
-mantained = "mantained"
 matrics = "matrics"
-mdule = "mdule"
-mechnism = "mechnism"
-memeory = "memeory"
-memroy = "memroy"
-messege = "messege"
-metaphore = "metaphore"
 metrices = "metrices"
-muliply = "muliply"
-mulitplying = "mulitplying"
 mutbale = "mutbale"
 occurence = "occurence"
 opeartor = "opeartor"

docs/api/paddle/static/accuracy_cn.rst

@@ -10,7 +10,7 @@ accuracy
 
 accuracy layer。参考 https://en.wikipedia.org/wiki/Precision_and_recall
 
-使用输入和标签计算准确率。如果正确的标签在 topk 个预测值里，则计算结果加 1。注意：输出正确率的类型由 input 类型决定，input 和 lable 的类型可以不一样。
+使用输入和标签计算准确率。如果正确的标签在 topk 个预测值里，则计算结果加 1。注意：输出正确率的类型由 input 类型决定，input 和 label 的类型可以不一样。
 
 参数
 ::::::::::::

docs/design/concurrent/go_op.md

@@ -218,7 +218,7 @@ for more details.
 
 #### Green Threads
 
-Golang utilizes `green threads`, which is a mechnism for the runtime library to
+Golang utilizes `green threads`, which is a mechanism for the runtime library to
 manage multiple threads (instead of natively by the OS).  Green threads usually
 allows for faster thread creation and switching, as there is less overhead
 when spawning these threads.  For the first version of CSP, we only support

docs/design/memory/README.md

@@ -116,7 +116,7 @@ I got inspiration from Majel and Caffe2, though above design look different from
 
 ### Caffe2
 
-In Caffe2, `Tensor<Context>::mutable_data()` allocates the memroy.  In particular, [`Tensor<Context>::mutable_data`](https://github.com/caffe2/caffe2/blob/v0.7.0/caffe2/core/tensor.h#L523) calls [`Tensor<Context>::raw_mutable_data`](https://github.com/caffe2/caffe2/blob/v0.7.0/caffe2/core/tensor.h#L459), which in turn calls [`Context::New`](https://github.com/caffe2/caffe2/blob/v0.7.0/caffe2/core/tensor.h#L479).
+In Caffe2, `Tensor<Context>::mutable_data()` allocates the memory.  In particular, [`Tensor<Context>::mutable_data`](https://github.com/caffe2/caffe2/blob/v0.7.0/caffe2/core/tensor.h#L523) calls [`Tensor<Context>::raw_mutable_data`](https://github.com/caffe2/caffe2/blob/v0.7.0/caffe2/core/tensor.h#L459), which in turn calls [`Context::New`](https://github.com/caffe2/caffe2/blob/v0.7.0/caffe2/core/tensor.h#L479).
 
 There are two implementations of `Context`:
 

docs/design/memory/memory_optimization.md

@@ -53,7 +53,7 @@ In compilers, the front end of the compiler translates programs into an intermed
 
 Therefore, the compiler needs to analyze the intermediate-representation program to determine which temporary variables are in use at the same time. We say a variable is "live" if it holds a value that may be needed in the future, so this analysis is called liveness analysis.
 
-We can leran these techniques from compilers. There are mainly two stages to make live variable analysis:
+We can learn these techniques from compilers. There are mainly two stages to make live variable analysis:
 
 - construct a control flow graph
 - solve the dataflow equations
@@ -197,7 +197,7 @@ After op1, we can process variable b and variable c; After op2, we can process v
 
 #### memory sharing policy
 
-A memory pool will be mantained in the stage of memory optimization. Each operator node will be scanned to determine memory optimization is done or not. If an operator satisfies the requirement, following policy will be taken to handle input/output variables.
+A memory pool will be maintained in the stage of memory optimization. Each operator node will be scanned to determine memory optimization is done or not. If an operator satisfies the requirement, following policy will be taken to handle input/output variables.
 
 ```
 if op.support_inplace():

docs/design/mkldnn/gru/gru.md

@@ -99,12 +99,12 @@ Because oneDNN assumes that all sentences are of equal length, before reorder, w
 ![](images/input_is_reverse.svg)
 
 * PaddlePaddle WeightX -> oneDNN WeightX\
-WeightX does not need custom reorders because memory arrangement is the same for both PP and oneDNN. However, it has to be modified if `origin_mode==false` by mulitplying update gate part by `-1`. At the end, oneDNN reorder is called to convert weights to correct type and strides selected by primitive.
+WeightX does not need custom reorders because memory arrangement is the same for both PP and oneDNN. However, it has to be modified if `origin_mode==false` by multiplying update gate part by `-1`. At the end, oneDNN reorder is called to convert weights to correct type and strides selected by primitive.
 * PaddlePaddle WeightH -> oneDNN WeightH\
 WeightH tensor has different representation in PP and oneDNN. PaddlePaddle stores it as 2 connected blocks of memory, where first contains reset and update gate recurrent weights, and second stores output gate recurrent weights. In oneDNN, these weights are stored in a single memory block of size `[OC, 3, OC]`. Therefore, custom reorder is needed here. After that, if `origin_mode==false`, update gate part is multiplied by `-1`. At the end, oneDNN reorder is called to convert weights to correct type and strides selected by primitive.
 ![](images/different_tensor_memory_arrangement.svg)
 * PaddlePaddle Bias -> oneDNN Bias\
-Bias does not require reorder from PP to oneDNN. However, if it is not provided by user, it has to be created and filled with `0.0f` because oneDNN requires it. If it was provided, it has to be modified when `origin_mode==false` by mulitplying update gate part by `-1`. Note: bias is always of `float` data type, even in `int8` and `bfloat16` kernels.
+Bias does not require reorder from PP to oneDNN. However, if it is not provided by user, it has to be created and filled with `0.0f` because oneDNN requires it. If it was provided, it has to be modified when `origin_mode==false` by multiplying update gate part by `-1`. Note: bias is always of `float` data type, even in `int8` and `bfloat16` kernels.
 * oneDNN TNC/NTC -> PaddlePaddle Output LoD\
 After execution of oneDNN GRU primitive, output tensor has to be converted back to PP representation. It is done in the same way as input reorder but in a reverse manner.
 

docs/dev_guides/custom_device_docs/memory_api_en.md

@@ -180,7 +180,7 @@ It copies synchronous memory in the device.
 
 device - the device to be used
 
-dst - the address of the destination device memroy
+dst - the address of the destination device memory
 
 src - the address of the source device memory
 

docs/eval/evaluation_of_docs_system.md

@@ -271,7 +271,7 @@ TensorFlow 的文档规划，比较直接地匹配了本文所介绍的分类标
     - Training Transformer models using Pipeline Parallelism
     - Training Transformer models using Distributed Data Parallel and Pipeline Parallelism
     - Distributed Training with Uneven Inputs Using the Join Context Manager
-- Moible
+- Mobile
     - Image Segmentation DeepLabV3 on iOS
     - Image Segmentation DeepLabV3 on Android
 - Recommendation Systems

docs/eval/【Hackathon No.69】PR.md

@@ -97,7 +97,7 @@ torch.tensor(data,
 
 在 paddle.to_tensor 中，stop_gradient 表示是否阻断梯度传导，PyTorch 的 requires_grad 表示是否不阻断梯度传导。
 
-在 torch.tensor 中，pin_memeory 表示是否使用锁页内存，而 PaddlePaddle 却无此参数。
+在 torch.tensor 中，pin_memory 表示是否使用锁页内存，而 PaddlePaddle 却无此参数。
 
 ------
 

docs/faq/train_cn.md

@@ -8,7 +8,7 @@
 
 ##### 问题：请问`paddle.matmul`和`paddle.multiply`有什么区别？
 
-+ 答复：`matmul`支持的两个 tensor 的矩阵乘操作。`muliply`是支持两个 tensor 进行逐元素相乘。
++ 答复：`matmul`支持的两个 tensor 的矩阵乘操作。`multiply`是支持两个 tensor 进行逐元素相乘。
 
 ----------