Re: [boost] ublas int*vector != double*vector?

From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2003-01-14 16:43:23

----- Original Message -----
From: "Julius Muschaweck" <muschaweck_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, January 14, 2003 10:15 AM
Subject: [boost] ublas int*vector != double*vector?

> Hi,
>
> this is my first posting, so please give me guidance if this is going into
> the wrong direction.
>
> I'm using ublas (with Visual Studio .NET) , and I like it a lot.
> However, in scalar * vector operations, ublas doesn't handle implicit
int -
> double conversions like the compiler, which resulted in a hard to trace
bug
> for me:
>
> using namespace boost::numeric::ublas;
> vector<double> v(3);
> v[0] = 1.1;
> v[1] = 2.2;
> v[2] = 3.7;
> vector<double> v2;
> v2 = 2.0 * v; // double times vector
> std::cout << v2 << std::endl;
> v2 = 2 * v;  // integer times vector
> std::cout << v2 << std::endl; //oops
> std::cout << 2*3.7 << ' ' << 2.0 * 3.7 << std::endl;
>
> produces
>
> (2.2,4.4,7.4)
> (2.,4.,7.)
> 7.4 7.4
>
> What seems to happen is that ublas first rounds the doubles in v to ints,
> performs integer multiplication and then converts the result back to
> double, whereas the compiler converts an int to double and then performs
> floating point multiplication.

Exactly. Kresimir Fresl noticed this bug recently and my current version
contains the following fix in traits.hpp already:

     template<class T1, class T2>
    struct promote_traits {
        // Default promotion will badly fail, if the types are different.
        // Thanks to Kresimir Fresl for spotting this.
        BOOST_STATIC_ASSERT ((boost::is_same<T1, T2>::value));
        typedef T1 promote_type;
    };

I couldn't check the Boost CVS version, because Sourceforge seems to have
problems.

> It's maybe not good style to rely on implicit conversions like this, but
> I'm surely not the only one.
>
> My opinion is that ublas should do int*vector<double> like the compiler
> does int*double, or am I missing a reason why this is intended?

Yes, it is one of the options to extend promote_traits to cover integral
types, too.

Thanks for your feedback (and sorry for the inconvenience),

Joerg