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

Subject: Re: [boost] [complex] Feedback and Potential Review Manager
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-05-01 10:09:09

>> 3) I disagree with

>>      explicit complex(const T&  re = T(0.), const T&  im = T(0.))
>> I believe this constructor should be non-explicit.
>> See ISO/IEC 14882:2011, Section 26.4.2.

> Agreed, I should stick to the standard.
> However, I will keep the imaginary constructor explicit.
> I do not want spurious Real -> Imaginary conversions.

Thank you for your detailed response, Matthieu.

Did you also notice in my other post that
my suggested correction was, in fact, wrong? I am terribly
sorry about that. You actually need this:
  explicit complex(const T&  re = T(), const T&  im = T());

>> 4) I would really like to see global operators for
>> seamless interaction of complex<T>  with integer PODs.
>> The proposed code of boost::complex forces explicit construction
>> from integer "all the way" to boost::complex<T>  just to, for example,
>> multiply with 2. This is extremely costly as most multiprecision
>> or fixed-point types have specially optimized routines
>> for multiplication with integer PODs.

> Great idea. I have done it for pow() but it is true that other operators
> may benefit from this. This optimization will only be available to
> POD types but T==double is probably the primary concern.

You know it's counter-intuitive but perhaps the global binary
arithmetic operators (complex * integral) and (complex / integral)
will be most beneficial. The heavyweight *users* of a potential
boost::math::complex may include multiple precision types and
fixed-point types. Both of these data types typically have optimized
multiplication and division routines that are linear O(N) in the number
of words N composing the type instead of O(N^2) or O(N * Log(N)).

It's a crazy world with those specialized types.

I briefly glanced at you pow-N routines. Perhaps I'm wrong,
but I believe you are not doing binary splitting of the exponent
here. Perhaps you might want to optimize this. Or maybe
I'm misunderstanding your code. Please get back to me
if this is unclear.

@ 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*.

>> 6) The tanh() function and some other functions
>> compute the exponent twice. By that I mean both
>> exp(x) as well as exp(-x). I believe that division would
>> be faster if exp(-x) were computed with (1 / exp(x)).
>> Or is there an issue with branch cuts that mandates the
>> potentially redundant calculation?

> I will have a look. Division is faster than exponentiation
> but the compiler may do smart things behind our back.
> I will try both versions. Thanks for this suggestion

You are right for compilers only dealing with built-ins.
Here again, considering my expectation that the big
users of boost::math::complex might be multiple-precision
and fixed-point types, division will almost always be faster.
I actually insist on this, unless there is an issue with branch cuts.

>> 7) I hope to find time to test this code further with
>> a tiny fixed-point class. But I might be too busy for
>> that extra work.

> This would be interesting to test. For what it is worth,
> I have tested the class with boost::rational but this does
> not allow to test the more complicated functions.

OK. I will try very hard to make the time for it next weekend
or sooner.

Keep up the good work, Matthieu!
Best regards, Chris.