• Mark Evans (8/8) Sep 16 2002 If the documentation is correct,
• Walter (6/14) Sep 17 2002 Yes, this may need to change. -Walter
• Mac Reiter (20/40) Sep 17 2002 I don't do a lot of work with complex and imaginary, but how bad would i...
• Walter (5/10) Sep 17 2002 be to
• Mark Evans (13/24) Sep 17 2002 I completely agree with float32, float64, etc. and wish those were the b...
• Walter (13/24) Sep 18 2002 built-in
• Mac Reiter (39/66) Sep 18 2002 Hmmm. Thinking with my fingers again... If we had a quaternion templat...
• Mark Evans (6/8) Sep 18 2002 Everyone keeps talking about aliases; they are nice but the point is thi...
• Sandor Hojtsy (11/18) Sep 19 2002 the
• Mark Evans (17/17) Sep 21 2002 Responding to the D online documentation for complex numbers, the major ...

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

"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

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

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

"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

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

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.

"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

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.

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

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

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

"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

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

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