Re: [boost] Determining interest: Pure imaginary number library

Subject: Re: [boost] Determining interest: Pure imaginary number library
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-11-19 12:47:37

Le 19/11/11 12:21, Matthieu Schaller a écrit :
> Thank you for your interest and your input.
>
> I have corrected the mistakes spotted by Francis Smit and added casts
> from/to std::complex as suggested by Vicente Botet.
>
> Some comments about your proposals.
>
> Comparing imaginary and reals seems confusing to me
>> ///Returns true if x equals y
>> template<typename T>
>> inline bool operator==(const Imaginary<T>&  x, const T&  y);
>> template<typename T>
>> inline bool operator==(const T&  x, const Imaginary<T>&  y);
>>
>
> The SL offers comparison between std::complex<T>  and T which only compare
> the real part of the complex number and verifies that its imaginary part is
> zero. I do the same here: I compare the imaginary part of both arguments
> and verify that the real part of the complex is zero.
>
Ummm, yes but an imaginary is not a real, and the comparison works only 
when both are 0. Is this really useful?
>
>> The following divide assign operator is missing:
>>
>>   Imaginary<T>&  operator/=(const Imaginary<T>&  rhs)
>
> I don't think so. If you divide an imaginary number by another imaginary
> number you obtain a real number which cannot be represented by this class.
> Hence, the absence of this operator. The same is true for *=.
Sorry for my ignorance :(
>
>
>> Many years ago I proposed
>>
>> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html
>>
>> Maybe it can be of interest.
>
> This looks like what I'm presenting here. Your proposal goes further in the
> sense that it also modifies std::complex<T>  to add the relevant
> constructors and operators to the SL complex class but I can't do that here
> even if it would be more "symmetric" vis-a-vis the real numbers. The
> complex class could be modified to interact in a better way with pure
> imaginary numbers but this cannot really be done.
What about defining a boost::complex<> class that behaves like the 
proposed one.
>
> I will replace
>
> T&  imag();
>>     const T&  imag() const;
>>
>> by
>>
>>     T imag() const;
>
> I have modified the code as you suggested as it seems that the norm imposes
> the latter form for std::complex. Even though I don't really see why. A
> non-const access could simplify the notation in some cases and I don't see
> any smarter implementation than just
> T m_real;
> T m_imag;
> but I will conform to the norm and only provide const access.
>
>
> While I like the trick, it could break a lot of code. Could the addition of
>> a user literal allow to use it as
>>
>> complex_t z = 4.2 + 3.0i;
>>
> I haven't had a look at this until now but this may allow to simplify the
> notation even more. I see a slight drawback: it uses a C++11 feature which
> prevents its use with older compilers and these are often the compilers
> used by scientists on computing platforms. It is quite rare to have access
> to the last compiler versions in numerical computing.
Maybe defining a variable i inside a specific namespace could avoid
complex_t z = 4.2 + 3.0 imag::i;
> Thanks again for your input. I will "boostify" the code to make it follow
> more closely the code guiding rules, add a boost-like documentation and
> prepare more examples.
Good luck,
Vicente