Boost logo

Boost :

From: Maxim Shemanarev (mcseem_at_[hidden])
Date: 2002-08-22 19:15:08


> First of all, I agree with Maxim that a general core-level solution is
> really
> difficult, not only because it is difficult to define consistent semantics
> for it, but also because of backward compatibility.

Not only because of that.

1. Expressions can be very complex and in these cases it's not obvious what
to do, I mean what data types the compiler should use for internal
variables. Twice longer? But why only twice?. I've already gave this
example, what if we have y = x*a*b*c/d; Look, x*a is 64 bits, x*a*b
theoretically should be 96 bits and x*a*b*c is 128 bits! So, it's absolutely
right to lose *intentionally* most significant part of the mul-product on
each step.

2. Remember the division-by-zero issue. On most machines it throws a
hardware exception. But at least on Intel it occures not only when you
divide by zero, but also when the result of the division doesn't fit 32-bit
value! I.e. if you try this (suppose we downgrade everything to 16 bits
unsigned):
mov ax, 60000
umul 50000
udiv 10
You will have the very same zero-divide exception. But if you add the "cwd"
command after "umul" it'll be impossible to have it.

Again, the way all C-compilers treat integer expressions is absolutely
correct!
What I'm talking about is to have only a very special case for only this
expression a*b/c. That's it, thank you for understanding :-)

> template<class N>
> struct algebra_kernel
> {
> template<class T>
> static T muldiv ( T x, T y,T w)
> {
> return static_cast<T>( static_cast<N>(x) * static_cast<N>(y) /
> static_cast<N>(w)) ;
> }
>
> .... so on ...
> } ;

This technique is exactly what I said in the original post. But it will
result in calling internal mul64 and div64 and so, slowing down the
calculations.

McSeem


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk