Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change Config and UserConfig to allow recursive nesting of dictionaries #4574

Open
scarere opened this issue Nov 22, 2024 · 0 comments
Open
Labels
part: misc framework Issue/PR for general applications for Flower framework. state: stale If issue/PR hasn't been updated within 3 weeks. type: feature request This issue or comment suggests an additional feature.

Comments

@scarere
Copy link

scarere commented Nov 22, 2024

Describe the type of feature and its functionality.

Currently both Config and User config are defined as arbitrary dictionaries with string keys and Scalar values. This requires the user to have knowledge of what the string keys are in order to access the values they packed into the config. Why not allow the values to also include dictionaries so long as the end values are always Scalars. This can be done with a recursive typing definition. It would allow more organized config and userconfig dictionaries. Furthermore we have a specific use case where we need to pass a highly nested dictionary loaded from a json file from the server to the client. There are too many key-value pairs to make it worth it to unnest the whole thing. Right now we are getting around it by serializing the dictionary so that it can be passed as a scalar Bytes value and then unserializing it on the client. Ideally we could skip the serialization step. However, the UserConfig type used in the Context class does not allow bytes values. We are not making use of the Context objects yet, but are considering it as a good way to store state information. Although one of the state objects is another nested dictionary.

I think this is a good change so long as it does not significantly interfere with other parts of the library. There might even be some other dictionary types in flwr.common.typing that could benefit from a recursive definition. Namely the Properties type and perhaps even the Metrics type. Although you might need to modify the aggregation function to recursively search the dictionary until it finds a scalar value to aggregate, but that would be worth the hassle in my opinion to allow more organized dictionary types

Describe step by step what files and adjustments are you planning to include.

For python, I believe the change is simple. Not sure if there would be any downstream effects. Here is an example of some changes to flwr.common.typing

Metrics = dict[str, Union[Scalar, 'Metrics']]
Config = dict[str, Union[Scalar, 'Config']]
Properties = dict[str, Union[Scalar, 'Properties']]
UserConfig = dict[str, Union[UserConfigValue, 'UserConfig']]

Is there something else you want to add?

No response

@scarere scarere added the type: feature request This issue or comment suggests an additional feature. label Nov 22, 2024
@WilliamLindskog WilliamLindskog added state: stale If issue/PR hasn't been updated within 3 weeks. part: misc framework Issue/PR for general applications for Flower framework. labels Dec 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
part: misc framework Issue/PR for general applications for Flower framework. state: stale If issue/PR hasn't been updated within 3 weeks. type: feature request This issue or comment suggests an additional feature.
Projects
None yet
Development

No branches or pull requests

2 participants