This project is mirrored from Pull mirroring failed .
Last successful update .
  1. 10 Nov, 2020 1 commit
  2. 22 Oct, 2020 1 commit
  3. 11 Sep, 2020 1 commit
  4. 13 Aug, 2020 1 commit
  5. 05 Aug, 2020 2 commits
  6. 04 Aug, 2020 1 commit
  7. 29 Jul, 2020 1 commit
  8. 25 Jul, 2020 2 commits
  9. 24 Jul, 2020 1 commit
  10. 23 Jul, 2020 1 commit
  11. 22 Jul, 2020 1 commit
  12. 18 Jul, 2020 1 commit
    • Taylor Cramer's avatar
      Propagate container_type and include it in type equality checks. · 4ed574ab
      Taylor Cramer authored
      Previously, NamedTupleTypeWithPyContainerType was often lost and turned into
      a NamedTupleType without the container. This resulted in users being given
      AnonymousTuples when a more specific container should have been returned.
      This change fixes a large number of sites where container types were lost, and
      adjusts usage sites as appropriate, including the removal of `from_tff_result`
      This change also makes the `__eq__` function for
      `NamedTupleTypeWithPyContainerType` require equivalent container types, rather
      than just equivalent field structure. Call sites that wished to compare only
      field structure are adjusted to use `Type.{is, check}_equivalent_to`.
      PiperOrigin-RevId: 321883012
  13. 23 Jun, 2020 1 commit
    • Taylor Cramer's avatar
      Modifications from profiling, including removal of `isinstance` casing · 91dd2a0e
      Taylor Cramer authored
      These are modifications I made in order to speed up the workload timing
      out in serialization + deserialization in b/156371202. I intend to follow
      it with a change to intern types, whose serialization, deserialization, and
      comparison is currently causing exponential blowups due to the nested
      structure of type signatures and the frequency with which they occur
      throughout the AST (one full copy per node).
      The biggest change in this CL comes from the move away from using
      `isinstance` to case over AST blocks and type nodes. This change was motivated
      by a few factors:
      - It's significantly faster (a single method lookup vs. type tree traversal).
      - It clarifies which `isinstance` checks are dynamic Python "downcasts" vs.
        "switch"es on a kind of sum-type. The downcast-like spots are in my opinion
        more suspect and should be subject to a decent bit of scrutiny when added,
        while switches on a sum-type should not be cause for concern.
      - I personally find it more ergonomic and easier to read:
        `my_structure.is_lambda()` vs.
        `isinstance(my_structure, computation_types.Lambda)`
      Some other performance-motivated changes included here are:
      - Caching the list-of-tuples representation of AnonymousTuples.
      - Moving formatting of error messages out of the success path.
      - Removing the `are_equivalent_types` check on building blocks
        which ensured that the deserialized type of a building block
        matched the type of the deserialized building block. This
        check isn't exactly redundant, but given correct serialization
        and deserialization it will never trigger, and it is extremely
        expensive (expontentially complex). This may be worth looking
        into reenabling once I've landed a change to intern Types.
      - Removing the `check_well_formed` on building blocks __init__.
        This is similar to the above in that it should be unnecessary
        given correct TFF code, and is extremely expensive. As above,
        it may be worth trying to enable when we start interning types.
      - I did *not* disable the `is_concrete_instance_of` check on
        the `Intrinsic` building block, which is also quite expensive.
        I think this one is rather higher-value than the two above,
        but this is totally a judgement call as they are all quite
        costly and scale exponentially in time with the depth of the
        type tree. This should also hopefully be much cheaper once
        we have type interning.
      - Moving the type tree visitor to internal iteration.
        I did not do the same for the building block visitor yet, since
        it has more visitors of varied shape and complexity, but I think
        this is worth investigating in the future.
      PiperOrigin-RevId: 317769828
  14. 18 Jun, 2020 1 commit
  15. 12 Jun, 2020 1 commit
    • Taylor Cramer's avatar
      Move typechecking functions to public tff.Type API · f3d1d0be
      Taylor Cramer authored
      These functions are more often than not what is wanted
      rather than __eq__ checks on types, yet they were
      previously hidden inside of core/impl. This change
      moves them to `tff.Type` methods so that they can be
      used elsewhere (such as in tff.learning).
      PiperOrigin-RevId: 315957012
  16. 28 May, 2020 1 commit
  17. 22 May, 2020 1 commit
  18. 20 May, 2020 1 commit
  19. 16 May, 2020 1 commit
    • Michael Reneer's avatar
      Move `type_utils` conversion functions to the `types` package. · 06be556d
      Michael Reneer authored
      convert_to_py_container -> type_to_py_container
      to_non_all_equal -> type_to_non_all_equal
      Note: The "type" prefix is retained here to make the public API a little clearer. (e.g. tff.framework.type_to_tf_dtypes_and_shapes)
      PiperOrigin-RevId: 311838556
  20. 14 May, 2020 1 commit
  21. 12 May, 2020 1 commit
  22. 08 May, 2020 2 commits
  23. 14 Apr, 2020 1 commit
  24. 04 Apr, 2020 1 commit
  25. 19 Mar, 2020 1 commit
  26. 10 Mar, 2020 1 commit
    • Scott Wegner's avatar
      Support dict-like syntax for extracting values from federated values by key. · 2ece44d6
      Scott Wegner authored
      This is a convenience for working with values within a federated computation. Now, individual values can be extracted from the structure using:
        val = my_federated_computation()
      This is already possible using `getattr(val, 'foo')`; this change makes the existing functionality more discoverable.
      PiperOrigin-RevId: 299975964
  27. 19 Feb, 2020 1 commit
  28. 14 Feb, 2020 1 commit
  29. 08 Feb, 2020 1 commit
    • Taylor Cramer's avatar
      Add intrinsic federated_eval · f3694f0a
      Taylor Cramer authored
      This intrinsic is similar to federated_value, but accepts a no-argument lambda
      rather than an unplaced value. This will clarify the behavior of the intrinsic
      (eval on all clients separately rather than eval and then broadcast), and
      unblocks the effort to ban unplaced values.
      PiperOrigin-RevId: 293898477
  30. 03 Jan, 2020 3 commits
  31. 31 Dec, 2019 2 commits
  32. 16 Nov, 2019 3 commits