Math errors


#1

2^2^2 etc is ok
but 6^6^6 gives answer 0
9^8^6 gives negative numbers!!!
the use of parenthesis helps a little but its not consistant
If i go out of bounds /overflow it should tell me with a suitable error message

a language designed for math and science should able repeated powers well at this stage in its evolution


#2

Welcome! This is a common question — take a look at this entry in the FAQ:

https://docs.julialang.org/en/stable/manual/faq/#Why-does-Julia-use-native-machine-integer-arithmetic?-1


#3

To follow up on the previous comment, Julia defaults to using native integer arithmetic for performance. If you want to handle arbitrarily large integers, Julia also provides the BigInt type which is designed to do exactly that:

julia> big(6)^6^6
2659119772153226779682489404387918594905342200269924300660432789497073559873882909121342292906175583032440682826506723425601635775590279389642612611093020398930347774460613894425379600874662147884229022133853 <truncated>

(I had to truncate that result because the full answer is longer than the maximum post length on Discourse).


#4

This is an area where I feel Julia is a bit inconsistent in it’s philosophy.

Unlike C/C++, by default, when accessing a string or an array, bounds are checked (i.e. safe by default), however using the @inbounds macro, you can eliminate the bounds checking (basically 100% of the time in my programming I need to use that, because I check bounds at the top level, not on every access, for performance).

However, the opposite philosophy is used for numbers, operations do not check for overflow by default (and it’s a bit difficult to make that happen, there is no @checkoverflow macro to make sure that happens generically).

I understand why they decided to do things this way (the fallout from going out of bounds is generally much worse than the fallout from overflowing an numeric operation), however it would be nice if there were a generic way (that people implementing custom numeric types could also support), to indicate that overflow checking is desired.

While that is true, BigInt is quite slow, and take up a huge amount of memory compared to say Int128, and so may work in some applications where speed / memory usage are important.

With v0.7, it might be possible to make a small Union type, that was an Int64 or BigInt (or a better replacement for BigInt), and operations which overflowed an Int64 would return a BigInt instead.