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
>> 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
> I will replace
> T& imag();
>> const T& imag() const;
>> 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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk