Throwing a few ideas out in the form of rhetorical-ish questions:
Is wraparound ever desirable in practical situations? Wouldn’t you always want to throw an overflow error or return NaN? (Is an overflow even a NaN?)
Shouldn’t it be the user’s responsibility to cater for potential overflow errors, rather than the developer having to contort Julia’s internals? It’s reasonable to expect some level of engineering skill…
As noted, the user can specify
sum( T, [foo, bar] ) to manually force promotion to T. Isn’t this one of the Zen rules of Python: “Explicit trumps implicit”?
It must be difficult to implement a consistent automatic selective overflow checking internally: if checking is not present for
+, how can it be present for
sum, which is just a bunch of
+ operations in a loop?
Overflow checking is clearly at odds with performance. I wonder if it might make sense, rather than for Julia to make difficult trade-off decisions, to have some global
overflow_check flag that would be on by default but can be turned off. By offing the flag the user is signing on the dotted line that they know what they’re doing. And maybe get the
@fastmath macro to disable overflow checking with
tmp = overflow_check; overflow_check = false; ...; overflow_check = tmp.
Speed is valuable, but a clean consistent simple interface is priceless. Machines get faster each year and 32 bit systems are arguably on the way out. So I’m not sold on the arguments for promotion to Int32 rather than Int64. If the user wishes to take advantage of specific architectures, let them manually supply the promotions. Let them optimise the code. But keep the internals of Julia clean as a whistle!
i.e. They can specify
(a+b)::t – is that the same as
+(T, a, b) or
+( promote(T, a, b) ... )? Or does Julia first do
a+b and subsequently convert to
I’ve just bumped into a similar promotion issue elsewhere (https://github.com/JuliaLang/julia/issues/19714)
I wonder if rather than just a
check_overflow flag, maybe Julia could also have an overflow policy – on overflow:
… and a promotion policy:
- use biggest type (so 8 8 -> 8, 8 16 -> 16 etc.)
- next power of two (so 8 8 -> 16, 8 16 -> 32 etc.)
- 32-bit optimised: promote <32 to 32, <64 to 64 (so 8 8 -> 32, 8 16 -> 32, 16 32 -> 64 etc.)
- 64-bit: promote everything to 64, so (8 8 -> 64 etc.)