This project is mirrored from https://github.com/tensorflow/federated. Pull mirroring failed .
Last successful update .
  1. 05 Nov, 2020 1 commit
    • Michael Reneer's avatar
      Fix PY 3.8 warning about using ABCs from `collections`. · c40e3083
      Michael Reneer authored
      Do not use or import the ABCs from `collections`, this is deprecated since Python 3.3, and in 3.9 it will stop working. These ABCs have moved to 'collections.abc' and should be used from this package.
      
      PiperOrigin-RevId: 340678321
      c40e3083
  2. 29 Jul, 2020 1 commit
  3. 25 Jul, 2020 1 commit
  4. 24 Jul, 2020 1 commit
  5. 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`
      functions.
      
      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
      4ed574ab
  6. 15 Jul, 2020 1 commit
    • Keith Rush's avatar
      Uses bytes of ndarray instead of string rep of flatten. · 6ca78bc5
      Keith Rush authored
      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
      6ca78bc5
  7. 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
      91dd2a0e
  8. 17 Jun, 2020 1 commit
  9. 16 Jun, 2020 1 commit
  10. 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
      f3d1d0be
  11. 29 May, 2020 1 commit
  12. 20 May, 2020 1 commit
  13. 08 May, 2020 2 commits
  14. 14 Feb, 2020 1 commit
    • Taylor Cramer's avatar
      Use an LRU cache for unbound reference checking · 65405057
      Taylor Cramer authored
      Previously, we would store an unbounded number of
      cache entries for this function. This CL changes
      that to use an LRU cache so that we don't grow the
      cache indefinitely.
      
      PiperOrigin-RevId: 295031712
      65405057
  15. 12 Feb, 2020 1 commit
  16. 07 Feb, 2020 1 commit
  17. 06 Feb, 2020 1 commit
  18. 25 Jan, 2020 1 commit
    • Taylor Cramer's avatar
      Delete cache across executor close · 2e545818
      Taylor Cramer authored
      The test added here fails before this CL with "futures are tied to different event loops"
      
      This CL clears the cache in the caching executor on close.
      Other executors, such as the concurrent and remote executors,
      rely on values they produce not being reused across a call to `close`.
      
      It may be that we need to change when `close` is called in order to allow
      some resources to be reused between top-level calls to federated computations,
      but in any case we need for the cache to be cleared at the same time that
      the remote executor or concurrent executor threads are cleaned up.
      
      PiperOrigin-RevId: 291426443
      2e545818
  19. 17 Jan, 2020 1 commit
  20. 03 Jan, 2020 1 commit
  21. 20 Dec, 2019 1 commit
  22. 10 Dec, 2019 1 commit
    • Zachary Garrett's avatar
      Invalidate the entire cache when the underlying executor raises an execption. · 70d3b5d3
      Zachary Garrett authored
      This is a heavy hammer. We should follow-up, there maybe a better approach such
      as subclassing RetryableError into an error that signals the underlying
      Executor was restarted.
      
      This avoids double delete errors in caching executor dictionary (a current
      problem).  This can happen if two callers start awaiting a future from the
      inner executor that fails and they both try to cleanup.
      
      PiperOrigin-RevId: 284568338
      70d3b5d3
  23. 07 Dec, 2019 1 commit
  24. 16 Nov, 2019 2 commits
  25. 16 Oct, 2019 1 commit
  26. 05 Sep, 2019 1 commit
  27. 27 Aug, 2019 1 commit
  28. 20 Aug, 2019 1 commit
  29. 16 Aug, 2019 1 commit
  30. 10 Aug, 2019 1 commit
  31. 07 Aug, 2019 2 commits
  32. 06 Aug, 2019 1 commit