math, bigly

[Mark Waddingham]

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.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps