Wht std.complex is needed?
MikeWh
cf725b-0 at yahoo.com
Sat May 16 15:08:21 PDT 2009
Why in the world would complex types be dropped from D? That's what drew me
and my collegues to the language in the first place! Our heritage
electromagnetics analysis code and antenna design software is all written in
FORTRAN for that reason. I've been writing our new antenna algorithms in D,
and I just finished a very clean FFT routine that leverages D's built-in
cdouble. Sure, there's work-arounds if complex weren't built in, but you
could make that same statement about almost any feature of the language.
Built-in complex type is a huge selling point in my field - I don't know
that I would stop using D if complex types went away, but I can say with
certainty we would not have adopted D in the first place without it.
Mike
"Don" <nospam at nospam.com> wrote in message
news:grclgp$2kj3$1 at digitalmars.com...
> bearophile wrote:
>> Sam Hu:
>>> Doesn't D already has the built-in types cfloat, cdouble, creal,
>>> ifloat, idouble, and ireal?What's the advantage having complex class
>>> instead?
>
> The intention is that cfloat, cdouble,... will be deprecated eventually.
>
> I don't think std.complex should be part of Phobos yet, it needs some
> major work -- in particular, polar coordinates are just asking for
> trouble, especially as currently implemented. The angle 'arg' needs to be
> fixed point, otherwise you get a roundoff nightmare.
> Even assert(z == - (-z)) can fail!
>
>>
>> Some people have discussed/complained that complex types aren't worth
>> being built-ins, so the *struct* Complex of std.complex of D2 will
>> replace them. (I am not sure such complex struct is as good as the
>> current built-ins, but it seems most D1 users don't use complex numbers
>> much, so they don't care).
>>
>> Bye,
>> bearophile
More information about the Digitalmars-d-learn
mailing list