|
Boost : |
From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2003-02-28 08:42:23
Somewhere in the E.U., le 28/02/2003
Bonjour
In article <3E5E2E00.7F23DE6A_at_[hidden]>,
Jason House <jhouse_at_[hidden]> wrote:
[SNIP]
> Is there an integer-based complex number class in existence in boost?
> If it supports >> and <<, then it could be used in the fixed point class
> just as naturally as an integer type. Of course the conversion to/from
> double really doesn't make much sense... So maybe there would be some
> trouble... I could imagine using some special coding tricks to make the
> conversion normally be to double, but be a double precision complex
> number class when an integer based complex number class is passed in...
> It's starting to sound more complicated to support complex numbers :(
> But all the requirements might already exist in boost :)
[SNIP]
You can always use ::std::complex<int>, for instance, but the
result is implementation dependant, as per the standard, and would not
be much interesting as it stands.
It could be made far more interesting (along with its
quaternionic and octonionic siblings) if it were rewriten for the
domains it would best suited to: number theory and cryptography (the
current complex & al are aimed at engineering and physics style
computations).
But then we really would like to instanciate then on finite
rings, and then we are faces with some limitation of the current
language on the types that can be used as default template parameters (I
did some work on that with Daryl Walker some time back, and we stopped
when we hit that limitation).
As well, and this meshes with the tack you are more likely
interested in, we would also need unlimited size integer-like classes.
There was talk some time ago as to fulfilling this need, but I do not
remember it comming to fruition. I had done things like that in the
past, for my thesis, with support for some trancendental functions, but
well, I already have too much to do in the short term...
Bon courage
Hubert Holin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk