Re: [boost] Boost.Preprocessor - High-Precision Arithmetic Query

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-10-20 18:23:10

----- Original Message -----
From: "Joel de Guzman" <djowel_at_[hidden]>

> > > > > I don't know what you mean by option 3. If it causes a glorious
and
> > > > > loud preprocessor failure, I like that best. If it fails silently,
I
> > > > > am somwhat ambivalent.
> > > >
> > > > It causes a preprocessing failure (i.e. a "glorious and loud one").
> > >
> > > Then why in the world would anyone want saturation instead? That will
> > > just cover bugs.
> >
> > That is why I'm asking.  The arithmetic in the library currently does
> > saturation arithmetic.  At this point, Joel says "saturation for sure,"
and
> > you [David] say error instead.  I currently have it working with
saturation,
> > but I can remove the saturation an cause an error.  I really don't know
what
> > the best course of action here is--which is why I'm asking.
>
> I think David has a point. I must've missed the part that says that
> 3 is the most efficient. In my mind, I mistakenly concluded that
> no. 2 is the most efficient. In which case, I wouldn't mind
> silent saturation or wraparound (which is what integers do anyway).

The efficiency difference is not signicant enough to make the decision based
on that.  I just think that preprocessor failures are sometimes very hard to
figure out the error.  If I use saturation, nothing will fail.  Rather, the
number generated will likely be much higher than expected, which will be, in
most cases, obvious during the rest of a compile.  Preprocessing failures
have an annoying way of expanding into incomprehensibility.  I think it's
somewhat unlikely to be an issue in most cases.  Basically, the question is,
"should this generate a preprocessing error or not?"

#define X BOOST_PP_POSITIVE_HP(9 9 9 9 9 9 9 9 9)

BOOST_PP_MUL_HP(X, X)

Paul Mensonides