On 2017-08-09 18:14, Mark Wieder via use-livecode wrote:
Oops. OK - point sheepishly taken. Is that the definition of integer
in the dictionary? The "integer" entry just says "if the value
contains digits (and an optional minus sign) and no other characters,
it is an integer", which is as simplisitic a definition as the entry
Technically an integer is a number which has no fractional part... So
that definition is mostly correct (10e100 is also an integer - just a
very large one).
The 'problem' in LC is that numbers are internally represented as
doubles. Technically doubles can hold integer values up to 2^53-1
faithfully - any larger than that (like 10e100) then they cease to be
exact (as the magnitude increases, so do the number of values which are
represented the same way).
But what annoys me isn't the fact that baseconvert, etc (bitXor is the
one that bit me) only work on integers less than 2^32. It's more the
fact that the input data was crunched down to something the functions
could handle, and then give me the wrong result with no warning.
We certainly could make all operations which only work *exclusively* on
integers (bit*) throw an error when out of bounds (and extend them to
2^53-1 max), but the engine never has so this comes with a
backwards-compatibility risk - perhaps one we should consider though.
The arithmetic operations are not possible to bounds-check in this way
as you get a 'graceful' degradation of precision when using them.
I'm pretty sure BaseConvert could be made to be an entirely
string->string operation as I said previously - not having any bounds
limit at all... Although you'd still not be able to do something like
base2 -> base10, bit operations, base10 -> base2 if your bit sequence >
52 bits long. So how worth-while that is, I'm not sure.
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription