-
Notifications
You must be signed in to change notification settings - Fork 0
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
Fix behavior for nested types #1
Conversation
I don’t think you should try to guess from the order of the parameter listing. Packages implementing new numeric types should overload this function themselves. |
I agree. The default behavior is very simple and just assumes the first type is the numeric base type. It’s more of a useful fallback that works 99% of the time, not a final solution. But I am emphasizing that a downstream package should write a specialized method to their type. |
Here's the updated readme which is a bit more explicit about this. This package currently exports a tiny function
For example,
Package maintainers should write a specialized method for their type. import BaseType: base_numeric_type
base_numeric_type(::Type{Dual{T}}) where {T} = base_numeric_type(T) It is important to call |
Once the new version is updated we can ask different packages to start overloading this. |
Now when you have a
Quantity{Measurement{Float32}}
, it will returnFloat32
, rather thanMeasurement{Float32}
.The change is essentially just
@stevengj could you please confirm this is your expected behavior? Note that this will result in
base_numeric_type(Quantity{ComplexF32})
returningFloat32
, which I believe is more correct, asFloat32
is the base type ofComplexF32
.