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