function overflow()
a = 2^63
return a
end
overflow()
function overflow_no()
a = BigInt(2)^63
return a
end
overflow_no()
In the above example overflow() will overflow with no warning, but overflow_no() works fine. This is a very subtle “bug” that data scientists coming from a pure statistics/machine learning background may not fully appreciate and can cause lots of headaches in debugging.
Wouldn’t it make sense for Julia to have a way to define an auto-promotion rule for bit types when it overflows? E.g. auto promote the Int64 to BigInt when it overflows. This feels more natural to me, a mathematician/statistician by training.
Unfortunately, that’s not possible without a large performance hit. See the FAQ. For scientific work, in general better use Float64 than Int, since it progressively loses absolute precision when moving away from zero, and becomes Inf in case of overflow. Int should be reserved for purely integer values, e.g. an index into an array (which cannot overflow because of memory use limits).
Overflow used to be a big issue on say 16-bit CPUs (or for 8-bit integers…).
This is of course increasingly rare and very much so for Int64. So rare in fact that a better option may be to just fail with an OverflowException.
[For indexes into arrays Int (Int64 or Int32) will never overflow, as arrays can’t get that big.]
Note also there is Int128 datatype (faster than BigInt), with overflow even more rare, but possible.
All of the Integer types can trivially be wrapped into a new type that check for overflow (already done in a package?), and then throw an exception (with a performance hit, see other post). In theory, such a type could also be made the default replacing the current Integer types (with the same performance cost, doubt the compiler could reduce it; it really wouldn’t have more information to do so) so that you need no syntax changes [for literal values].
That new default would not be accepted for Julia, unless it’s a runtime command-line option,. Such an option would only work if you’ve not defined a new type.
There are some issues on this, I found just this one again (note marked “1.x”-milestone, desiding on this isn’t important for 1.0 as the above plan breaks no code):