On Fri, 16 Jun 2000, you wrote:
> Richard Wackerbarth writes:
> > On Fri, 16 Jun 2000, Dave Peticolas wrote:
> > > Richard Wackerbarth writes:
> > > > On Fri, 16 Jun 2000, Dave Peticolas wrote:
> > > > > Ok, you've convinced me of the need to track 'smallest denominational
> > > > > units', but not why we need to use integers rather than FP numbers.
> > > > > You can round FP numbers, too. Why couldn't we just round the FP
> > > > > amounts to the appropriate precision when needed? If you're worried
> > > > > about the loss of accuracy, you should provide a realistic example
> > > > > where the precision of 64-bit floating points is insufficient.
> > > >
> > > > I don't have a problem with 64 bit FP precision. However, I worry that
> > > > you don't gain anything by using FP. And you do run the risk of
> > > > forgetting to process the values as money rather than true reals.
> > >
> > > The reason why I like doubles is that a huge amount of work has gone
> > > into making the IEEE floating point specification "correct". These
> > > quantities are used ubiquitously and are scrutinized by many people.
> > > I have great confidence that the calculations are being done
> > > correctly. OTOH, if we roll our own numerical library, I will have
> > > much less confidence. It's not that I think we are bad developers,
> > > it's just that the problem is quite complicated. It took a long time
> > > to get IEEE floating point correct, and there were some extremely
> > > smart people involved.
> >
> > Unlike FP, Scaled integer arithmetic is easy. The main thing that we do is
> > addition. And that is the easiest to do.
> > Actually, the hard part is getting the rounding done in the right places.
> > A good FP package won't help there at all.
>
> Addition may be the main thing thing, but it's not the only thing.
> Even if you only do a multiplication/division/etc. once in a while,
> you've still got to do it correctly.
>
> > > For that reason, if we decide to drop doubles, I would rather use
> > > a library like gmp which has already been written/debugged rather
> > > than start from scratch. We've got too many other things to do.
> > I have no problem using gmp when Int64 is not available.
>
> If we're going to use gmp sometimes, we should use it all the time.
> Mixing two libraries is just silly.
>
> dave
>
> --
This may not be a big deal for the total gnucash package - but using scaled
integer arthimetic for the financial calculator and amortization schedule
computations I am finalizing and getting ready to send to Dave is done totally
in double. All of the calculations can probably be done in scaled integers, but
the complexity will go up several orders of magnitude. log and exp functions
are used and would have to be rewritten to use scaled integers. I don't know
about gmp - does it contain log and exp functions. Also rewriting for scaled
integers in the calculation of interest from the other valiables. I haven't
looked closely, but from the top of my head, rewriting the Newton apprixmation
starting point alone would not be trivial and would introduce much source for
error. As long as doubles can be used - I think that staying with them would be
the best for the calculator at least - unless someone very familiar with scaler
integer arthimetic would volunteer to rewrite from the present source. Also, I
would willing to bet that for some of the computations which are iterative in
nature, the time delay introduction would be significant. Of course we can rely
on faster H/W to alleviate the problem :-).
Of course, the calculator could remain in FP and appropriate translations done
on its input/output.
Just my two cents worth.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
