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

Differences between Model and LightModel #37

Open
MatthewCaseres opened this issue Apr 11, 2024 · 4 comments
Open

Differences between Model and LightModel #37

MatthewCaseres opened this issue Apr 11, 2024 · 4 comments

Comments

@MatthewCaseres
Copy link
Collaborator

MatthewCaseres commented Apr 11, 2024

I'm starting up some docs and it isn't clear how to motivate the difference in the models. from a historical perspective, I wanted to do my own thing and contribute to a group effort without breaking existing stuff.

How do we communicate this to users in a way that isn't confusing? Do I just say

LightModel is like Model but it implements memory optimizations, automatic aggregations, and has a slightly different API

and move on from it? Is there anything to really be done from a source code perspective here that would be easy to do?

@lewisfogden
Copy link
Owner

I'd like us to converge on one API, and then ideally merge the models. (potentially making the optimisations a flag like proj_len).

Other option would be to note one as a 'reference implementation', and then allow variations as long as they include the basic features.

I feel like we should handle the aggregations separately somehow, they are quite specific to the backend you choose, e.g. numpy, pytorch etc. Other option is to decide which backends we support, so single value, numpy, pytorch, arrow?

@MatthewCaseres
Copy link
Collaborator Author

MatthewCaseres commented Apr 11, 2024

one model

Agree on this. I'm biased but I would be fine with using the current LightModel as the default model ? What would need to change?

edit: I don't mean to be pushy with this I don't know how tone communicates online, it is your project and it obviously needs to meet your standards. If we want to offer a simple model and a complex model, I think it needs to be that the complex one is a strict superset of the simple one.

aggregations

A little unsure of what is meant by this

I feel like we should handle the aggregations separately somehow, they are quite specific to the backend you choose, e.g. numpy, pytorch etc.

I think PyTorch is too big to want to list as a dependency. But users can write their own aggregation function.

@lewisfogden
Copy link
Owner

I'm working through LightModel at moment, once I understand it fully I'll be able to comment a bit more appropriately :)

Is there an example of how to do the graph optimisation before a run? I can't find it

@MatthewCaseres
Copy link
Collaborator Author

https://github.com/lewisfogden/heavylight/blob/main/tests/test_memory_savings.py#L85-L91

You need to do a run before doing optimization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants