PiperOrigin-RevId: 339961597

For now measurements are aggregated by SumFactory, but we will add support in the future for private measurements aggregation.

Also:
  1. Change state to OrderedDict (from tuple).
  2. Change default zeroing norm order from np.inf to 2 for ease of transition between ZeroingFactory and ZeroingClippingFactory (which must use 2-norm), and use tf.linalg.global_norm if norm order is 2, for efficiency.
PiperOrigin-RevId: 339908232

PiperOrigin-RevId: 339805559

PiperOrigin-RevId: 339804460

PiperOrigin-RevId: 339801656

PiperOrigin-RevId: 339684912

This backend is a good place to construct contexts that can be used for testing.

* Added a test backend.
* Added an `execution_context` which can execute `federated_secure_sum` intrinsics.

PiperOrigin-RevId: 339579125

PiperOrigin-RevId: 339523983

PiperOrigin-RevId: 339382611

PiperOrigin-RevId: 339340854

Certain TensorFlow APIs (e.g. C++ callable API) fail if feeds and fetches are identical. TFF introduces identity graphs in order to reason about invariants in its compilation to TensorFlow, and indeed passes them through directly in the case of compiling (x -> x) to TensorFlow. This change prevents feeds and fetches from being identical in these graphs.

PiperOrigin-RevId: 339320146

The API changed to request the factory, rather than the executor.

PiperOrigin-RevId: 339291526

PiperOrigin-RevId: 339278080

PiperOrigin-RevId: 339271404

PiperOrigin-RevId: 339245271

* Removes the complicated `tf.TensorArray`s and TF control flow in `build_personalize_fn`, and uses the simpler Python control flow.
* Adds type annotations and module-level constants.
* Improves the docstring.

PiperOrigin-RevId: 339174601

PiperOrigin-RevId: 339136371

Introduces ClippingFactory, ZeroingFactory, and ZeroingClippingFactory for aggregation after clipping/zeroing large values.

PiperOrigin-RevId: 339116405

PiperOrigin-RevId: 338680584

This also cleans up some other shared functionlity
in form_utils and clarifies the ordering of
(context_from_server, client_data) parameters in
both broadcast-form-able computations and in
`BroadcastForm.client_processing`. This aligns
with `IterativeProcess`, but does not match `work`.

PiperOrigin-RevId: 338553479

PiperOrigin-RevId: 338499217

PiperOrigin-RevId: 338360194

Fixed bug in RemoteExecutor which could cause it to hang in streaming mode if the connection fails before messages are sent.

PiperOrigin-RevId: 338284054

PiperOrigin-RevId: 338282399

PiperOrigin-RevId: 338088240

PiperOrigin-RevId: 338087663

PiperOrigin-RevId: 338076995

PiperOrigin-RevId: 337964148

```
TypeError: Expected tensorflow.python.ops.variables.Variable, found tensorflow.python.keras.engine.base_layer_utils.TrackableWeightHandler.
```
PiperOrigin-RevId: 337961843

PiperOrigin-RevId: 337958997

Instead insert a `tf.function` decorator before (underneath) the
`tff.tf_computation` decorator, and enter a `tf.init_scope` context during
`tf.Variable` creation. The `tf.init_scope` hoists variable creation out of the
`tf.function` to the nearest graph scope (provided by `tff.tf_comptuation`),
which would otherwise result in an error from the the `tf.function` wrapper.

More details on `tf.Variable` in `tf.function`:
https://www.tensorflow.org/guide/function#variables

Longer term, it may be nice to fold this automatic wrapping into the
`tff.tf_computation` decorator, or re-introduce as `tff.tf2_computation`,
however this requires all users to know they must use `tf.init_scope` during
variable creation. Inside TFF packages (e.g.  `tff.learning`) we can handle
this for them, but its an extra point of concern for custom algorithm writers.

PiperOrigin-RevId: 337935371

Using `attr.s` classes as TFF type specifications has usability issues when used in conjunction with python static type checking. Mixing python type checking with TF and TFF types does not work well. This functionality will be removed in a future release.

PiperOrigin-RevId: 337578239

This enables support for Python 3.8, which changed behavior of `_asdict` to
return regular `dict` types.
https://docs.python.org/3/library/collections.html#collections.somenamedtuple._asdict

PiperOrigin-RevId: 337559550

This change moves the `apply` method inside the `EstimationProcess` class, and renames it as `map`. It also updates the tests to be consistent with the pattern in the other processes in templates.

PiperOrigin-RevId: 337424574

Adds DifferentiallyPrivateFactory, an AggregationProcessFactory for DPQueries from tensorflow_privacy.

PiperOrigin-RevId: 337400971

This is a sibling
to CanonicalForm which is intended to represent a
new task type which involves only server work +
broadcast + client work with no final aggregation.

My hope is to reuse much of the existing CanonicalForm
compilation infrastructure for compiling to this form
(that is, sharing much of canonical_form_utils.py
between both forms). An alternative approach would be
to slightly extend and re-use CanonicalForm by adding
a client output and checking to ensure that the arguments
to the aggregation functions are empty structures. I'm
not strongly opposed to that formulation, but have
developed a weak preference for this approach in order
to reduce overloading and layering of complexity on top
of the existing system. My hope is that the approach taken
in this CL will encourage work towards easier
development of varied computation "shape" definitions.

PiperOrigin-RevId: 337184931

PiperOrigin-RevId: 337038042

Change the shape of "class" from [] to [1]

PiperOrigin-RevId: 336980750

Much of the existing complication was unnecessary
since the change to make `intrinsics.federated_zip`
recursive.

PiperOrigin-RevId: 336967098

Fixes pytype mismatch in optimizer_utils, adding extra typing info in federated_averaging and federated_sgd.

PiperOrigin-RevId: 336957857