Rethinking Numeric

[John Ralls]

On May 28, 2014, at 6:39 AM, David Carlson wrote:

> On 5/25/2014 9:34 AM, John Ralls wrote:
>> On 25 May 2014, at 07:19, John Ralls <jralls at ceridwen.us> wrote:
>> 
>>> On 25 May 2014, at 01:54, Christian Stimming (mobil) <christian at cstimming.de> wrote:
>>> 
>>>> Thanks for starting the discussion. 
>>>> 
>>>> If we've reached the point where our int64 rational numbers do not fit our problem requirements anymore, I'd rather look for a different number representation that fits our application domain better. I'm thinking about replacing rational numbers by decimal floating point numbers. That is, a number is represented by m * 10^e with the mantissa m and exponent e as signed integers. This is different from our normal *binary* floating point in that we use the exponent with base 10. However, all common rules for floating point can be applied just as normal. By the way, maybe there is even a standard comparable to IEEE 754 available? 
>>>> 
>>>> Just another possible way to proceed for solving this problem...
>>> Is this http://en.wikipedia.org/wiki/Decimal_floating_point what you're talking about? If so, it says that the IEEE spec is 854, and answers some of my questions, but leaves out database support.
>> A different spec: http://speleotrove.com/decimal/decarith.html
>> And an implementation, which is used in CPython: http://www.bytereef.org/mpdecimal/index.html
>> 
>> Regards,
>> John Ralls
>> 
>> 
>> _______________________________________________
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> 
> 
> If you look at the problem from a perspective that if math or numeric
> operations are somewhat costly in cpu cycles, therefore should be
> minimized (without sacrificing accuracy), then the data design should be
> such to minimize the number of numeric operations for common events. 
> 
> One way to greatly reduce the number of numeric operations might be to
> save the value of the current balance for each account (either on a
> recent date or simply including all posted transactions except newly
> entered ones) explicitly in the data and use that as the starting
> reference point for computation rather than zero in the far past.  That
> would mean somehow marking the newly entered transactions that have not
> been included in the running balance calculations, of course, as well as
> some other safeguards to detect possible errors, but it might give a
> substantial net savings of cpu overhead.  This might allow using a more
> accurate numeric representation without an excessive overhead penalty.
> 
> Just a thought.

That will be worth considering if balance computations show up as being a problem in profiling data. So far they don't.

Regards,
John Ralls