www.digitalmars.com         C & C++   DMDScript  

D - Complex Numbers

reply Mark Evans <Mark_member pathlink.com> writes:
If the documentation is correct,

http://www.digitalmars.com/d/index.html

then type 'complex' is implemented with extended-precision parts.  I'd suggest
changing this to double-precision if there is to be only 'one' kind of complex
number.  That would be a more standard choice.  (Think of all the cross-platform
and file i/o issues for example.)

Thanks Walter!

Mark
Sep 16 2002
parent reply "Walter" <walter digitalmars.com> writes:
Yes, this may need to change. -Walter

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:am5m9k$52h$1 digitaldaemon.com...
 If the documentation is correct,

 http://www.digitalmars.com/d/index.html

 then type 'complex' is implemented with extended-precision parts.  I'd

 changing this to double-precision if there is to be only 'one' kind of

 number.  That would be a more standard choice.  (Think of all the

 and file i/o issues for example.)

 Thanks Walter!

 Mark

Sep 17 2002
parent reply Mac Reiter <Mac_member pathlink.com> writes:
I don't do a lot of work with complex and imaginary, but how bad would it be to
have:

float complex c;
double complex d;
extended complex e;

and the imaginary equivalents, of course...  I thought about:

complex<float> c;

but that looks too much like the C++ templated class approach, so I figured I'd
avoid it.

Of course, I prefer:

float32, float64, float80

over float/double/extended anyway.  If such a naming scheme was instituted, then
complex and imaginary would of course become:

complex32, complex64, complex80, imaginary32, imaginary64, imaginary80

unless you wanted to be pedantic, in which case the imaginaries would stay as
above and the complex would be (since they have two floating point values in
them):

complex64, complex128, complex160

Mac

In article <am7lko$2bic$1 digitaldaemon.com>, Walter says...
Yes, this may need to change. -Walter

"Mark Evans" <Mark_member pathlink.com> wrote in message
news:am5m9k$52h$1 digitaldaemon.com...
 If the documentation is correct,

 http://www.digitalmars.com/d/index.html

 then type 'complex' is implemented with extended-precision parts.  I'd

 changing this to double-precision if there is to be only 'one' kind of

 number.  That would be a more standard choice.  (Think of all the

 and file i/o issues for example.)

 Thanks Walter!

 Mark


Sep 17 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:am8999$3v$1 digitaldaemon.com...
 I don't do a lot of work with complex and imaginary, but how bad would it

 have:

 float complex c;
 double complex d;
 extended complex e;

That'd probably work the best. They're already implemented throughout the compiler, there's just no syntax for it.
Sep 17 2002
parent reply Mark Evans <Mark_member pathlink.com> writes:
I completely agree with float32, float64, etc. and wish those were the built-in
names...but I've already written on that.  Thanks for the seconding motion Mac!

Does "double complex" make sense from a consistency standpoint?  Syntactically
this phrase bears no relation to D template classes.  Maybe that is a Good Thing
for built-ins...but maybe it's just confusing.

There are other mathematical objects whose implementation *would* be template
classes (quaternions, Matrix Template Library sort of stuff, etc.) and it would
be rather awful to have complex numbers use a different syntax than all the
other template objects.

I'd vote for a syntax matching the template syntax even if complex numbers are
built-ins.  Then they would just be built-in template classes (always defined).

Mark


In article <am8upo$mb4$1 digitaldaemon.com>, Walter says...
"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:am8999$3v$1 digitaldaemon.com...
 I don't do a lot of work with complex and imaginary, but how bad would it

 have:

 float complex c;
 double complex d;
 extended complex e;

That'd probably work the best. They're already implemented throughout the compiler, there's just no syntax for it.

Sep 17 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:am93g5$rdj$1 digitaldaemon.com...
 I completely agree with float32, float64, etc. and wish those were the

 names...but I've already written on that.  Thanks for the seconding motion

 Does "double complex" make sense from a consistency standpoint?

 this phrase bears no relation to D template classes.  Maybe that is a Good

 for built-ins...but maybe it's just confusing.

 There are other mathematical objects whose implementation *would* be

 classes (quaternions, Matrix Template Library sort of stuff, etc.) and it

 be rather awful to have complex numbers use a different syntax than all

 other template objects.

 I'd vote for a syntax matching the template syntax even if complex numbers

 built-ins.  Then they would just be built-in template classes (always

D has templates, but doesn't really have template classes in the sense that C++ does. So I'm not sure what you mean.
Sep 18 2002
parent reply Mac Reiter <Mac_member pathlink.com> writes:
In article <ama72t$24pc$1 digitaldaemon.com>, Walter says...
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:am93g5$rdj$1 digitaldaemon.com...
 I completely agree with float32, float64, etc. and wish those were the

 names...but I've already written on that.  Thanks for the seconding motion

 Does "double complex" make sense from a consistency standpoint?

 this phrase bears no relation to D template classes.  Maybe that is a Good

 for built-ins...but maybe it's just confusing.

 There are other mathematical objects whose implementation *would* be

 classes (quaternions, Matrix Template Library sort of stuff, etc.) and it

 be rather awful to have complex numbers use a different syntax than all

 other template objects.

 I'd vote for a syntax matching the template syntax even if complex numbers

 built-ins.  Then they would just be built-in template classes (always

D has templates, but doesn't really have template classes in the sense that C++ does. So I'm not sure what you mean.

Hmmm. Thinking with my fingers again... If we had a quaternion template, we would do something like: instance quaternion(double) q64; q64.quaternion MyQuaternion; or maybe even add a: alias q64.quaternion quat64; quat64 AnotherQuaternion; or any of the other things that have been suggested ("with q64", "using template quaternion(double)", etc) So what would be a similar syntax for the built in complex? Presumably, the only thing inside the pseudo-template would be the complex type itself, resulting in something like: complex(double).complex MyComplex; // if you can shorthand, which I seem to // remember you can't, so nevermind... instance complex(double) c64; alias c64.complex complex64; complex64 MyComplex; Not really sure that that gets you anything. If you were to try to standardize it, all you could really standardize while maintaining the template syntax is the actual "instance complex(double) pick_a_name;" part. Basically, you would parameterize your built-in types, recognize when someone made a variable of a built-in type and use optimized code for those, and then either disallow or create real templatized support for other types. For instance, given the template syntax, someone who wanted maximal accuracy and was willing to sacrifice speed might try something like this: instance complex(symbolic) fullcomplex; (Assuming that symbolic is a class that provides mathematical operations and tracks values symbolically internally, like Mathematica or other heavy duty programs for mathematicians) The resulting class would be much slower than complex(double), but it would still work. Or, you could disallow these extended forms, sort of like in C++ when you do a template specialization for some types and you don't provide a specialization for "any" type, so it causes a compilation error if instantiated with any other type. Of course, for convenience, you would almost certainly do the aliases somewhere in phobos, at which point everyone will use the alias, and you might as well just pick a name (unless you actually do want to make the template for complex and allow people to instantiate it for strange types). Mac
Sep 18 2002
parent reply Mark Evans <Mark_member pathlink.com> writes:
Maybe those are good points.  Well, as I said, my preferences fall along the
lines of Complex32, Complex64, Complex80, Complex128, no templates needed.

Of course, for convenience, you would almost certainly do the aliases somewhere
in phobos

Everyone keeps talking about aliases; they are nice but the point is this: Native types should have semantically rational names even if they break tradition. Aliases in Phobos can then support "traditional" nomenclature. Mark
Sep 18 2002
next sibling parent "Sandor Hojtsy" <hojtsy index.hu> writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:amb1i2$a3$1 digitaldaemon.com...
 Maybe those are good points.  Well, as I said, my preferences fall along

 lines of Complex32, Complex64, Complex80, Complex128, no templates needed.

Of course, for convenience, you would almost certainly do the aliases


in phobos

Everyone keeps talking about aliases; they are nice but the point is this: Native types should have semantically rational names even if they break tradition. Aliases in Phobos can then support "traditional" nomenclature.

Yes, break those old (C) traditions please. And I think we don't even need aliases for "backward compatibility" with C or whatever. Don't think of the (C) programmers as silly ones. A good programmer can easily adopt to a new (better) typename set. Yours, Sandor
Sep 19 2002
prev sibling parent Mark Evans <Mark_member pathlink.com> writes:
Responding to the D online documentation for complex numbers, the major need for
multiple complex types arises in file i/o.  Nobody wants to store extended
precision to disk.  Primarily because every platform has its own extended type,
but also to save space.  Most people use double precision; in some cases single
precision.  (Perhaps disk streaming of complex numbers could be supported in
some way that would not involve whole new complex types.)

I would like to see more properties on complex numbers, specifically .arg and
mag which are the polar form, perhaps .conj too (conjugate).

Mark

Documentation:

Adding two new types to the language is enough, hence complex and imaginary have
extended precision. There is no complex float or complex double type, and no
imaginary float or imaginary double. [NOTE: the door is open to adding them in
the future, but I doubt there's a need] 

Complex numbers have two properties: 

re get real part as an extended
im get imaginary part as an imaginary
Sep 21 2002