From 18188f4ba3f53cc1dab765b8a0d932d21db0ae8a Mon Sep 17 00:00:00 2001 From: brett koonce Date: Fri, 27 Sep 2019 14:39:42 -0500 Subject: [PATCH] docs: minor spelling tweaks (#4027) --- docs/contribute/code_review.rst | 2 +- docs/contribute/error_handling.rst | 2 +- docs/contribute/pull_request.rst | 2 +- docs/deploy/android.md | 4 ++-- docs/dev/hybrid_script.rst | 2 +- docs/dev/inferbound.rst | 8 ++++---- docs/dev/relay_pass_infra.rst | 2 +- docs/faq.md | 2 +- docs/install/from_source.rst | 2 +- docs/langref/hybrid_script.rst | 4 ++-- docs/langref/relay_expr.rst | 4 ++-- docs/langref/relay_type.rst | 4 ++-- docs/vta/dev/config.rst | 4 ++-- docs/vta/install.md | 2 +- 14 files changed, 22 insertions(+), 22 deletions(-) diff --git a/docs/contribute/code_review.rst b/docs/contribute/code_review.rst index 920a29c6445e..f6f2136be9af 100644 --- a/docs/contribute/code_review.rst +++ b/docs/contribute/code_review.rst @@ -22,7 +22,7 @@ Perform Code Reviews This is a general guideline for code reviewers. First of all, while it is great to add new features to a project, we must also be aware that each line of code we introduce also brings **technical debt** that we may have to eventually pay. -Open source code is maintained by a community with diverse backend, and it is even more important to bring clear, documented and maintainable code. Code reviews are shepherding process to spot potential problems, improve quality of the code. We should, however, not rely on code review process to get the code into a ready state. Contributors are encouraged to polish the code to a ready state before requesting reviews. This is especially expected for code owner and comitter candidates. +Open source code is maintained by a community with diverse backend, and it is even more important to bring clear, documented and maintainable code. Code reviews are shepherding process to spot potential problems, improve quality of the code. We should, however, not rely on code review process to get the code into a ready state. Contributors are encouraged to polish the code to a ready state before requesting reviews. This is especially expected for code owner and committer candidates. Here are some checklists for code reviews, it is also helpful reference for contributors diff --git a/docs/contribute/error_handling.rst b/docs/contribute/error_handling.rst index 152f613b8002..4d5e5c54f03c 100644 --- a/docs/contribute/error_handling.rst +++ b/docs/contribute/error_handling.rst @@ -107,7 +107,7 @@ error messages when necessary. def preferred(): # Very clear about what is being raised and what is the error message. - raise OpNotImplemented("Operator relu is not implemented in the MXNet fronend") + raise OpNotImplemented("Operator relu is not implemented in the MXNet frontend") def _op_not_implemented(op_name): return OpNotImplemented("Operator {} is not implemented.").format(op_name) diff --git a/docs/contribute/pull_request.rst b/docs/contribute/pull_request.rst index 4a2a335a95c9..7ad53758c54b 100644 --- a/docs/contribute/pull_request.rst +++ b/docs/contribute/pull_request.rst @@ -51,7 +51,7 @@ We use docker container to create stable CI environments that can be deployed to multiple machines. You can find the prebuilt images in ``_ . Because we want a relatively stable CI environment and make use of pre-cached image, -all of the CI images are built and maintained by comitters. +all of the CI images are built and maintained by committers. Upgrade of CI images can cause problems and need fixes to accommodate the new env. Here is the protocol to update CI image: diff --git a/docs/deploy/android.md b/docs/deploy/android.md index 3e8c1293fb0f..78d67a76b756 100644 --- a/docs/deploy/android.md +++ b/docs/deploy/android.md @@ -22,7 +22,7 @@ NNVM compilation of model for android target could follow same approach like android_rpc. -An reference exampe can be found at [chainer-nnvm-example](https://github.com/tkat0/chainer-nnvm-example) +An reference example can be found at [chainer-nnvm-example](https://github.com/tkat0/chainer-nnvm-example) Above example will directly run the compiled model on RPC target. Below modification at [rum_mobile.py](https://github.com/tkat0/chainer-nnvm-example/blob/5b97fd4d41aa4dde4b0aceb0be311054fb5de451/run_mobile.py#L64) will save the compilation output which is required on android target. @@ -39,4 +39,4 @@ deploy_lib.so, deploy_graph.json, deploy_param.params will go to android target. ## TVM Runtime for Android Target Refer [here](https://github.com/dmlc/tvm/blob/master/apps/android_deploy/README.md#build-and-installation) to build CPU/OpenCL version flavor TVM runtime for android target. -From android java TVM API to load model & execute can be refered at this [java](https://github.com/dmlc/tvm/blob/master/apps/android_deploy/app/src/main/java/ml/dmlc/tvm/android/demo/MainActivity.java) sample source. +From android java TVM API to load model & execute can be referred at this [java](https://github.com/dmlc/tvm/blob/master/apps/android_deploy/app/src/main/java/ml/dmlc/tvm/android/demo/MainActivity.java) sample source. diff --git a/docs/dev/hybrid_script.rst b/docs/dev/hybrid_script.rst index 010af6c87f3b..7bb5e234cba0 100644 --- a/docs/dev/hybrid_script.rst +++ b/docs/dev/hybrid_script.rst @@ -83,7 +83,7 @@ In HalideIR, loops have in total 4 types: ``serial``, ``unrolled``, ``parallel`` Variables ~~~~~~~~~ -Because there is no variables in ``HalideIR``, all the mutatable variables will be lowered to an array with size 1. +Because there is no variables in ``HalideIR``, all the mutable variables will be lowered to an array with size 1. It takes the first store of a variable as its declaration. Math Intrinsics diff --git a/docs/dev/inferbound.rst b/docs/dev/inferbound.rst index e16871e3b7cf..1b74cabf01cc 100644 --- a/docs/dev/inferbound.rst +++ b/docs/dev/inferbound.rst @@ -71,7 +71,7 @@ A TVM schedule is composed of Stages. Each stage has exactly one Operation, e.g. Array outputs; Array stages; Map stage_map; - // remainder ommitted + // remainder omitted }; class StageNode : public Node { @@ -81,14 +81,14 @@ A TVM schedule is composed of Stages. Each stage has exactly one Operation, e.g. Array all_iter_vars; Array leaf_iter_vars; Array relations; - // remainder ommitted + // remainder omitted }; class OperationNode : public Node { public: virtual Array root_iter_vars(); virtual Array InputTensors(); - // remainder ommitted + // remainder omitted }; class ComputeOpNode : public OperationNode { @@ -97,7 +97,7 @@ A TVM schedule is composed of Stages. Each stage has exactly one Operation, e.g. Array reduce_axis; Array body; Array root_iter_vars(); - // remainder ommitted + // remainder omitted }; } diff --git a/docs/dev/relay_pass_infra.rst b/docs/dev/relay_pass_infra.rst index b358e957b258..98de347734ba 100644 --- a/docs/dev/relay_pass_infra.rst +++ b/docs/dev/relay_pass_infra.rst @@ -83,7 +83,7 @@ more details). For example, during registration of a pass (will be covered in later), the pass developers can specify the name of the pass, the optimization level it will be performed at, and/or the passes that are required. ``opt_level`` could be used to help the pass infra identify if a certain pass -needes to be executed when running under a user-provided optimization level. The +needs to be executed when running under a user-provided optimization level. The ``required`` field can be used by the pass infra to resolve pass dependencies. .. code:: c++ diff --git a/docs/faq.md b/docs/faq.md index 74fc82e3bda0..e587c5591d38 100644 --- a/docs/faq.md +++ b/docs/faq.md @@ -31,7 +31,7 @@ This representation is high level, and can be helpful to perform generic optimiz such as memory reuse, layout transformation and automatic differentiation. TVM adopts a low level representation, that explicitly express the choice of memory -layout, parallelization pattern, locality and hardware primtives etc. +layout, parallelization pattern, locality and hardware primitives etc. This level of IR is closer to directly target hardwares. The low level IR adopt ideas from existing image processing languages like Halide, darkroom and loop transformation tools like loopy and polyhedra based analysis. diff --git a/docs/install/from_source.rst b/docs/install/from_source.rst index 852a23f7d790..f70a18b60528 100644 --- a/docs/install/from_source.rst +++ b/docs/install/from_source.rst @@ -86,7 +86,7 @@ The configuration of TVM can be modified by `config.cmake`. - TVM optionally depends on LLVM. LLVM is required for CPU codegen that needs LLVM. - - LLVM 4.0 or higher is needed for build with LLVM. Note that verison of LLVM from default apt may lower than 4.0. + - LLVM 4.0 or higher is needed for build with LLVM. Note that version of LLVM from default apt may lower than 4.0. - Since LLVM takes long time to build from source, you can download pre-built version of LLVM from `LLVM Download Page `_. diff --git a/docs/langref/hybrid_script.rst b/docs/langref/hybrid_script.rst index 4a3707fdaee8..99f44cede1f0 100644 --- a/docs/langref/hybrid_script.rst +++ b/docs/langref/hybrid_script.rst @@ -130,7 +130,7 @@ Users can access containers by either constants or constants loops annotated. Variables ~~~~~~~~~ -All the mutatable variables will be lowered to an array with size 1. +All the mutable variables will be lowered to an array with size 1. It regards the first store of a variable as its declaration. .. note:: @@ -158,7 +158,7 @@ Attributes ~~~~~~~~~~ So far, ONLY tensors' ``shape`` and ``dtype`` attribute are supported! -The ``shape`` atrribute is essentailly a tuple, so you MUST access it as an array. +The ``shape`` attribute is essentially a tuple, so you MUST access it as an array. Currently, only constant-indexed access is supported. .. code-block:: python diff --git a/docs/langref/relay_expr.rst b/docs/langref/relay_expr.rst index a9f1cf8f18ba..4a999a95f851 100644 --- a/docs/langref/relay_expr.rst +++ b/docs/langref/relay_expr.rst @@ -26,7 +26,7 @@ Dataflow and Control Fragments ============================== For the purposes of comparing Relay to traditional computational graph-based IRs, it -can be useful to consider Relay exrpessions in terms of dataflow and control fragments. +can be useful to consider Relay expressions in terms of dataflow and control fragments. Each portion of a Relay program containing expressions that only affect the dataflow can be viewed as a traditional computation graph when writing and expressing transformations. @@ -88,7 +88,7 @@ expression where it is bound, respectively. In the below code segment, notice that :code:`%a` is defined twice. This is permitted, as in most functional languages; in the scope of the second :code:`let` expression, the name :code:`%a` is "shadowed," meaning all -references to :code:`%a` in the inner scope refer to the later defintion, while +references to :code:`%a` in the inner scope refer to the later definition, while references to :code:`%a` in the outer scope continue to refer to the first one. diff --git a/docs/langref/relay_type.rst b/docs/langref/relay_type.rst index d54ea086e16c..ce00dff755c9 100644 --- a/docs/langref/relay_type.rst +++ b/docs/langref/relay_type.rst @@ -290,7 +290,7 @@ parameters must be treated as different types) and be recursive (a constructor for an ADT can take an instance of that ADT, thus an ADT like a tree or list can be inductively built up). The representation of ADTs in the type system must -be able to accomodate these facts, as the below sections will detail. +be able to accommodate these facts, as the below sections will detail. Global Type Variable ~~~~~~~~~~~~~~~~~~~~ @@ -316,7 +316,7 @@ Definitions (Type Data) ~~~~~~~~~~~~~~~~~~~~~~~ Besides a name, an ADT needs to store the constructors that are used -to define it and any type paramters used within them. These are +to define it and any type parameters used within them. These are stored in the module, :ref:`analogous to global function definitions`. While type-checking uses of ADTs, the type system sometimes must diff --git a/docs/vta/dev/config.rst b/docs/vta/dev/config.rst index f4b5bcec8af1..d8808e912b9f 100644 --- a/docs/vta/dev/config.rst +++ b/docs/vta/dev/config.rst @@ -68,7 +68,7 @@ below. We provide additional detail below regarding each parameter: - ``TARGET``: Can be set to ``"pynq"``, ``"ultra96"``, ``"sim"`` (fast simulator), or ``"tsim"`` (cycle accurate sim with verilator). - - ``HW_VER``: Hardware version which increments everytime the VTA hardware design changes. This parameter is used to uniquely idenfity hardware bitstreams. + - ``HW_VER``: Hardware version which increments every time the VTA hardware design changes. This parameter is used to uniquely identity hardware bitstreams. - ``LOG_BATCH``: Equivalent to A in multiplication of shape (A, B) x (B, C), or typically, the batch dimension of inner tensor computation. - - ``LOG_BLOCK``: Equivalent to B and C in multiplication of shape (A, B) x (B, C), or typically, the input/output channel dimensions of the innter tensor computation. + - ``LOG_BLOCK``: Equivalent to B and C in multiplication of shape (A, B) x (B, C), or typically, the input/output channel dimensions of the inner tensor computation. diff --git a/docs/vta/install.md b/docs/vta/install.md index 2f99d1f3fe48..c43a167292b4 100644 --- a/docs/vta/install.md +++ b/docs/vta/install.md @@ -202,7 +202,7 @@ Before powering up the device, we need to flash the microSD card image with late #### Flash SD Card and Boot Angstrom Linux To flash SD card and boot Linux on DE10-Nano, it is recommended to navigate to the [Resource](https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=1046&PartNo=4) tab of the DE10-Nano product page from Terasic Inc. -After registeration and login on the webpage, the prebuild Angstrom Linux image would be available for downloading and flashing. +After registration and login on the webpage, the prebuilt Angstrom Linux image would be available for downloading and flashing. Specifically, to flash the downloaded Linux SD card image into your physical SD card: First, extract the gzipped archive file.