Keno / SIUnits.jl

Efficient unit-checked computation

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

add constructors for identity conversions?

JeffBezanson opened this issue · comments

Currently we get this:

julia> typeof(.1mm)(.1mm)
ERROR: MethodError: Cannot `convert` an object of type SIUnits.SIQuantity{Float64,1,0,0,0,0,0,0,0,0} to an object of type Float64
This may have arisen from a call to the constructor Float64(...),
since type constructors fall back to convert methods.
Stacktrace:
 [1] SIUnits.SIQuantity{Float64,1,0,0,0,0,0,0,0,0}(::SIUnits.SIQuantity{Float64,1,0,0,0,0,0,0,0,0}) at /home/jeff/.julia/v0.6/SIUnits/src/SIUnits.jl:11

Generally subtypes of Number should be able to handle T(x::T) calls. This causes problems e.g. with ranges of unit quantities:

julia> range(1mm, 0.1mm, 50)
Error showing value of type StepRangeLen{SIUnits.SIQuantity{Float64,1,0,0,0,0,0,0,0,0},SIUnits.SIQuantity{Rational{Int64},1,0,0,0,0,0,0,0,0},SIUnits.SIQuantity{Float64,1,0,0,0,0,0,0,0,0}}:
ERROR: MethodError: Cannot `convert` an object of type SIUnits.SIQuantity{Float64,1,0,0,0,0,0,0,0,0} to an object of type Float64
This may have arisen from a call to the constructor Float64(...),
since type constructors fall back to convert methods.
Stacktrace:
 [1] unsafe_getindex(::StepRangeLen{SIUnits.SIQuantity{Float64,1,0,0,0,0,0,0,0,0},SIUnits.SIQuantity{Rational{Int64},1,0,0,0,0,0,0,0,0},SIUnits.SIQuantity{Float64,1,0,0,0,0,0,0,0,0}}, ::Int64) at ./range.jl:506

Out of curiosity, are you trying this out of interest in something units-related or is this an example to explore defaults for constructors etc.? Worth cross-referencing Unitful.jl, where the first works and the second fails (though it works if you change the first argument to 1.0mm).

I found this by trying to create an AxisArray with SIUnit spacings (it works if you use Unitful), just for demo purposes. Naturally, the construct-vs-convert issue jumped out at me.

It's been a while since I looked in on Unitful.jl, and it is really quite glorious! I might even look the other way on its overloading show(::IO, ::Type{...}) :)
Is there any reason to keep both Unitful and SIUnits around?

Personally I don't think so. SIUnits was started using a pretty early version of Julia (in particular, before @generated functions), and was awesome given what was possible at the time. But Unitful definitely benefits from leveraging more modern functionality. IMO it's one of the best examples of the need for @generated and one of the best "stressors" of the type system (you may recall I mentioned it briefly at JuliaCon).

Also, @ajkeller34 has been awesome as a designer, developer, and maintainer. Really nice to have this part of the Julia landscape in such good hands, in no small measure because it also frees up @Keno to do other cool stuff.

If @Keno is amenable, we could put a more aggressive redirection in the README.

It's just plain fun to attach units to all your variables and see how many packages choke 🙂. (Beyond code, this also applies on purely theoretical grounds to whole fields of applied mathematics, like about 80% of the widely-used algorithms in optimization theory.) My own packages are not immune from that kind of failure. It's consistently a good test of whether you're thinking about things in a clean way.

Please do whatever with this package. It was written for my physics/EE homework, which I don't have any more, so I'm no longer regularly using this package.

@JeffBezanson @timholy Thank you so much for the very generous words! I'm flattered.