[CodeStyle][Typos][M-[1-2]，M-[4-7]，M-[9-11]] Fix typo(Moible, …) (#7627)

* fix typo: 'Moible', 'mantained', 'mdule', 'mechnism', 'memeory', 'memroy', 'messege', 'metaphore', 'muliply', 'mulitplying',

* Update docs/guides/model_convert/convert_from_pytorch/api_difference/torch_more_args/torch.scalar_tensor.md

Co-authored-by: Copilot <[email protected]>

---------

Co-authored-by: ooo oo <[email protected]>
Co-authored-by: Copilot <[email protected]>

Author: 3 people

_typos.toml

@@ -29,7 +29,6 @@ feeded = "feeded"
 
 # These words need to be fixed
 Learing = "Learing"
-Moible = "Moible"
 Operaton = "Operaton"
 Optimizaing = "Optimizaing"
 Optimzier = "Optimzier"
@@ -44,17 +43,8 @@ interchangable = "interchangable"
 intializers = "intializers"
 intput = "intput"
 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/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

@@ -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/design/others/graph.md

@@ -56,7 +56,7 @@ For each parameter, like W and b created by `layer.fc`, marked as double circles
 
 ## Block and Graph
 
-The word block and graph are interchangable in the design of PaddlePaddle.  A [Block](https://github.com/PaddlePaddle/Paddle/pull/3708) is a metaphore of the code and local variables in a pair of curly braces in programming languages, where operators are like statements or instructions.  A graph of operators and variables is a representation of the block.
+The word block and graph are interchangable in the design of PaddlePaddle.  A [Block](https://github.com/PaddlePaddle/Paddle/pull/3708) is a metaphor of the code and local variables in a pair of curly braces in programming languages, where operators are like statements or instructions.  A graph of operators and variables is a representation of the block.
 
 A Block keeps operators in an array `BlockDesc::ops`
 

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 进行逐元素相乘。
 
 ----------