PiperOrigin-RevId: 321639468

PiperOrigin-RevId: 321617729

PiperOrigin-RevId: 321611005

A problem shows up with using subclasses of `tff.learning.Model`: after wrapping the model as an EnhancedModel, one cannot access the methods that are specifically defined by the subclass model.

This CL removes the EnhancedModel wrapper used when computing baseline metrics and training personalized models. This makes sure that users can access the full functionality of the model returned by `model_fn`.

PiperOrigin-RevId: 321578480

PiperOrigin-RevId: 321431928

PiperOrigin-RevId: 321423023

* Removed the `tff.framework.set_default_executor` API.
* Updated the callers to use the higher-level convienent API `tff.backends.*` instead.

PiperOrigin-RevId: 321421612

PiperOrigin-RevId: 321411362

PiperOrigin-RevId: 321393738

PiperOrigin-RevId: 321378169

PiperOrigin-RevId: 321268189

PiperOrigin-RevId: 321266409

PiperOrigin-RevId: 321265603

This change adds a compiler function to the `ExecutionContext` object. Conceptually a `Context` can be thought of as an "environment" which owns compilation and owns execution for a given computation. Additionally, this change replaces `set_default_executor` with higher level functions in order to simplify how contexts are constructed.

* Added compiler function to the `ExecutionContext`.
* Deprecated `set_default_executor`.
* Removed all usage of `set_default_executor` internally.
* Added convenience high level functions that set an execution context:
  * tff.backends.native.set_local_execution_context
* Updated `set_default_executor` call-sites to either use the convenience high level functions or to manually construct a context and use `set_default_context`.

Note that we should consider creating the following convenience high level functions:
  * tff.backends.native.set_remote_execution_context
  * tff.backends.native.set_sizing_execution_context
  * tff.backends.iree.set_iree_execution_context

PiperOrigin-RevId: 321263709

Semantic changes:
-  Use the LR schedule with round 0 during the server intializiation.
   Previously this relied on the optimizer builder specifying a default for the
   learning rate, which was overriden in later rounds. Explicitly call with a
   "round 0" learning rate to ensure the documented type is adhered to. This
   can be seen in the type annotations for the `server_optimizer_fn` argument
   to `build_server_init_fn` and `build_fed_avg_process`.

PiperOrigin-RevId: 321237803

Taking string rep of flattened ndarray can cause non-equal ndarrays to hash to identical values.

E.g., added test here failed previously--arrays that have identical values on the ends of their flattened reps, but differ in the middle, will result in the same key.

PiperOrigin-RevId: 321234171

PiperOrigin-RevId: 321234129

There are a few users to consider:

1. A developer on TFF wants source at HEAD.
2. A researcher using TFF wants pip package at release in 90% of scenarios and sometimes (ideally rarely) wants nightly, but never wants to build a pip package.
3. A developer making a framework using TFF wants pip release and nightly, but never wants to build a pip package.
4. A researcher upstreaming change to TFF basically has moved from #2 to #3.

Fixes: #878
PiperOrigin-RevId: 321226038

Explicitly raise a (clearer) error message when models end up in invalid states due to interleaving graph and eager.

In rare cases code may have run w/o crashing when in these invalid states, but it's safer to error with an explanation rather than risk silent failures/fragile behavior.

PiperOrigin-RevId: 321192744

TrainableModel has been removed from TFF for a while.

PiperOrigin-RevId: 321184501

PiperOrigin-RevId: 320693256

PiperOrigin-RevId: 320643179

PiperOrigin-RevId: 320624398

  * Fixes `building_blocks.Block` traversal in `transform_preorder`.
  * Extends `unwrap_placement` to handle no-arg lambdas.

PiperOrigin-RevId: 320601917

PiperOrigin-RevId: 320416185

PiperOrigin-RevId: 320284158

PiperOrigin-RevId: 320269759

PiperOrigin-RevId: 320264910

PiperOrigin-RevId: 320255379

PiperOrigin-RevId: 320200437

PiperOrigin-RevId: 320026302

PiperOrigin-RevId: 320014281

In response to #875

PiperOrigin-RevId: 320013295

This is part of the current refactoring of the HLO related dialect.
`xla_hlo` will be reintroduced in a new form later.

PiperOrigin-RevId: 319916753

The type signature of `work` was <client_data, state> -> <client_updates, client_stats> where client_updates = <simple_agg, secure_agg>. After this CL, the type signature of `work` becomes <client_data, state> -> client_updates.

* `canonical_form.py`: remove `client_outputs` from `work`; update doc.

* `canonical_form_utils.py`: remove c8 from the canonical form, and change c7 to c6 and c6 to c5; remove `_create_next_with_fake_client_output` function.

* Remove `client_outputs` from `test_utils.py`.

PiperOrigin-RevId: 319873694

PiperOrigin-RevId: 319868133

PiperOrigin-RevId: 319322191

PiperOrigin-RevId: 319316718

PiperOrigin-RevId: 319311286