Rational denominator overflow in nm^3

[jiahao]

julia> using SIUnits.ShortUnits; (1.0)*nm^3 #dfq??
-1.4428143086438808e-19 m³

julia> nm^3 #Insidious overflow error!
-1//6930898827444486144 m³

[Keno]

Maybe make nm use Rational{Int128}?

[jiahao]

That would just be delaying the problem, no? Conceivably someone would want nm^6 in some future application and reencounter this issue.

[Keno]

Arguably people who work with more than 3 space dimensions don't tend to use meters, but fair enough. Maybe have the base units use a custom order-of-magnitude type? Then you could go as high as $nm^div(typemax(Int),3)$

[jiahao]

Keeping track of the order of magnitude separately would work. Do you envision nm^3 being represented as (Meter^3, -27) or (Meter, -9)^3 ?

[Keno]

(Meter^3, -27). I'd just go for Float64, but that can't represent 10^n exactly which is something I do want if people have custom types for which it matters. For builtin types in arithmetic I'd just default to Float64.

[jiahao]

Fair enough, especially since SI prefixes go up to 10^24. (Scaling is a very common problem in scientific calculations; many practical computations explicitly work in custom, transformed units where the quantities are close to 1.0.)

[Keno]

Hmm yeah this makes me wonder if we should support something more general here.

[Keno]

I guess people can always define their own custom non-si unit with whatever scaling they want, but you do lose a bunch of nice things.

[jiahao]

Would be nice to figure out something that would general enough to work with fractional powers also.

[Keno]

Yeah, I've been meaning to put some more thought into this package. Added to the ever-growing todo list.

[timholy]

For fractional powers, I will see if I can come up with a more acceptable version of JuliaLang/julia#7172.

If one is thinking about generalizing this package: I'm mulling over conversions like JuliaImages/Images.jl#101. That presumably would be best done with an SIUnits-like approach with Count and Photon as parameters. Keno, I'm aware you have a lot on your plate, and since I'm more excited about the prospect of a debugger than just about any other change to Julia, I'll mull this over a bit (in a couple weeks).

[StefanKarpinski]

I've also wondered whether time stuff shouldn't be integrated with some kind of units – UT time is odd because it's an angular measurement, not an actual time measurement, but that's fundamentally what it is. At which point one starts wondering if unit support doesn't belong in base.

cc: @quinnj, @JeffBezanson.

[StefanKarpinski]

Also, I wonder if this particular issue couldn't be addressed with some kind of fixed-point type. Something like Fixed{b,k} which can represent fixed-point values in arbitrary bases.

[timholy]

At which point one starts wondering if unit support doesn't belong in base.

As a possible alternative to Base, I was thinking in terms of a GenerateUnitfulQuantities.jl package, which given a modest number of directives would code-generate SIUnits.jl, TimeUnits.jl, PixelUnits.jl, etc. Each one of these is a bit of a domain of its own, but there's a lot of need for shared infrastructure.

All this of course puts pressure on some of our current type-inference challenges, but perhaps this kind of development will help clarify what is needed.

[quinnj]

Sorry for not commenting earlier. Yeah, I think generally the idea is good to have solid units backing everything, though I worry about getting all the abstractions playing nicely with one another so it's actually feasible to use in other packages pleasantly. Seems tricky to work out corner cases or weird domain issues (I'm thinking about some of the hassles we went through with the StepRange for Dates/Periods business), that end up throwing a wrench in a nicely laid abstraction plan.
So I'm all for it if we can mature something and it'll work, but I just personally find it a bit of a daunting task to iron out. I've definitely been planning on kicking around with a TTInstant though based on the SISecond so we have a nice way to deal with leap seconds.