mirror of
https://github.com/zebrajr/tensorflow.git
synced 2025-12-06 00:19:58 +01:00
Fixed typos and grammatical errors
This commit is contained in:
parent
dbba95ec7e
commit
6d1cc2e35a
|
|
@ -89,8 +89,8 @@ Follow either of the two links above to access the appropriate CLA and instructi
|
|||
### Contributing code
|
||||
|
||||
If you have improvements to TensorFlow, send us your pull requests! For those
|
||||
just getting started, Github has a
|
||||
[how to](https://help.github.com/articles/using-pull-requests/).
|
||||
just getting started, GitHub has a
|
||||
[how-to](https://help.github.com/articles/using-pull-requests/).
|
||||
|
||||
TensorFlow team members will be assigned to review your pull requests. Once the
|
||||
pull requests are approved and pass continuous integration checks, a TensorFlow
|
||||
|
|
@ -101,7 +101,7 @@ automatically on GitHub.
|
|||
|
||||
If you want to contribute, start working through the TensorFlow codebase,
|
||||
navigate to the
|
||||
[Github "issues" tab](https://github.com/tensorflow/tensorflow/issues) and start
|
||||
[GitHub "issues" tab](https://github.com/tensorflow/tensorflow/issues) and start
|
||||
looking through interesting issues. If you are not sure of where to start, then
|
||||
start by trying one of the smaller/easier issues here i.e.
|
||||
[issues with the "good first issue" label](https://github.com/tensorflow/tensorflow/labels/good%20first%20issue)
|
||||
|
|
|
|||
|
|
@ -2,8 +2,8 @@ If you open a GitHub Issue, here is our policy:
|
|||
|
||||
1. It must be a bug/performance issue or a feature request or a build issue or
|
||||
a documentation issue (for small doc fixes please send a PR instead).
|
||||
1. Make sure the Issue Template is filled out.
|
||||
1. The issue should be related to the repo it is created in.
|
||||
2. Make sure the Issue Template is filled out.
|
||||
3. The issue should be related to the repo it is created in.
|
||||
|
||||
**Here's why we have this policy:** We want to focus on the work that benefits
|
||||
the whole community, e.g., fixing bugs and adding features. Individual support
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@
|
|||
[](https://tensorflow.github.io/build#TF%20Official%20Continuous)
|
||||
[](https://tensorflow.github.io/build#TF%20Official%20Nightly)
|
||||
|
||||
**`Documentation`** |
|
||||
**`Documentation`** |
|
||||
------------------- |
|
||||
[](https://www.tensorflow.org/api_docs/) |
|
||||
|
||||
|
|
@ -114,7 +114,7 @@ apply fixes to bugs or security vulnerabilities:
|
|||
|
||||
* Clone the TensorFlow repo and switch to the corresponding branch for your
|
||||
desired TensorFlow version, for example, branch `r2.8` for version 2.8.
|
||||
* Apply (that is, cherry pick) the desired changes and resolve any code
|
||||
* Apply (that is, cherry-pick) the desired changes and resolve any code
|
||||
conflicts.
|
||||
* Run TensorFlow tests and ensure they pass.
|
||||
* [Build](https://www.tensorflow.org/install/source) the TensorFlow pip
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@
|
|||
* Optimized this function for some cases by fusing internal operations.
|
||||
|
||||
* `tf.saved_model.SaveOptions`
|
||||
* Provided a new `experimental_skip_saver` argument which if specified,
|
||||
* Provided a new `experimental_skip_saver` argument which, if specified,
|
||||
will suppress the addition of `SavedModel`-native save and restore ops
|
||||
to the `SavedModel`, for cases where users already build custom
|
||||
save/restore ops and checkpoint formats for the model being saved, and
|
||||
|
|
|
|||
|
|
@ -8,12 +8,12 @@ TensorFlow and how to report them.
|
|||
This document applies to other repositories in the TensorFlow organization,
|
||||
covering security practices for the entirety of the TensorFlow ecosystem.
|
||||
|
||||
## TensorFlow models are programs
|
||||
## TensorFlow's models are programs
|
||||
|
||||
TensorFlow
|
||||
[**models**](https://developers.google.com/machine-learning/glossary/#model) (to
|
||||
use a term commonly used by machine learning practitioners) are expressed as
|
||||
programs that TensorFlow executes. TensorFlow programs are encoded as
|
||||
programs that TensorFlow executes. TensorFlow's programs are encoded as
|
||||
computation
|
||||
[**graphs**](https://developers.google.com/machine-learning/glossary/#graph).
|
||||
The model's parameters are often stored separately in **checkpoints**.
|
||||
|
|
@ -31,7 +31,7 @@ The computation graph may also accept **inputs**. Those inputs are the
|
|||
data you supply to TensorFlow to train a model, or to use a model to run
|
||||
inference on the data.
|
||||
|
||||
**TensorFlow models are programs, and need to be treated as such from a security
|
||||
**TensorFlow's models are programs, and need to be treated as such from a security
|
||||
perspective.**
|
||||
|
||||
## Execution models of TensorFlow code
|
||||
|
|
@ -101,7 +101,7 @@ compare model quality for a fixed model architecture), you must carefully audit
|
|||
your model, and we recommend you run the TensorFlow process in a sandbox.
|
||||
|
||||
Similar considerations should apply if the model uses **custom ops** (C++ code
|
||||
written outside of the TensorFlow tree and loaded as plugins).
|
||||
written outside the TensorFlow tree and loaded as plugins).
|
||||
|
||||
## Accepting untrusted inputs
|
||||
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ AutoGraph turned off.
|
|||
* placing a Tensor-dependent `break`, `continue` or `return` inside a Python
|
||||
loop (see example below)
|
||||
* attempting to use a `tf.Tensor` in a list comprehension, by iterating over
|
||||
it or using it in a condition)
|
||||
it or using it in a condition
|
||||
|
||||
A typical example of mixing Python and TF control flow in an incompatible way
|
||||
is:
|
||||
|
|
@ -156,7 +156,7 @@ exceptions, expect them to be wrapped by this exception.
|
|||
This error usually appears in the context of a conversion warning. It indicates
|
||||
that a lambda function could not be parsed (see [Limitations](limitations.md)).
|
||||
|
||||
This type of errors can usually be avoided by creating lambda functions in
|
||||
This type of error can usually be avoided by creating lambda functions in
|
||||
separate simple assignments, for example:
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ In the example above, we've optimized away the conditional on a constant
|
|||
condition. The AutoGraph dispatch rules have the same effect: anything that is
|
||||
not a TensorFlow object is a compile-time constant for TensorFlow, and can be
|
||||
optimized away. For this reason, you can usually mix Python and TensorFlow
|
||||
computation and it will transparently have the expected result even
|
||||
computation, and it will transparently have the expected result even
|
||||
when only some computations are executed in the graph.
|
||||
|
||||
<!-- TODO(mdan): This is actually a limitation (a very subtle one) -->
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ exception inside `tf.function`, you will obtain the original exception.
|
|||
The exception traceback still contains the entire call stack, including frames
|
||||
corresponding to generated code.
|
||||
|
||||
AutoGraph tries to re-raise an exception of the same type as the original
|
||||
AutoGraph tries to re-raise an exception to the same type as the original
|
||||
exception. This is usually possible for subclasses of
|
||||
`Exception` that do not define a custom `__init__`. For more complex
|
||||
exception types which define a custom constructor, AutoGraph raises a
|
||||
|
|
@ -144,7 +144,7 @@ refer to symbols used in your code.
|
|||
|
||||
### TensorFlow execution errors
|
||||
|
||||
TensorFlow execution errors are displayed normally, but the portions of the
|
||||
TensorFlow's execution errors are displayed normally, but the portions of the
|
||||
error message which correspond to user code contain references to the original
|
||||
code.
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ are handled correctly.
|
|||
The following types of functions are not converted:
|
||||
|
||||
* functions already converted
|
||||
* functions defined in a allowlisted module (see autograph/core/config.py)
|
||||
* functions defined in an allowlisted module (see autograph/core/config.py)
|
||||
* non-Python functions (such as native bindings)
|
||||
* `print`, `pdb.set_trace`, `ipdb.set_trace`
|
||||
* most built-in functions (exceptions are listed in
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ tf.print(x) # Error -- x may be None here
|
|||
```
|
||||
|
||||
For this reason, AutoGraph forbids variables to be defined in only one branch
|
||||
of a TensorFlow conditional, if the variable is used afterwards:
|
||||
of a TensorFlow conditional, if the variable is used afterward:
|
||||
|
||||
```
|
||||
del x
|
||||
|
|
@ -172,7 +172,7 @@ The examples below use a `while` loop, but the same notions extend to all
|
|||
control flow such as `if` and `for` statements.
|
||||
|
||||
In the example below, `x` needs to become a loop variable of the
|
||||
corresponding `tf.while_loop':
|
||||
corresponding 'tf.while_loop':
|
||||
|
||||
```
|
||||
while x > 0:
|
||||
|
|
@ -343,7 +343,7 @@ recognizes.
|
|||
|
||||
AutoGraph assumes that variables that local functions close over may be used
|
||||
anywhere in the parent function, because in general it is possible to hide a
|
||||
function call in almost any Python statement). For this reason, these variables
|
||||
function call in almost any Python statement. For this reason, these variables
|
||||
are accounted within TensorFlow loops.
|
||||
|
||||
For example, the following code correctly captures `a` in the TensorFlow loop
|
||||
|
|
@ -358,7 +358,7 @@ for i in tf.range(3):
|
|||
f() # Prints 2
|
||||
```
|
||||
|
||||
An consequence is that these variables must be defined before the loop (see
|
||||
A consequence is that these variables must be defined before the loop (see
|
||||
Undefined and None values above). So the following code will raise an error,
|
||||
even if the variable is never used after the loop:
|
||||
|
||||
|
|
@ -462,7 +462,7 @@ for i in tf.range(10):
|
|||
|
||||
#### Python collections of fixed structure are allowed TensorFlow control flow
|
||||
|
||||
An exception from the previous rule is made by Python collections that are
|
||||
An exception to the previous rule is made by Python collections that are
|
||||
static, that is, they don't grow in size for the duration of the computation.
|
||||
|
||||
Caution: Use functional programming style when manipulating static collections.
|
||||
|
|
@ -503,7 +503,7 @@ for i in tf.range(10):
|
|||
d[key] += i # Problem -- accessing `dict` using non-constant key
|
||||
```
|
||||
|
||||
The code above will raises an "illegal capture" error. To remedy it, write it
|
||||
The code above will raise an "illegal capture" error. To remedy it, write it
|
||||
in functional programming style:
|
||||
|
||||
```
|
||||
|
|
@ -530,7 +530,7 @@ rank is dynamic.
|
|||
|
||||
TensorFlow has optional static types and shapes: the shape of tensors may be
|
||||
static (e.g. `my_tensor.shape=(3, 3)` denotes a three by three matrix) or
|
||||
dynamic (e.g. `my_tensor.shape=(None, 3)` denotes a matrix with a dynamic
|
||||
dynamic (e.g. `my_tensor.shape=(None, 3)`) denotes a matrix with a dynamic
|
||||
number of rows and three columns. When the shapes are dynamic, you can still
|
||||
query it at runtime by using the `tf.shape()` function.
|
||||
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ Generally, the dispatch follows these rules:
|
|||
|
||||
The first rule above means that if you convert normal, non-TensorFlow code with
|
||||
AutoGraph and call it with non-TensorFlow inputs, executing the generated code
|
||||
should be no different than executing the original.
|
||||
should be no different from executing the original.
|
||||
|
||||
### Functional form
|
||||
|
||||
|
|
@ -95,7 +95,7 @@ Args:
|
|||
cond: expression condition; same as `cond` in `_ if cond else _`.
|
||||
if_true: true value (as thunk); same as `lambda: x` in `x if _ else _`.
|
||||
if_false: false value (as thunk); same as `lambda: x` in `_ if _ else x`.
|
||||
expr_repr: human readable string representing `cond`. Used for error messages.
|
||||
expr_repr: human-readable string representing `cond`. Used for error messages.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -147,7 +147,7 @@ Args:
|
|||
<b>`.
|
||||
* get_state: returns the current value of the loop variables
|
||||
* set_state: sets new values into the loop variables
|
||||
* symbol_names: human readable string representing each loop variable. Used
|
||||
* symbol_names: human-readable string representing each loop variable. Used
|
||||
for error messages.
|
||||
* opts: additional, implementation-specific, keyword arguments.
|
||||
|
||||
|
|
@ -232,7 +232,7 @@ Args:
|
|||
<b>`.
|
||||
* get_state: returns the current value of the conditional variables
|
||||
* set_state: sets new values into the conditional variables
|
||||
* symbol_names: human readable string representing each conditional variable.
|
||||
* symbol_names: human-readable string representing each conditional variable.
|
||||
Used for error messages.
|
||||
* nouts: number of output conditional variables. Not all conditional variables
|
||||
are outputs - some are just inputs. The first nouts values in get_state and
|
||||
|
|
@ -280,7 +280,7 @@ Args:
|
|||
* body: loop body (as thunk); same as `def body(): <b>` in `while _: <b>`.
|
||||
* get_state: returns the current value of the loop variables
|
||||
* set_state: sets new values into the loop variables
|
||||
* symbol_names: human readable string representing each loop variable. Used
|
||||
* symbol_names: human-readable string representing each loop variable. Used
|
||||
for error messages.
|
||||
* opts: additional, implementation-specific, keyword arguments.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user