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

(AbstractDevice)(x) should respect Adapt.adapt_structure #1149

Closed
vpuri3 opened this issue Dec 28, 2024 · 6 comments
Closed

(AbstractDevice)(x) should respect Adapt.adapt_structure #1149

vpuri3 opened this issue Dec 28, 2024 · 6 comments

Comments

@vpuri3
Copy link
Contributor

vpuri3 commented Dec 28, 2024

The current implementation of cpu_device()(x) does not work if x, say, has an abstract FFT plan. Rather, it should call adapt_storage on x if that is defined.

https://github.com/LuxDL/Lux.jl/blob/main/lib/MLDataDevices/src/public.jl#L366

@avik-pal
Copy link
Member

The issue with Adapt.adapt_structure is that it is opt-in and has very few structures defined.

@vpuri3
Copy link
Contributor Author

vpuri3 commented Dec 28, 2024

would you recommend overloading device(x) for types that may also overload Adapt.adapt_strucure?

@vpuri3
Copy link
Contributor Author

vpuri3 commented Dec 28, 2024

the issue with the functor implementation is that adapt_structure is applied to leaf elements of x. so if i want a custom conversion for x.a, that won't be possible if x.a has subfields.

the adapt approach is preferable for overloading as the conversion of x.a.b would be handled by the recursive adapt call to x.a.

@avik-pal
Copy link
Member

Mark x.a as a MLDataDevices.isleaf or a Functors.isleaf?

@vpuri3
Copy link
Contributor Author

vpuri3 commented Dec 29, 2024

Thanks, let me try that.

@vpuri3
Copy link
Contributor Author

vpuri3 commented Dec 30, 2024

Thanks Avik, that did work.

@vpuri3 vpuri3 closed this as completed Dec 30, 2024
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