On 5/25/2014 9:34 AM, John Ralls wrote: > On 25 May 2014, at 07:19, John Ralls <jra...@ceridwen.us> wrote: > >> On 25 May 2014, at 01:54, Christian Stimming (mobil) >> <christ...@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@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. David C _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
