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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-10-19 13:37:59

----- Original Message -----
From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>

Hello Victor,

> <only slightly jesting>
> you left out "the C way"
> 4) just do modular arithmetic and leave it up to the programmer to "know"
> what's wrong

This would be even easier than causing the preprocessor to error.  It would
simply ignore overflow altogether.

> or as Scott Meyers keeps saying (I paraphrase) "When in doubt, do what int
> does"

By this, do you mean wrap around to the other side?  I don't have a
realistic way of doing that (unfortunately).

> </only slightly jesting>
>
> I don't have a good answer here.
> Most computers (that I've played with over the years) gave the answer
> modulo (max value + 1) and a flag (or trap) commonly called overflow.
> Most HLLs just give answer modulo (max value +1) and no way to even detect
> overflow.
> IMO, you're breaking new ground here (unfortunately)

I could maintain an "overflow" bit and yield a valid saturated number.
However, I don't think its worth doing anything too complex.  This is only
the preprocessor after all!  Two major issues that I run into in this type
of stuff is slowness (e.g. EDG) and macro depth (e.g. Microsoft and
Metrowerks).  I've solved these issues for the most part, but adding any
"extended" support of the non-common case of overflow would imply an
increase in macro depth and a slowdown on EDG-based preprocessors--even when
it *doesn't* overflow.

If it wasn't for those two issues, I would increase the support far higher
than ten digits.  Ten just happens to be the lucky number.  When you do
multiplication of two ten digit numbers by hand, for example, you end up
adding ten results together with a maximum of 10 digits in a column.
Accounting for the possibility of carrying from the previous column, that is
11 digits--which adding 11 digits conveniently cannot cause a carrying of
more than a single digit (maximum would be 9 * 11 == 99).  Because of this
multiplication uses an "optimized" addition.  However, there is no reason
why it can't use regular addition of two ten-digit numbers (or a combination
of both) if I want to increase the number of significant digits later.  The
infrastructure is already there to handle it--as everything but division
(and modulus) is non-recursive.

Thanks for you comments,

Paul Mensonides