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-28 17:46:13

Le 25/11/11 10:35, Matthieu Schaller a écrit :
> Dear all,
>
> My advice would be to boostify the code, write the documentation including
>> as much performances tests as you consider could help to consider this
>> library a should have.
>
> I have modified the code to match the quality criterions, added a
> comprehensive (doxygen) documentation and modified all the directories to
> mimic the main trunk.
The directory structure is

- boost
-- imaginary
- libs
-- imaginary
--- test
--- doc
--- example
--- perf (if you have some performance tests)

> You can also find in the sources a test file which tests all operators and
> functions for accuracy. It uses boost::test and shows that all functions
> are accurate within 10e-12 (four doubles) when compared to the same
> computation done with std::complex<>. When the result is not completely
> identical, the imaginary<>  class version is always closer to the analytical
> result than the std::complex<>  one.
> The only exception is the tanh() function which differs from the
> std::complex<>  one by 1e-9 for numbers close to 0.
>
> I have also added another example (computing the Julia fractal set in
> mathematics) showing a ~5% gain in performance. The speed-up in this case
> is much less impressive but the algorithm does not only use imaginary
> numbers.
>
> I could also provide an example which brutally compares the speed of some
> functions and operators but I prefer presenting real applications rather
> than artificially improved codes.
This is right for the examples section, but I would add some performance 
tests for the specific operations that will reinforce the motivation.
> Is there something that could obviously be improved ?

Quickbook documentation, a motivation section, + a performance analysis 
section.

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, ...
> Is there some interest in pushing this further ?
Yes sure.

Best,
Vicente