Hi guys,
speaking as a Groovy user again (i.e. irrespective of how hard this
would be to change/implement) and as someonewho has run into the same
problem: This seems very Java & mighty un-groovy to me.
At least if the calculation is done in a single statement (but also for
constant numerical values in general), I would expect one of two
behaviors: Either
1. Throw a compilation error, saying that the result cannot be
represented within the literal datatype given (with a hint that
appending "L" or "G" might be what the user wants), or
2. Automatically use BigInteger as the result type.
Gauging whether the product of several integer literals fits within a
32-bit int is not something humans are typically good at, and a
numerical overflow is basically always an error. During runtime overflow
error detection is typically off, due to performance considerations, but
this would not prohibit it during compile time...
Cheers,
mg
On 09/12/2019 18:00, Paul King wrote:
Meta note: This thread is related to the usage of Groovy and best
belongs on the users mailing list where it will gain more eyeballs and
also more likely to be found in the future by other users in the same
scenario. The dev list is for aspects relating to the development of
the language itself.
But to answer the current question, Integer literals aren't made
BigInteger by default but if either side of a multiplication is a
BigInteger, the answer will be BigInteger, so you get the correct
answer in the posed problem with e.g.: 86400G*1000*30
Cheers, Paul.
On Tue, Dec 10, 2019 at 2:48 AM Angelo Schneider
<angelo.schnei...@oomentor.de <mailto:angelo.schnei...@oomentor.de>>
wrote:
Would that not be handled by BigInteger?
I assumed integer literals are treated as BigInter just like
float/double literals are treated as BigDecimals.
Greetings
Angelo
Am 09.12.2019 um 00:51 schrieb Edmond Kemokai <ekemo...@gmail.com
<mailto:ekemo...@gmail.com>>:
I'd read up on the MAX_VALUE doc but didn't see any mention of
this behavior... Thanks guys!!
