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 <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.
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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
