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

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
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
>
>

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
>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
>>
>>
>
>

"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
be to
> 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.

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
>be to
>> 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.
>
>
>

"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
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).

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

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
>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).
>
>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

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

"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
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.

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

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