Some time ago I wrote some complex number functions for std.math, but they were not really usable because of the implicit real->creal conversion issue. Now that that problem has been removed in DMD 0.150, several could be added.

There are a few issues to be addressed, though:
* The function cos(x) + I*sin(x), which on x86 machines is very efficient, and available through the FSINCOS asm instruction (the only CPU support for complex numbers!) is important for many of these functions, and it could usefully become an intrinsic.
What should it be called? Ideas I've had
creal exp(ireal x)  -- It's correct, but I don't think this 'feels' like
		      an intrinsic.
creal cis(real x)   -- namespace pollution could be an issue
creal cosisin(real x) -- doesn't this look a bit silly?
creal fcis(real x)  -- mirrors fabs(), this is what I put into Ares,
                    but is it too obscure?

* DDoc comments.
Should sin(creal) be with sin(real) ? Or should the complex trig functions be put together?

Don Clugston wrote:
> Some time ago I wrote some complex number functions for std.math, but they were not really usable because of the implicit real->creal conversion issue. Now that that problem has been removed in DMD 0.150, several could be added.
> 
> There are a few issues to be addressed, though:
> * The function cos(x) + I*sin(x), which on x86 machines is very
> efficient, and available through the FSINCOS asm instruction (the only
> CPU support for complex numbers!) is important for many of these
> functions, and it could usefully become an intrinsic.
> What should it be called? Ideas I've had
> creal exp(ireal x)  -- It's correct, but I don't think this 'feels' like
>               an intrinsic.
> creal cis(real x)   -- namespace pollution could be an issue
> creal cosisin(real x) -- doesn't this look a bit silly?
> creal fcis(real x)  -- mirrors fabs(), this is what I put into Ares,
>                     but is it too obscure?

How about
        alias creal complex;
	complex expi(real x)
reflecting the fact that it actually computes exp(I*x)?

(Sorry for writing "complex" instead of the monstrosity "creal". My fingers just don't obey me when I command them to write about a "complex real" number. Of course, "creal" could also stand for "really complex". But then "real" should be renamed into "cnreal", standing for "not really complex"...)

> 
> * DDoc comments.
> Should sin(creal) be with sin(real) ? Or should the complex trig
> functions be put together?
> 

Norbert Nemec wrote:
> Don Clugston wrote:
>> Some time ago I wrote some complex number functions for std.math, but
>> they were not really usable because of the implicit real->creal
>> conversion issue. Now that that problem has been removed in DMD 0.150,
>> several could be added.
>>
>> There are a few issues to be addressed, though:
>> * The function cos(x) + I*sin(x), which on x86 machines is very
>> efficient, and available through the FSINCOS asm instruction (the only
>> CPU support for complex numbers!) is important for many of these
>> functions, and it could usefully become an intrinsic.
>> What should it be called? Ideas I've had
>> creal exp(ireal x)  -- It's correct, but I don't think this 'feels' like
>>               an intrinsic.
>> creal cis(real x)   -- namespace pollution could be an issue
>> creal cosisin(real x) -- doesn't this look a bit silly?
>> creal fcis(real x)  -- mirrors fabs(), this is what I put into Ares,
>>                     but is it too obscure?
> 
> How about
>         alias creal complex;
> 	complex expi(real x)
> reflecting the fact that it actually computes exp(I*x)?

That's not bad. I think I'll go with that. Thanks.

> 
> (Sorry for writing "complex" instead of the monstrosity "creal". My
> fingers just don't obey me when I command them to write about a
> "complex real" number. Of course, "creal" could also stand for "really
> complex". But then "real" should be renamed into "cnreal", standing for
> "not really complex"...)

It is a bit of an oxymoron. I do like the idea of having 'complex' as a standard alias in std.math. It should operate almost as a reserved word, users should not be defining it to be anything other than creal.
But I would not like to have to type "imaginary" instead of "ireal" -- it's just too long. Any ideas on that one?

FWIW, the name "imaginary" is a bit stupid, too. In what sense is a negative "real" number more "real" than an "imaginary" number? Arguably, D is just continuing the trend of inappropriate names <g>.

>> * DDoc comments.
>> Should sin(creal) be with sin(real) ? Or should the complex trig
>> functions be put together?
>>

Don Clugston wrote:
> Norbert Nemec wrote:
>> (Sorry for writing "complex" instead of the monstrosity "creal". My
>> fingers just don't obey me when I command them to write about a
>> "complex real" number. Of course, "creal" could also stand for "really
>> complex". But then "real" should be renamed into "cnreal", standing for
>> "not really complex"...)
> 
> It is a bit of an oxymoron. I do like the idea of having 'complex' as a standard alias in std.math. It should operate almost as a reserved word, users should not be defining it to be anything other than creal.
> But I would not like to have to type "imaginary" instead of "ireal" -- it's just too long. Any ideas on that one?
> 

Here's what I've devised for a floating-point type system similar to D's:

   single - real single-precision (32-bit) IEEE 754 floating point
  isingle - imaginary single-precision (32-bit) IEEE 754 floating poi$
  csingle - complex single

   double - real double-precision (64-bit) IEEE 754 floating point
  idouble - imaginary double-precision (64-bit) IEEE 754 floating poi$
  cdouble - complex double

 extended - real extended-precision (80-bit) IEEE 754 floating point
iextended - imaginary extended-precision (80-bit) IEEE 754 floating point
cextended - complex extended

    float - alias for  single
   ifloat - alias for isingle
   cfloat - alias for csingle

Notably, the float has been renamed to single, and real has been renamed to extended.  Float still lurks around as an alias for single though.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O M--@ V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne

James Dunne wrote:
> Don Clugston wrote:
>> Norbert Nemec wrote:
>>> (Sorry for writing "complex" instead of the monstrosity "creal". My
>>> fingers just don't obey me when I command them to write about a
>>> "complex real" number. Of course, "creal" could also stand for "really
>>> complex". But then "real" should be renamed into "cnreal", standing for
>>> "not really complex"...)
>>
>> It is a bit of an oxymoron. I do like the idea of having 'complex' as a standard alias in std.math. It should operate almost as a reserved word, users should not be defining it to be anything other than creal.
>> But I would not like to have to type "imaginary" instead of "ireal" -- it's just too long. Any ideas on that one?
>>
> 
> Here's what I've devised for a floating-point type system similar to D's:
> 
>    single - real single-precision (32-bit) IEEE 754 floating point
>   isingle - imaginary single-precision (32-bit) IEEE 754 floating poi$
>   csingle - complex single
> 
>    double - real double-precision (64-bit) IEEE 754 floating point
>   idouble - imaginary double-precision (64-bit) IEEE 754 floating poi$
>   cdouble - complex double
> 
>  extended - real extended-precision (80-bit) IEEE 754 floating point
> iextended - imaginary extended-precision (80-bit) IEEE 754 floating point
> cextended - complex extended
> 
>     float - alias for  single
>    ifloat - alias for isingle
>    cfloat - alias for csingle
> 
> Notably, the float has been renamed to single, and real has been renamed to extended.  Float still lurks around as an alias for single though.

Something that I *really* like about 'real' is that it's short, so it becomes used by default. I think with your naming scheme, everyone would use double by default.

If we could start afresh, the best way I think would be to have single, double, extended, and have 'float' as an alias for extended. Unfortunately, 'float' is too heavily entrenched as a low-precision floating point number.

James Dunne wrote:

> Here's what I've devised for a floating-point type system similar to D's:

I think you should also include half (16-bit) and quad (128-bit) floats.

--anders

In article <e15v1k$1qnu$1@digitaldaemon.com>, James Dunne says...
>
>Don Clugston wrote:
>> Norbert Nemec wrote:
>>> (Sorry for writing "complex" instead of the monstrosity "creal". My fingers just don't obey me when I command them to write about a "complex real" number. Of course, "creal" could also stand for "really complex". But then "real" should be renamed into "cnreal", standing for "not really complex"...)
>> 
>> It is a bit of an oxymoron. I do like the idea of having 'complex' as a
>> standard alias in std.math. It should operate almost as a reserved word,
>> users should not be defining it to be anything other than creal.
>> But I would not like to have to type "imaginary" instead of "ireal" --
>> it's just too long. Any ideas on that one?
>> 
>
>Here's what I've devised for a floating-point type system similar to D's:
>
>    single - real single-precision (32-bit) IEEE 754 floating point
>   isingle - imaginary single-precision (32-bit) IEEE 754 floating poi$
>   csingle - complex single
>
>    double - real double-precision (64-bit) IEEE 754 floating point
>   idouble - imaginary double-precision (64-bit) IEEE 754 floating poi$
>   cdouble - complex double
>
>  extended - real extended-precision (80-bit) IEEE 754 floating point
>iextended - imaginary extended-precision (80-bit) IEEE 754 floating point cextended - complex extended
>
>     float - alias for  single
>    ifloat - alias for isingle
>    cfloat - alias for csingle
>
>Notably, the float has been renamed to single, and real has been renamed to extended.  Float still lurks around as an alias for single though.
>

Since 'float' is included as an alias that C/++ programmers would be familiar with, I like this scheme, except 'extended' isn't intuitive, especially on machines that don't support > 64 bit fp.

Any ideas there?

>-- 
>-----BEGIN GEEK CODE BLOCK-----
>Version: 3.1
>GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O
>M--@ V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e
>h>--->++ r+++ y+++
>------END GEEK CODE BLOCK------
>
>James Dunne

James Dunne wrote:
> Don Clugston wrote:
>> Norbert Nemec wrote:
>>> (Sorry for writing "complex" instead of the monstrosity "creal". My
>>> fingers just don't obey me when I command them to write about a
>>> "complex real" number. Of course, "creal" could also stand for "really
>>> complex". But then "real" should be renamed into "cnreal", standing for
>>> "not really complex"...)
>>
>> It is a bit of an oxymoron. I do like the idea of having 'complex' as a standard alias in std.math. It should operate almost as a reserved word, users should not be defining it to be anything other than creal.
>> But I would not like to have to type "imaginary" instead of "ireal" -- it's just too long. Any ideas on that one?
>>
> 
> Here's what I've devised for a floating-point type system similar to D's:
> 
>    single - real single-precision (32-bit) IEEE 754 floating point
>   isingle - imaginary single-precision (32-bit) IEEE 754 floating poi$
>   csingle - complex single
> 
>    double - real double-precision (64-bit) IEEE 754 floating point
>   idouble - imaginary double-precision (64-bit) IEEE 754 floating poi$
>   cdouble - complex double
> 
>  extended - real extended-precision (80-bit) IEEE 754 floating point
> iextended - imaginary extended-precision (80-bit) IEEE 754 floating point
> cextended - complex extended
> 
>     float - alias for  single
>    ifloat - alias for isingle
>    cfloat - alias for csingle
> 
> Notably, the float has been renamed to single, and real has been renamed to extended.  Float still lurks around as an alias for single though.
> 

How about this:

floats   ifloats   cfloats
floatd   ifloatd   cfloatd
floate   ifloats   cfloatd

floatc   ifloatc   cfloats
floath   ifloath   cfloatd

Another alternative:

float32  ifloat32  cfloat32
float64  ...
float80
float128
float16

etc. Just exploring alternatives, not actually suggesting it, but I prefer a nomenclature that actually mentions that the type is a floating point number. ("single", "extended"? Single what? Extended what?)

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Don Clugston wrote:
> It is a bit of an oxymoron. I do like the idea of having 'complex' as a
> standard alias in std.math. It should operate almost as a reserved word,
> users should not be defining it to be anything other than creal.
> But I would not like to have to type "imaginary" instead of "ireal" --
> it's just too long. Any ideas on that one?

It would not be a problem that "imaginary" is such a long word: this type is hardly ever used when coding. Maybe in special places inside a library, but I cannot imagine any user-code that actually needs to declare a variable of that type. Either you code real or complex, but coding purely imaginary is pointless.

> FWIW, the name "imaginary" is a bit stupid, too. In what sense is a negative "real" number more "real" than an "imaginary" number? Arguably, D is just continuing the trend of inappropriate names <g>.

Well, I tend to think about redefining nonsensical conventions myself. I just hate it when *others* do it. :-)

Seriously: communications is never about using the "right" term, but always about using a term that people understand most easily. And the best way to handle stupid conventions: don't change them unless you already are an unquestioned guru in the field.

Norbert Nemec wrote:
> Don Clugston wrote:
>> It is a bit of an oxymoron. I do like the idea of having 'complex' as a
>> standard alias in std.math. It should operate almost as a reserved word,
>> users should not be defining it to be anything other than creal.
>> But I would not like to have to type "imaginary" instead of "ireal" --
>> it's just too long. Any ideas on that one?
> 
> It would not be a problem that "imaginary" is such a long word: this
> type is hardly ever used when coding. Maybe in special places inside a
> library, but I cannot imagine any user-code that actually needs to
> declare a variable of that type. Either you code real or complex, but
> coding purely imaginary is pointless.

You've convinced me. Having just done functions for pure imaginary arguments I have a very warped perspective right now. It's a very annoying type to work with -- it's not closed under basic arithmetic operations. And probably, most of the remaining uses of it are covered by automatic type inference.
eg.
const I = 1i;
instead of
const imaginary I = 1i;

>> FWIW, the name "imaginary" is a bit stupid, too. In what sense is a
>> negative "real" number more "real" than an "imaginary" number? Arguably,
>> D is just continuing the trend of inappropriate names <g>.
> 
> Well, I tend to think about redefining nonsensical conventions myself. I
> just hate it when *others* do it. :-)
> 
> Seriously: communications is never about using the "right" term, but
> always about using a term that people understand most easily. And the
> best way to handle stupid conventions: don't change them unless you
> already are an unquestioned guru in the field.

And do your best to avoid creating them, regardless of whether you are an unquestioned guru in the field.

I think we could easily amass a lobby group of 100% of the users of complex numbers in D to have a 'complex' alias set up in math.d. And gradually phase out use of creal (which I think would be better named cfloat80 or similar -- make the underlying type itself be of fixed size).