$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] Determining interest: Pure imaginary number library
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-12-25 06:51:23
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:
>>
>> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html
>>
>> 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 the
specializations of boost::complex<> boost::imaginary<> for float and double?
Vicente
-- View this message in context: http://boost.2283326.n4.nabble.com/Determining-interest-Pure-imaginary-number-library-tp4075796p4232789.html Sent from the Boost - Dev mailing list archive at Nabble.com.