Re: [boost] [complex] Feedback and Potential Review Manager

Subject: Re: [boost] [complex] Feedback and Potential Review Manager
From: Matthieu Schaller (matthieu.schaller_at_[hidden])
Date: 2012-05-01 13:07:07

>> @ Experienced Boosters: I fear lots of code here!
>> Can Matthieu write global ops for binary arithmetic with
>> PODs in a clever way combining boost::enable_if with is_integral, etc.?
>> Or does the developer really need to diligently write all those 
>> global ops
>> (with PODs on both RHS and LHS) for unequivocal resolution
>> with char, signed char, unsigned char, short, unsigned short, int,
>> unsigned int, long, unsigned long, long long, unsigned long long,
>> float, double, long double, and maybe even const char*.
>
> For sure, off the top of my head and untested with a real compiler, 
> but how about:
>
> template <class Float, class Arithmetic>
> typename enable_if<is_arithmetic<Arithmetic>, complex<typename 
> boost::math::tools::promote_args<Float, Arithmetic>::type> >::type
>    operator *(const complex<Float>& a, const Arithmetic& val)
> {
>    typedef complex<typename boost::math::tools::promote_args<Float, 
> Arithmetic>::type> result_type;
>    return result_type(a.real() * val, a.imag() * val);
> }
>
> So basically this is only selected as a possible overload if the 
> second argument is a builtin arithmetic type, then the type of the 
> result is calculated using a helper template from Boost.Math which 
> effectively promotes integers to double and then computes 
> typeof(Float*promoted(Arithmetic)).  Basically promote_args implements 
> the logic in 26.8 para 11 of C++11.
>
> So that:
>
> complex<float> * double -> complex<double>
> complex<float> * int -> complex<double>  (because integers get 
> promoted to double)
> complex<double> * long long -> complex<double>
>
> etc etc.
>
> HTH, John.
>
> PS of course we could argue that ints longer than 53 bits should be 
> promoted to long double to try to avoid loss of digits.... but that's 
> a whole other ball game....
>

But then aren't you removing the optimization complex<double> * int that 
Chris originally proposed ? As your int is promoted to a double. Or are 
you talking about non-POD integer-like types ?

Bests,

Matthieu

-- 
Matthieu Schaller