[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: About big integers in Lua 5.3.
- From: Coda Highland <chighland@...>
- Date: Thu, 14 Jan 2016 12:46:12 -0800
On Thu, Jan 14, 2016 at 12:39 PM, Tom N Harris <email@example.com> wrote:
> On Thursday, January 14, 2016 03:00:14 PM Chris Berardi wrote:
>> I'd be tempted to upgrade the number to some sort of arbitrary precision big
>> number (a third number sub-type?) when it overflows an int or float.
> This is getting silly.
> What if I meant for the number to be an integer with overflow? If the parser is
> trying to guess my intent of whether the value should be an integer, float, or
> error then what do I do if it guesses wrong? When the assumption is error then
> every time I want to guarantee a non-error value will have to be written
> carefully. When the assumption is float then how do I force integer overflow or
> flag loss of precision? The assumption of integer I think is safest because I
> can force a float by adding ".0".
> To show some practical examples instead of speaking in vague abstractions, I
> expect the issue will arise when writing number constants in hex. You can have
> the surprise behavior of 9223372036854775808 being less than
> 9223372036854775807, or the surprise of 9223372036854775808 not being equal to
> 0x80000000000000000000. Programmers working with natural numbers would be
> annoyed by the former, while programmers working with binary data would be
> annoyed by the later.
> While making sure that for any number N, N+1 > N makes sense to mathematicians
> that's not how the underlying representation works and ultimately Lua operates
> on number representations, not number theory. We're all familiar with
> 0.1+0.1+0.1 not being equal to 0.3. Lua doesn't hide the imprecision of floats,
> nor do I think it should hide the overflow of integers.
> tom <firstname.lastname@example.org>
+1. This is exactly my opinion on the matter. If I'm working with a
64-bit integer, and I KNOW I'm working with a 64-bit integer, then
give me a 64-bit integer; I'm aware enough of the circumstances to be
able to deal with the implications, and at the very least I can
reconstruct the original positive number from the negative one because
there hasn't been any actual data loss.