Boost logo

Boost :

Subject: Re: [boost] Determining interest: Pure imaginary number library
From: Matthieu Schaller (matthieu.schaller_at_[hidden])
Date: 2011-12-26 12:34:22

Le dimanche 25 décembre 2011, Vicente Botet <vicente.botet_at_[hidden]> a
écrit :
> Matthieu Schaller wrote
>> Le 29. 11. 11 17:31, Matthieu Schaller a écrit :
>>> Le 29. 11. 11 12:39, John Maddock a écrit :
>>>>> I also think that it will be worth defining a boost::complex class
>>>>> on the style of the rejected standard proposal that will integrate
>>>>> better with the imaginary class.
>>>>> The standard complex class has a constraint that a boost::complex
>>>>> class could avoid, it only accepts the builtin double and float
>>>>> types. This complex class could accept any type conforming to the
>>>>> expected Concept. I'm sure that others are expecting a complex class
>>>>> that can be used with specific classes, as arbitrary precision, ...
>>> This can be done. The boost::complex class could simply be an
>>> implementation of the n1869 draft by Thorsten Ottosen then:
>>> With the addition of the TR1 reciprocal trigonometric functions and
>>> the small updates brought by C++11.
>>> On top of this, some mathematical operators could be specialized for
>>> float and double if some performance improvements can be obtained in
>>> those cases.
>>> I will work on this.
>> Dear all,
>> Some news about this idea. I worked on an implementation of a complex
>> number library which should work with any time T providing the relevant
>> operators and basic mathematical functions.
>> The design I had in mind is the following: provide a template class and
>> specialisations for the float, double and long double types using the
>> basic mathematical SL functions for these three types wherever required.
>> This is fine and works in a satisfactory way in terms of precision. Now,
>> this way of doing the computation is much slower than the SL version of
>> std::complex<>. This is simply because the standard functions use
>> built-in functions which in some cases can be as much as ten times
>> faster than purely applying the mathematical definition. In other words
>> a boost::complex<> library would be outperformed by the std::complex<>
>> library in almost all non-trivial computations when used with the POD
>> floating point numbers.
>> Does someone have an idea of how these issue could be solved ? As such a
>> performance drop almost kills all the motivation to use such a
>> boost::complex<> class.
> Is there anything that prevents the use of the standard std:.complex in
> specializations of boost::complex<> boost::imaginary<> for float and

Nothing but the idea of having a stand-alone package.



Boost list run by bdawes at, gregod at, cpdaniel at, john at