math, bigly
Mark Waddingham
mark at livecode.com
Wed Aug 9 13:15:39 EDT 2017
On 2017-08-09 18:56, Bob Sneidar via use-livecode wrote:
>> Btw, I should mention that the way numbers work in LiveCode has become
>> one of my biggest 'pet peeves' over the last year or so. The current
>> way things work is too simplistic really - it hides the very important
>> distinction between 'exact' and 'inexact' numeric representations, for
>> example.
>>
>> Unfortunately, there's a fair amount of work involved to fix the
>> situation to my satisfaction level - although I think I have a handle
>> on how to do so without hugely adversely affecting general numeric
>> performance. *sigh*
It isn't doing the math that is hard - there are plenty of libraries
which do general precision arithmetic. Even standard 'high-school'
algorithms work well for reasonable magnitudes and you only really need
to get out the big guns - e.g. the Strassen algorithm - for very large
numbers, although that scale is relatively common in 'high-end'
cryptography settings (factoring large numbers for the purposes of
generating keys and such).
The main issue is working out how to do it so that the ability to handle
large numeric precision does not impact the performance of the normal
sized numeric precision operations. There's also the exact <-> inexact
boundary issue too (going from integer/rational -> irrational) -
realistically modern processors are only really good at (64-bit)
integers, or (64-bit) IEEE floating point values.
What you really want is to use machine sized integers for all
computations which don't require anything greater than that (i.e <
64-bits these days) *without* penalty; but still allow code to be
written which can handle large integers too. I think I've figured out a
reasonable way to do that - but it requires type / range analysis.
The exact / inexact thing is still troublesome though - in other
languages 10 means something different from 10.0. Maybe that's actually
reasonable, but part of me feels it is a little subtle.
Certainly infinite precision integers would be exceptionally handy - as
you also get arbitrary length bitsets like that too (there's an
equivalence between dense bitsets and integers, unsurprisingly, you can
use the two interchangeably).
In any case, the first step before doing anything in this regard is to
do a little bit more work on our 'Number' representation internally -
and make the engine abstract through its API for various operations
rather than just using +/- etc. directly in the implementation of syntax
- then we would be able to more easily experiment with internal
representations.
Warmest Regards,
Mark.
--
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
More information about the Use-livecode
mailing list