Open rickhg12hs opened 10 years ago
I bet the problem is here. @rickhg12hs, can you change that, test, and if it works submit a PR?
It looks like there are more problems for 32-bit platforms. E.g., const Yotta
(and others) will overflow/wrap with Int32
s.
using SIUnits
doesn't even work at the moment.
julia> versioninfo()
Julia Version 0.4.0-dev+492
Commit beca3e4 (2014-09-06 19:43 UTC)
Platform Info:
System: Linux (i686-redhat-linux)
CPU: Genuine Intel(R) CPU T2250 @ 1.73GHz
WORD_SIZE: 32
BLAS: libopenblas (DYNAMIC_ARCH NO_AFFINITY Banias)
LAPACK: libopenblas
LIBM: libopenlibm
LLVM: libLLVM-3.3
julia> using SIUnits
Warning: New definition
convert(Type{SIQuantity{T,m,kg,s,A,K,mol,cd}},T) at /home/rick/.julia/v0.4/SIUnits/src/SIUnits.jl:102
is ambiguous with:
convert(Type{T<:Number},Period) at dates/periods.jl:23.
To fix, define
convert(Type{SIQuantity{_<:Period,m,kg,s,A,K,mol,cd}},_<:Period)
before the new definition.
Warning: New definition
convert(Type{SIQuantity{T,m,kg,s,A,K,mol,cd}},S) at /home/rick/.julia/v0.4/SIUnits/src/SIUnits.jl:103
is ambiguous with:
convert(Type{T<:Number},Period) at dates/periods.jl:23.
To fix, define
convert(Type{SIQuantity{T,m,kg,s,A,K,mol,cd}},_<:Period)
before the new definition.
Warning: New definition
convert(Type{SIQuantity{T,m,kg,s,A,K,mol,cd}},S) at /home/rick/.julia/v0.4/SIUnits/src/SIUnits.jl:108
is ambiguous with:
convert(Type{T<:Number},Period) at dates/periods.jl:23.
To fix, define
convert(Type{SIQuantity{T,m,kg,s,A,K,mol,cd}},_<:Period)
before the new definition.
ERROR: `+` has no method matching +(::(Int32,Int32,Int32,Int32,Int32,Int32,Int32), ::(Int32,Int32,Int32,Int32,Int32,Int32,Int32))
in * at promotion.jl:159
in include at ./boot.jl:246
in include_from_node1 at ./loading.jl:128
in reload_path at loading.jl:152
in _require at loading.jl:67
in require at loading.jl:51
while loading /home/rick/.julia/v0.4/SIUnits/src/SIUnits.jl, in expression starting on line 292
Actually, do the more "extreme" constants even work on a 64-bit platform?
const Zetta = (10^21)SIPrefix
const Yotta = (10^24)SIPrefix
and
const Zepto = (1//10^21)SIPrefix
const Yocto = (1//10^24)SIPrefix
Hmm, looks like not. I may have been the one to add those. Oops.
I suppose we could make them BigInts, but alternatively we could just delete them. Thoughts?
The overflow situation is pretty bad. Nowadays when doing exploratory calculations I mostly use bigints and bigfloats to avoid bad answers. This of course not great for production. We probably need some sort of support for storing the order of magnitude in the type.
How about Int128's?
Need to make it all work on different platforms too.
One way to store the type information in SIPrefix
would be to make the type parametric on the exponent, i.e.
const Yotta = (10^24)SIPrefix
becomes
const Yotta = 1*SIPrefix{24}
Of course we'd have to implement some special arithmetic for SIPrefix
es to handle this, but at least we should be able to avoid overflows in most cases. It's probably also possible to define normalize(siq::SIQuantity)
to store the OOM of siq
in the type instead of the number (although I'm not sure it's a good idea - I haven't thought very carefully about rounding errors that might be introduced, for example...).
A parametric SIPrefix
, analogous to SIQuantity
, makes the most sense to me.
cc me, note to re-enable tests that depend on SIUnits in Images.jl for 32 bit systems when this is fixed ref https://github.com/timholy/Images.jl/pull/243#issuecomment-68942440