david.carlson.417 at gmail.com
Wed May 28 09:39:30 EDT 2014
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
> John Ralls
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
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.
More information about the gnucash-devel