mark at livecode.com
Wed Aug 9 12:29:40 EDT 2017
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
> for "hex".
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 ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
More information about the Use-livecode