This is an automated email from the ASF dual-hosted git repository. masahi pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/incubator-tvm.git
The following commit(s) were added to refs/heads/master by this push: new a449d8b [DOCS] Fix sphinx precheck (#4967) a449d8b is described below commit a449d8b1fe8ca34bbc9eaca2e8ecfe76324118de Author: Tianqi Chen <tqc...@users.noreply.github.com> AuthorDate: Fri Feb 28 13:20:04 2020 -0800 [DOCS] Fix sphinx precheck (#4967) * [DOCS] Fix sphinx precheck * ignore keras warnings * Remove more warnings --- docs/langref/relay_adt.rst | 41 ++++++++++----------- docs/langref/relay_expr.rst | 68 +++++++++++++++++------------------ docs/langref/relay_type.rst | 16 ++++----- tests/scripts/task_sphinx_precheck.sh | 2 +- 4 files changed, 64 insertions(+), 63 deletions(-) diff --git a/docs/langref/relay_adt.rst b/docs/langref/relay_adt.rst index e487684..a53c751 100644 --- a/docs/langref/relay_adt.rst +++ b/docs/langref/relay_adt.rst @@ -1,3 +1,4 @@ + .. Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information @@ -63,7 +64,7 @@ Hence, it is often easy to reason about ADTs. Below is a simple example of defining an ADT and using it in a function via a match expression: -.. code-block:: python +.. code-block:: # Defines an ADT named "Numbers" data Numbers { @@ -94,7 +95,7 @@ meaning that two ADTs with structurally identical constructors will nevertheless be distinct data types from the point of view of the typechecker. -.. code-block:: python +.. code-block:: # structurally identical constructors to Numbers data Numbers2 { @@ -117,7 +118,7 @@ can be polymorphic and take type parameters. For example, one of the standard ADTs commonly used in functional programming languages is the optional type, defined here: -.. code-block:: python +.. code-block:: # a is a type parameter data Optional<a> { @@ -141,7 +142,7 @@ imply, an ADT instance is thus given a type that contains the concrete type arguments for that instance, ensuring the information is kept around. Let the below example illustrate: -.. code-block:: python +.. code-block:: # the signature for option indicates the type argument def @inc_scalar(%opt : Optional[Tensor[(), int32]]) -> Tensor[(), int32] { @@ -198,7 +199,7 @@ Many commonly used ADTs involve recursion; some of these are given in `Common ADT Uses`_. As an example here, we will examine the list ADT, ubiquitous in functional languages: -.. code-block:: python +.. code-block:: data List<a> { Nil : () -> List @@ -216,7 +217,7 @@ end of the list is reached, which can be indicated with a :code:`Nil` Lists represented in this manner can easily be recursively processed. For example, the following function sums a list of integers: -.. code-block:: python +.. code-block:: def @list_sum(%l : List[Tensor[(), int32]]) -> Tensor[(), int32] { match(%l) { @@ -250,7 +251,7 @@ and the second has a :code:`Cons` constructor pattern that uses variable pattern The below example uses a wildcard pattern to ignore one of the arguments to :code:`Cons`: -.. code-block:: python +.. code-block:: def @first<a>(%l : List[a]) -> Optional[a] { match(%l) { @@ -262,7 +263,7 @@ The below example uses a wildcard pattern to ignore one of the arguments to :cod Here, a constructor pattern is nested inside another constructor pattern to avoid nested match expressions for a list option. A top-level wildcard pattern is also used to handle all cases that do not match the first clause: -.. code-block:: python +.. code-block:: def @second_opt<a>(%ll : Optional[List[a]]) -> Optional[a] { match(%ll) { @@ -281,7 +282,7 @@ Note that a match expression checks its patterns in the order the cases are list that matches the input value is the one that is evaluated. Here, a top-level variable pattern binds the whole input value: -.. code-block:: python +.. code-block:: def @match_order_beware<a>(%l : List[a]) -> List[a] { match(%l) { @@ -291,7 +292,7 @@ input value: case Nil() { Nil() } } } - + Common ADT Uses =============== @@ -312,7 +313,7 @@ list comprehensions and certain library functions in Python. Below are very comm through lists, which are included in Relay's Prelude. (These have all been extensively characterized in the functional programming literature, and we do not attempt to reproduce that work in this document.) -.. code-block:: python +.. code-block:: # Map: for [h1, h2, ..., hn] returns [f(h1), f(h2), ..., f(hn)] def @map<a, b>(%f : fn(a) -> b, %l : List[a]) -> List[b] { @@ -341,7 +342,7 @@ in the functional programming literature, and we do not attempt to reproduce tha Using these iteration constructs, many common operations over lists can be expressed compactly. For example, the following map doubles all members of a list: -.. code-block:: python +.. code-block:: # directly written def @double(%l : List[Tensor[(), int32]]) -> List[Tensor[(), int32]] { @@ -356,7 +357,7 @@ For example, the following map doubles all members of a list: The following right fold concatenates two lists: -.. code-block:: python +.. code-block:: # directly written def @concat<a>(%l1 : List[a], %l2 : List[a]) -> List[a] { @@ -371,7 +372,7 @@ The following right fold concatenates two lists: The following left fold flattens a list of lists (using concatenation): -.. code-block:: python +.. code-block:: # directly written def @flatten<a>(%ll : List[List[a]]) -> List[a] { @@ -401,13 +402,13 @@ First let us suppose that we have a function corresponding to a trained recurren cell, which takes in a past state and an input value and returns a new state and output value. In Relay, this would have the following signature: -.. code-block:: python +.. code-block:: @cell : fn<state_type, in_type, out_type>(state_type, in_type) -> (state_type, out_type) We might consider a ReLU cell as a simple concrete example, with a trained version below: -.. code-block:: python +.. code-block:: def @linear(%x, %w, %b) { %w*%x + %b } @@ -429,7 +430,7 @@ We might consider a ReLU cell as a simple concrete example, with a trained versi Following Olah's example, we can encode a sequence (list) of inputs with the following left fold: -.. code-block:: python +.. code-block:: def @encode<state_type, in_type, out_type>(%cell, %input : List[in_type], %init : state_type) -> state_type { # not using the output @@ -439,7 +440,7 @@ Following Olah's example, we can encode a sequence (list) of inputs with the fol Using an *unfold* iterator (from Haskell's standard library), the same cell could be used to make a generator network (which takes a single input and produces a sequence of outputs): -.. code-block:: python +.. code-block:: # included in Relay's Prelude def @unfoldr<a, b>(%f : fn(b) -> Optional[(a, b)], %z : b) -> List[a] { @@ -468,7 +469,7 @@ a generator network (which takes a single input and produces a sequence of outpu An accumulating map (a fold that simultaneously updates an accumulator value and a list of outputs) can be used to write a general RNN (with an output for every input): -.. code-block:: python +.. code-block:: def @map_accumr<a, b, c>(%f : fn(a, b) -> (a, c), %acc : a, %l : List[b]) -> (a, List[c]) { match(%l) { @@ -500,7 +501,7 @@ Olah also gives an example of a bidirectional neural network, in which two sets cells (which may have different weights) process the input in both directions and produce a single set of outputs. The following is a Relay implementation of that example: -.. code-block:: python +.. code-block:: # creates a list of tuples from two lists # included in Relay's Prelude diff --git a/docs/langref/relay_expr.rst b/docs/langref/relay_expr.rst index 1fd39bc..66bfe43 100644 --- a/docs/langref/relay_expr.rst +++ b/docs/langref/relay_expr.rst @@ -92,7 +92,7 @@ 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. -.. code-block:: python +.. code-block:: let %a = 1; let %b = 2 * %a; // %b = 2 @@ -129,14 +129,14 @@ A definition minimally consists of the keyword :code:`fn`, an empty set of parameters, and a body expression (:py:class:`~tvm.relay.expr.Expr`) contained by curly braces. -.. code-block:: python +.. code-block:: fn() { body } A definition may contain any number of parameters. For example, a simple function that invokes the :code:`add` operator: -.. code-block:: python +.. code-block:: fn(%x, %y) { add(%x, %y) } @@ -147,7 +147,7 @@ One may also annotate explicit types on functions. For example, we can restrict the above function to only work on certain types: -.. code-block:: python +.. code-block:: fn(%x : Tensor[(10, 10), float32], %y : Tensor[(10, 10), float32]) -> Tensor[(10, 10), float32] { @@ -155,7 +155,7 @@ on certain types: } The above function only takes arguments of type :code:`Tensor[(10, 10), float32]` and returns a value of -type :code:`Tensor[(10, 10), float32]`. A function parameter is just a local +type :code:`Tensor[(10, 10), float32]`. A function parameter is just a local variable (:py:class:`~tvm.relay.expr.LocalVar`) optionally annotated with a type, written as :code:`%x : T`. When the type information is omitted, Relay attempts to infer the most general type @@ -166,7 +166,7 @@ parameters and return type based on the function body and call sites. A recursive function expression can be defined using a :code:`let` binding, as here: -.. code-block:: python +.. code-block:: let %fact = fn(%x : Tensor[(10, 10), float32]) -> Tensor[(10, 10), float32] { if (%x == Constant(0, (10, 10), float32)) { @@ -189,7 +189,7 @@ For example, in the below example, the final result will be a tensor of zero values because the closure for :code:`%f` stores the value of :code:`%x` at the pointer where :code:`%f` was defined. -.. code-block:: python +.. code-block:: let %g = fn() { let %x = Constant(0, (10, 10), float32); @@ -216,13 +216,13 @@ given at call sites. Type parameters are classified by *kind* and can only appear in parts of the type signature where their kind is appropriate (e.g., type parameters of kind :code:`Shape` can only appear where a shape -would be expected in a tensor type); for a full discussion, +would be expected in a tensor type); for a full discussion, see :ref:`the documentation on type parameters <type-parameter>`. For example, one can define a polymorphic identity function for any Relay type as follows: -.. code-block:: python +.. code-block:: fn<t : Type>(%x : t) -> t { %x @@ -231,7 +231,7 @@ any Relay type as follows: The below definition is also polymorphic, but restricts its arguments to tensor types: -.. code-block:: python +.. code-block:: fn<s : Shape, bt : BaseType>(%x : Tensor[s, bt]) { %x @@ -244,7 +244,7 @@ Notice that the return type is omitted and will be inferred. A function may also be subject to one or more type relations, such as in the following: -.. code-block:: python +.. code-block:: fn(%x, %y) where Broadcast { add(%x, %y) } @@ -347,14 +347,14 @@ or global functions) and Relay operators. The syntax of calls follows that used in C-like languages, demonstrated in the example below: -.. code-block:: python +.. code-block:: let %c = 1; let %f = fn(%x : Tensor[(), float32], %y : Tensor[(), float32]) { %x + %y + %c }; %f(10, 11) When a closure is called (see `Closures`_), -the closure's body is evaluated in the stored environment +the closure's body is evaluated in the stored environment (i.e., using the stored values for free variables) with local variable bindings added for each argument; the final value obtained by evaluating the body is the call's return value. @@ -362,7 +362,7 @@ Thus, in the above example, the call evaluates to 22. In the case of operators, the implementation is opaque to Relay, so the result is left up to the registered TVM implementation. -*Note: type parameters are not yet supported in the text format.* +*Note: type parameters are not yet supported in the text format.* A type-polymorphic function can also include type arguments at a call site. The type arguments are substituted for type parameters when @@ -370,7 +370,7 @@ type checking. If a function is type-polymorphic and type arguments are not given, type inference will attempt to infer type arguments if possible. The following code gives examples of explicit and inferred type arguments: -.. code-block:: python +.. code-block:: // %f : fn<a : Type, b : Type, c : Type>(a, b) -> c let %x1 = %f<Tensor[(), bool], Tensor[(), bool], Tensor[(), bool)]>(True, False); @@ -380,7 +380,7 @@ The following code gives examples of explicit and inferred type arguments: Note that all type relations in the function type must hold at each call site. Specifically, this means that the relation will be checked -against the specific types of the arguments at a given call site. This +against the specific types of the arguments at a given call site. This is also a form of polymorphism, since there may be multiple valid assignments of argument types and a return type so long as the relation is satisfied. @@ -390,7 +390,7 @@ and has the :code:`Broadcast` relation, then there are many different shapes that the arguments in the below call could have that would satisfy the type annotation: -.. code-block:: python +.. code-block:: let %x : Tensor[(100, 100, 100), float32] = %f(%a, %b); %x @@ -416,7 +416,7 @@ but have syntactic sugar in the text format to enter their definitions into the a global function definition includes a global identifier and is allowed to recursively refer to that identifier in the body, as in the following example: -.. code-block:: python +.. code-block:: def @ackermann(%m : Tensor[(), int32], %n : Tensor[(), int32]) -> Tensor[(), int32] { if (%m == 0) { @@ -455,11 +455,11 @@ Tuples Construction ~~~~~~~~~~~~ -The tuple node builds a finite (that is, of statically known size) sequence of heterogeneous data. +The tuple node builds a finite (that is, of statically known size) sequence of heterogeneous data. These tuples match Python's closely, and their fixed length allows for efficient projection of their members. -.. code-block:: python +.. code-block:: fn(%a : Tensor[(10, 10), float32], %b : float32, %c : Tensor[(100, 100), float32]) { let %tup = (%a, %b); // type: (Tensor[(10, 10), float32], float32) @@ -476,7 +476,7 @@ particular member of the tuple. Projections are 0-indexed. For example, the below projection evaluates to :code:`%b`: -.. code-block:: python +.. code-block:: (%a, %b, %c).1 @@ -494,10 +494,10 @@ that may reference the bound identifier. If a type annotation on the bound variable is omitted, Relay attempts to infer the most general type permitted for the variable. -The bound variable in a :code:`let` expression is only in scope +The bound variable in a :code:`let` expression is only in scope in its body, except when the variable defines a function expression. When a :code:`let` expression creates a function, the variable is also -in scope in its value to allow for recursively defined functions +in scope in its value to allow for recursively defined functions (see the previous subsection). The value of a :code:`let` binding is the value of the final expression @@ -505,7 +505,7 @@ after evaluating the bindings it depends on. For example, in the following example the entire expression evaluates to a tensor of shape :code:`(10, 10)` where all elements are 2: -.. code-block:: python +.. code-block:: let %x : Tensor[(10, 10), float32] = Constant(1, (10, 10), float32); %x + %x @@ -518,7 +518,7 @@ For example, the first and second :code:`let` bindings below may be evaluated in either order because neither has a dataflow dependency on the other: -.. code-block:: python +.. code-block:: let %x = %a + %b; let %y = %c + %d; @@ -549,7 +549,7 @@ of this nuance). In Relay's text format, a graph binding can be written as below (note the lack of a :code:`let` keyword and a semicolon): -.. code-block:: python +.. code-block:: %1 = %a + %b %2 = %1 + %1 @@ -561,7 +561,7 @@ Python front-end by setting *Python variables* equal to the corresponding Relay using the variables repeatedly, as below (a C++ program using the corresponding API bindings could accomplish the same thing): -.. code-block:: python +.. code-block:: sum1 = relay.add(a, b) sum2 = relay.add(sum1, sum1) @@ -581,7 +581,7 @@ Relay has a simple if-then-else expression that allows programs to branch on a single value of type :code:`bool`, i.e., a zero-rank tensor of booleans (:code:`Tensor[(), bool]`). -.. code-block:: python +.. code-block:: if (%t == %u) { %t @@ -626,7 +626,7 @@ executed; the clause expression is evaluated and returned. For example, suppose we have an ADT for natural numbers: -.. code-block:: python +.. code-block:: data Nat { Z : () -> Nat # zero @@ -635,7 +635,7 @@ For example, suppose we have an ADT for natural numbers: Then the following function subtracts one from a passed nat: -.. code-block:: python +.. code-block:: fn(%v: Nat[]) -> Nat[] { match(%v) { @@ -647,7 +647,7 @@ Then the following function subtracts one from a passed nat: The following function subtracts two from its argument if it is at least two and returns the argument otherwise, using a nested constructor pattern: -.. code-block:: python +.. code-block:: fn(%v : Nat[]) -> Nat[] { match(%v) { @@ -661,7 +661,7 @@ As aforementioned, the ordering of match clauses is relevant. In the below example, the first clause will always match so those below it can never run: -.. code-block:: python +.. code-block:: fn(%v : Nat[]) -> Nat[] { match(%v) { @@ -677,7 +677,7 @@ See :py:class:`~tvm.relay.adt.Match` for its definition and documentation. TempExprs ========= -Program transformations (passes) in Relay may require inserting temporary +Program transformations (passes) in Relay may require inserting temporary state into the program AST to guide further transformations. The :code:`TempExpr` node is provided as a utility to developers for this purpose; nodes inheriting from :code:`TempExpr` cannot appear directly in user-provided @@ -685,7 +685,7 @@ code but may be inserted in a pass. Any :code:`TempExpr` created in a pass should ideally be eliminated before the pass is complete, as a :code:`TempExpr` only stores internal state and has no semantics of its own. -For an example of :code:`TempExpr` being used in a pass, +For an example of :code:`TempExpr` being used in a pass, see :code:`src/relay/pass/alter_op_layout.cc`, which uses :code:`TempExpr` nodes to store information about operator layouts as the pass tries to rearrange operator calls. diff --git a/docs/langref/relay_type.rst b/docs/langref/relay_type.rst index ce00dff..0fc19b7 100644 --- a/docs/langref/relay_type.rst +++ b/docs/langref/relay_type.rst @@ -80,7 +80,7 @@ running a program. For example, here is a simple concrete tensor type corresponding to a 10-by-10 tensor of 32-bit floats: -.. code-block:: python +.. code-block:: Tensor[(10, 10), float32] @@ -101,7 +101,7 @@ For example, in the below code, :code:`%t` is of type :code:`(Tensor[(), bool], Tensor[(10, 10), float32])` and :code:`%c` is of type :code:`Tensor[(10, 10), float32]`. -.. code-block:: python +.. code-block:: let %t = (False, Constant(1, (10, 10), float32)); let %c = %t.1; @@ -116,7 +116,7 @@ Type Parameter Type parameters represent placeholder types used for polymorphism in functions. Type parameters are specified according to *kind*, corresponding to the types -those parameters are allowed to replace: +those parameters are allowed to replace: - :code:`Type`, corresponding to top-level Relay types like tensor types, tuple types, and function types - :code:`BaseType`, corresponding to the base type of a tensor (e.g., :code:`float32`, :code:`bool`) @@ -135,7 +135,7 @@ Like normal parameters, concrete arguments must be given for type parameters at For example, :code:`s` below is a type parameter of kind :code:`Shape` and it will be substituted with :code:`(10, 10)` at the call site below: -.. code-block:: python +.. code-block:: def @plus<s : Shape>(%t1 : Tensor[s, float32], %t2 : Tensor[s, float32]) { add(%t1, %t2) @@ -212,7 +212,7 @@ and the return type. For example, we can define the relation for :code:`flatten` If we have a relation like :code:`Broadcast` it becomes possible to type operators like :code:`add`: -.. code-block:: python +.. code-block:: add : fn<t1 : Type, t2 : Type, t3 : Type>(t1, t2) -> t3 where Broadcast @@ -359,7 +359,7 @@ This subsection uses the simple list ADT (included as a default ADT in Relay) to illustrate the constructs described in the previous sections. Its definition is as follows: -.. code-block:: python +.. code-block:: data List<a> { Nil : () -> List @@ -377,7 +377,7 @@ variable :code:`List` in the constructor definition. Below two instances of lists with their types given, using type calls: -.. code-block:: python +.. code-block:: Cons(1, Cons(2, Nil())) # List[Tensor[(), int32]] Cons((1, 1), Cons((2, 2), Nil())) # List[(Tensor[(), int32], Tensor[(), int32])] @@ -390,7 +390,7 @@ be specified.) Here are two lists that are rejected by the type system because the type parameters do not match: -.. code-block:: python +.. code-block:: # attempting to put an integer on a list of int * int tuples Cons(1, Cons((1, 1), Nil())) diff --git a/tests/scripts/task_sphinx_precheck.sh b/tests/scripts/task_sphinx_precheck.sh index cf45c8c..1f42886 100755 --- a/tests/scripts/task_sphinx_precheck.sh +++ b/tests/scripts/task_sphinx_precheck.sh @@ -36,7 +36,7 @@ echo "PreCheck sphinx doc generation WARNINGS.." cd docs TVM_TUTORIAL_EXEC_PATTERN=none make html 2>/tmp/$$.log.txt -grep -v -E "__mro__|RemovedInSphinx|UserWarning|FutureWarning" < /tmp/$$.log.txt > /tmp/$$.logclean.txt || true +grep -v -E "__mro__|RemovedInSphinx|UserWarning|FutureWarning|Keras" < /tmp/$$.log.txt > /tmp/$$.logclean.txt || true echo "---------Sphinx Log----------" cat /tmp/$$.logclean.txt echo "-----------------------------"