-
Notifications
You must be signed in to change notification settings - Fork 418
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
accept Number
in Exponential
#1691
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportPatch coverage is
📢 Thoughts on this report? Let us know!. |
The problem here is related to Unitful, right? I'm happy to merge this if we need to, but first I'd like to check if it's possible to fix this in Unitful. @sostock ? |
IMO this needs more thought as it affects much more than just |
Its not related to Unitful.jl - its a generic problem with See here: I don't have bandwidth (or the required knowledge) to make this "optimal" or think through the implications, that is clearly a problem for devs of this package. I was just proposing a solution that would work for other users of my own packages, as well as Unitful.jl |
Another option would be to make the support for non- For that, one would change the type parameter to |
Co-authored-by: Sebastian Stock <42280794+sostock@users.noreply.github.com>
This is a start on #1684, with
Exponential
as an example to start the discussion, I'm not personally across the problems this may cause so this PR is a request for input and feedback on that.The idea is to loosen the type of
θ
to beNumber
, and add a check forComplex
numbers so those errors are avoided. More or different checks may be required.I'm not totally satisfied with the combination of
!(θ isa Complex)
andisreal(θ)
checks, but the idea is to make sure that even wrapped numbers are internallyReal
.