Re: [boost] Re: Fixed point decimal

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-09-11 15:22:59

----- Original Message -----
From: "Seymour, William A - St Louis, MO" <WSEYMOUR_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, September 11, 2002 2:24 PM
Subject: RE: [boost] Re: Fixed point decimal

> > From: Fernando Cacciola [mailto:fcacciola_at_[hidden]]
> > Sent: Wednesday, September 11, 2002 7:44 AM
> > To: boost_at_[hidden]
> > Subject: Re: [boost] Re: Fixed point decimal
> >
> >
> > Hi Bill,
> >
> > I've just read this whole thread, and at some point you
> > mentioned that could could go back to a template version;
> > I would really like that.
> >
> > A few months ago I needed a fixed-point decimal class to
> > perform some geometric computations.
> >
>
> Do you need a fixed-point decimal type or a fixed-point
> binary type?
>
A fixed-point decimal type.

> >
> > The first thing I tried was your class, ...
> >
>
> Oh, dear!  It's still at the "What's your interest?" stage
> (and there hasn't been much); and it hasn't really been tested.
> I hope I wasn't too badly embarrassed by your trials.  8-)
>
Don't worry.
I changed the int type by hand, by replacing the type in the code by
__int64, and it seemed to work OK. (I think I had to touch a few places but
it was not big deal)
I had to drop it though, just because __int64 was eventually also too short
and some overflows crept from time to time, but it was working for some time
in real code without trouble (that is, if I had a fast __int256 it would
probably be in use today...)

>
> >
> > If you could turn the fixed decimal class into a template so
> > I can use it with an arbitrary length integer class it will
> > be just what I need.
> >
>
> That would move a lot of computationally expensive code into
> the header file.
>
What's the problem with a lot of computationally expensive code into a
header file?

> Also, doing what amounts to std::div() on any arbitrary type
> is likely to be inefficient.  (I think I need to do something
> like div() because the / operator's direction of truncation,
> and the sign of the % operator's result, are implementation-
> defined for negative values in C; and I don't find any normative
> text in the C++ standard that changes that.  If somebody can
> point me to such text, /please do/.)  OTOH, I'm already doing
> an inefficient div if my integer type is other than int or long;
> so maybe that's not a problem.
>
I would accept such inefficiencies as long as it works correctly. In my
case, I needed it for some specific exact calculations, so I don't care for
efficiency as much as I care for robustness.

> >
> > BTW; I need a compile-time-fixed number of decimals, and the
> > same for all decimal values. If you can do something to improve
> > performance for those cases it would be great.
> >
>
> Are you talking about the time it takes to calculate the
> representation of unity given the scale?  The only compile-
> time way to do that, AFAIK, is to use a recursive template;
> but the result wouldn't fit in an enum in general; and I
> don't know any other way to store the result portably.

OK, I see that... Seems too much trouble. Never mind.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com