| Commit message (Collapse) | Author | Age |
|
|
|
| |
PiperOrigin-RevId: 216443201
|
|
|
|
| |
PiperOrigin-RevId: 216400726
|
|
|
|
| |
PiperOrigin-RevId: 216395709
|
|
|
|
| |
PiperOrigin-RevId: 216370193
|
|
|
|
| |
PiperOrigin-RevId: 216280913
|
|
|
|
|
|
|
|
|
| |
Previously, we were passing the first (graph-level) seed for both the
graph-level and op-level seeds when creating a C++ dataset. This
change passes the op-level seed to the appropriate point, and adds a test
for the behavior with graph-but-not-op-level seeds.
PiperOrigin-RevId: 216280641
|
|
|
|
| |
PiperOrigin-RevId: 216260575
|
|
|
|
| |
PiperOrigin-RevId: 216256115
|
|
|
|
|
|
|
|
|
|
| |
This changes the behavior of randomness-introducing datasets (`tf.data.Dataset.shuffle()`, `tf.data.experimental.shuffle_and_repeat()`, and `tf.data.experimental.RandomDataset`). Previously, when you used the same `tf.data.Dataset` object multiple times in a pipeline (e.g. by zipping two datasets derived from the same randomness-introducing dataset) *and* you did not specify an explicit `seed`, the implementation would choose different non-deterministic seeds for each use of the `Dataset` object.
With this change, the seed will be chosen once per `Dataset` (technically, once per `Dataset`-`Graph` combination, due to the vagaries of capturing state in `Dataset.make_one_shot_iterator()`), which means that all uses of the same dataset object will observe the same sequence of values.
This change also revealed a small bug in how `Dataset.shuffle(..., reshuffle_each_iteration=False)` is serialized when an explicit seed is specified. The op-level seed was dropped, which could lead to non-deterministic behavior. This change fixes that issue by forwarding the op-level seed to the appropriate place.
PiperOrigin-RevId: 216248013
|
|
|
|
| |
PiperOrigin-RevId: 216247929
|
|\
| |
| |
| | |
PiperOrigin-RevId: 216217509
|
| |
| |
| |
| |
| |
| | |
`MapAndBatchDataset` whose user-provided functions have the property that each output argument take its value directly from an input argument (e.g. `lambda x, y: y, x`). This specialization can produce the result without having to schedule the function using the executor.
PiperOrigin-RevId: 216206232
|
| |
| |
| |
| | |
PiperOrigin-RevId: 216205396
|
|\ \
| | |
| | |
| | | |
PiperOrigin-RevId: 215995215
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
stateless_random_uniform now take minval+maxval and handles ints,
and stateless_normal/stateless_truncated_normal take mean+stddev.
Additionally, all of the stateless functions now have proper doc
strings.
This is step one of moving stateless random numbers out of contrib.
|
| | |
| | |
| | |
| | | |
PiperOrigin-RevId: 215969360
|
| | |
| | |
| | |
| | |
| | |
| | | |
`MapAndBatchDataset` whose user-provided functions have the property that each output argument take its value directly from an input argument (e.g. `lambda x, y: y, x`). This specialization can produce the result without having to schedule the function using the executor.
PiperOrigin-RevId: 215957592
|
| | |
| | |
| | |
| | |
| | |
| | | |
(used to be a segfault)
PiperOrigin-RevId: 215791737
|
| | |
| | |
| | |
| | | |
PiperOrigin-RevId: 215788485
|
| | |
| | |
| | |
| | | |
PiperOrigin-RevId: 215780734
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
"character" is treated:
* BYTE: Position & length refer to bytes in the string. (Default)
* UTF8: The string is interpreted as UTF-8 encoded Unicode code points, and position & length are treated relative to them.
RELNOTES: Add option to get substring using Unicode characters
PiperOrigin-RevId: 215773373
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously, we were returning an unknown shape in
`Dataset::output_shapes()` for the "most specific compatible shape"
between the two inputs. While this does not cause correctness problems
(since the unknown shape *is* compatible), we gain the ability to
raise errors earlier when more shape information is available.
PiperOrigin-RevId: 215764530
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
During graph construction, the shape function for AssignAddVariableOp etc.
would raise an error when the value being "assign add"ed to the variable
has an incompatible shape.
With eager execution, no such validation was being made which triggerred
an assertion failure in eigen:
https://github.com/eigenteam/eigen-git-mirror/blob/7d97e1cbbe4424fda39e31c88def7c0863897640/unsupported/Eigen/CXX11/src/Tensor/TensorEvaluator.h#L479
This change prevents that assertion failure.
PiperOrigin-RevId: 215749071
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, if the rank of the input to this transformation was
statically unknown, we would erroneously report that the output is a
scalar, and violate downstream shape integrity checks. Instead, in
that case the output shape should be unknown.
PiperOrigin-RevId: 215683027
|
| |
| |
| |
| |
| |
| |
| |
| | |
`set_stats_aggregator`. `tag` would get prep-end with all the statistics recorded as summary and `counter_prefix` would set the prefix for the statistics recorded as counter.
Note: `counter` defaults to `\tensorflow`, and `tag` and `prefix` gets associated with the dataset (not the stats_aggregator).
PiperOrigin-RevId: 215609159
|
| |
| |
| |
| | |
PiperOrigin-RevId: 215607038
|
| |
| |
| |
| | |
PiperOrigin-RevId: 215579950
|
| |
| |
| |
| |
| |
| | |
`tf.data.Dataset.with_options()` to make it possible to respectively represent, get, and set options, such as optimization configuration, of a tf.data input pipeline.
PiperOrigin-RevId: 215310764
|
| |
| |
| |
| |
| |
| | |
coordination.
PiperOrigin-RevId: 215309735
|
| |
| |
| |
| | |
PiperOrigin-RevId: 215269882
|
| |
| |
| |
| | |
PiperOrigin-RevId: 215248737
|
|\ \
| | |
| | |
| | | |
PiperOrigin-RevId: 215161850
|
| | |
| | |
| | |
| | |
| | |
| | | |
kernel supports any combination of the dtypes, and does not need a separate kernel for each dtype.
PiperOrigin-RevId: 215019812
|
| | |
| | |
| | |
| | | |
PiperOrigin-RevId: 215019058
|
| | |
| | |
| | |
| | | |
PiperOrigin-RevId: 214997213
|
| | |
| | |
| | |
| | | |
PiperOrigin-RevId: 214986756
|
|\ \ \
| | | |
| | | |
| | | | |
PiperOrigin-RevId: 214983237
|
| | | |
| | | |
| | | |
| | | | |
PiperOrigin-RevId: 214964640
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
with associated stats_aggregator.
PiperOrigin-RevId: 214961678
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
dependency
only to the sparse operators that need it.
Automated rollback of commit 120620caf23a044b8aa2db6ba5984384ec936009
PiperOrigin-RevId: 214950946
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
NOTE: All ops and kernels previously previously defined in
tensorflow/contrib/data have had their name prefixed with
"Experimental" to indicate that they are not (yet) stable, and thus
not subject to backwards or forwards compatibility guarantees.
PiperOrigin-RevId: 214940819
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
with the case when the background thread terminated because the iterator
finished and yet some other requests were coming in.
1. The GetNextFromShard would see an empty buffer and return cancelled instead
of OutOfRange errors
2. On shutdown, we weren't calling all the pending callbacks.
Tested with runs_per_test=5000
PiperOrigin-RevId: 214939274
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
(finite) dataset to a single element.
PiperOrigin-RevId: 214852364
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
PiperOrigin-RevId: 214821528
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Before this change, a CollectiveOp user was required to specify subdiv_offsets
for the RingReduce algorithm. During ring reduction, we created chunks of the
tensor to exchange between devices. If the chunks were too large, or if the
hardware supported multiple data exchanges in parallel, the user could further
subdivide the chunk by specifying more than 1 subdiv offset. Each subdiv
offset corresponded to another subdivision of the chunk, so effectively the
total number of tensor chunks is number of devices * number of subdivs.
After this change, we can dynamically infer the number of subdivisions based on
a target chunk size. In ring_reducer.cc, we start with 1 subdiv, and keep
increasing until chunk size is less than MAX_CHUNK_SIZE. Currently,
MAX_CHUNK_SIZE is set at 4 MB, although it may make sense to change this based
on specific hardware.
As a part of this change, a user can now provide an empty subdiv_offset list.
If empty, we dynamically add subdivisions based on the above algorithm. If
non-empty, we take the user-specified subdivions.
PiperOrigin-RevId: 214815959
|
| | | |\ \
| |_|_|/ /
|/| | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
based on standard ranges.
PiperOrigin-RevId: 214796357
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 214726180
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 214700693
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
PiperOrigin-RevId: 214691838
|