www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Complex number functions for std.math

reply Don Clugston <dac nospam.com.au> writes:
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?
Mar 30 2006
parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
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?
Mar 31 2006
parent reply Don Clugston <dac nospam.com.au> writes:
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?
Apr 07 2006
next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
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
Apr 07 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
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.
Apr 07 2006
parent James Dunne <james.jdunne gmail.com> writes:
Don Clugston wrote:

 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.


Brevity is ... wit.


 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.


I agree with your assesment on 'float'.  Sometimes traditions just have 
to be broken though.  .NET did it when assigning new meaning to the word 
'assembly'; I remember at first I was completely lost.

Thanks for the input!

-- 
Regards,
James Dunne
Apr 09 2006
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Apr 07 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
Anders F Björklund wrote:

 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


Are they IEEE 754 standardized?  I'll take a look into this.  Thanks!

-- 
Regards,
James Dunne
Apr 09 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
James Dunne wrote:


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


 
 Are they IEEE 754 standardized?  I'll take a look into this.  Thanks!


No, but they follow the same format. "IEEE-compatible", perhaps ?

http://en.wikipedia.org/wiki/Half_precision
http://en.wikipedia.org/wiki/Single_precision
http://en.wikipedia.org/wiki/Double_precision
http://en.wikipedia.org/wiki/Quad_precision

I think that quads are now included in IEEE 754r (for "revised")

--anders
Apr 09 2006
parent reply James Dunne <james.jdunne gmail.com> writes:
Anders F Björklund wrote:

 James Dunne wrote:
 

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



 Are they IEEE 754 standardized?  I'll take a look into this.  Thanks!


 
 
 No, but they follow the same format. "IEEE-compatible", perhaps ?
 
 http://en.wikipedia.org/wiki/Half_precision
 http://en.wikipedia.org/wiki/Single_precision
 http://en.wikipedia.org/wiki/Double_precision
 http://en.wikipedia.org/wiki/Quad_precision
 
 I think that quads are now included in IEEE 754r (for "revised")
 
 --anders


So, software-supported half-precision and hardware-supported 
quad-precision (if available)?  Sounds interesting...

Why not throw in fixed-point types as well?

-- 
Regards,
James Dunne
Apr 09 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
James Dunne wrote:


 So, software-supported half-precision and hardware-supported 
 quad-precision (if available)?  Sounds interesting...


I think that SoftFloat has 128-bit support, but I've only seen the 
double-double implementation in hardware (and it is *not* full IEEE)

There is an open source (C++) implementation of half from OpenEXR,
it uses unsigned short for storage and float for all calculations...

"single" and "double" are the ones usually present in hardware,
"extended" and "quad" might be available, and "half" never is.
(unless you count the graphics hardware, since OpenGL and some
GPU cards do have support for 16-bit floating point channels...)

As discussed earlier, type "real" is easiest to do as an alias.


 Why not throw in fixed-point types as well?


Oh, I thought you were talking about floating point formats here ?
I think that IEEE now includes fixed-point too, but haven't checked.

--anders
Apr 09 2006
prev sibling next sibling parent reply Dave <Dave_member pathlink.com> writes:
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
Apr 07 2006
parent James Dunne <james.jdunne gmail.com> writes:
Dave wrote:

 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


 
 


I guess...

	half
	single
	double
	twopt5
	quad

:)

But seriously though, I used 'extended' since it came from Borland's 
Pascal which I was familiar with up until I learned C - it was a great 
transition between BASIC and C.  (see 
http://www.merlyn.demon.co.uk/pas-real.htm#FloatTypes)

I tend to favor the numbering scheme by postfixing the number of bits 
required by the type to the base name of the type:

	float16
	float32
	float64
	float80
	float128

Perhaps these should be the base types with 'single', 'double', and 
'extended' as aliases for the common ones?

-- 
Regards,
James Dunne
Apr 09 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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
Apr 08 2006
parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
 float32  ifloat32  cfloat32
 float64  ...
 float80
 float128
 float16


In my opinion these are the best ones as they make it clear that it is a 
floating point number and how big it is.
Apr 08 2006
parent James Dunne <james.jdunne gmail.com> writes:
Johan Granberg wrote:

 

 float32  ifloat32  cfloat32
 float64  ...
 float80
 float128
 float16


 
 
 In my opinion these are the best ones as they make it clear that it is a 
 floating point number and how big it is.


Yes they do, but unfortunately hardware limitations come into play - one 
wouldn't want code breaking all over the place if 80-bit floats were not 
available on the target architecture.  (Assuming that the 
higher-precision types wouldn't be cast down to the highest-precision 
type available on the target architecture)

-- 
Regards,
James Dunne
Apr 09 2006
prev sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
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.
Apr 08 2006
parent reply Don Clugston <dac nospam.com.au> writes:
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).
Apr 08 2006
parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Don Clugston wrote:

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


Well, the whole discussion is pretty much pointless unless Walter is
willing to touch the topic again. When the topic came up two years ago,
the final sentence was something like: "Well, I agree that creal sounds
stupid, but we are not going to roll this up yet again." Obviously, the
name "creal" was the result of a tedious discussion a little while
before. That discussion was before my time and obviously nobody back
then had strong feelings against talking about "really complex numbers".
Therefore the final word still is: "Do in the library whatever you want,
the language definition will not be changed again."
Apr 08 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Norbert Nemec wrote:


 That discussion was before my time and obviously nobody back
 then had strong feelings against talking about "really complex numbers".


Walter didn't like the "extended" keyword, so he renamed it "real":
http://www.digitalmars.com/d/changelog.html#new054 [DMD 0.54, 2003]

Several people hated "imaginary real" and "complex real", though ?
But I guess they left and never came back, or something like that.


 Therefore the final word still is: "Do in the library whatever you want,
 the language definition will not be changed again."


That's my understanding as well, with the 64-128 bit floating type.
I'd rather have the basic D types be of a fixed size, but that's me.

The pragmatic approach is to use some aliases, or doubles instead...

--anders
Apr 09 2006
parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Anders F Bj=F6rklund wrote:

 Norbert Nemec wrote:
=20

 That discussion was before my time and obviously nobody back
 then had strong feelings against talking about "really complex numbers=




".

=20
=20
 Walter didn't like the "extended" keyword, so he renamed it "real":
 http://www.digitalmars.com/d/changelog.html#new054 [DMD 0.54, 2003]


That's interesting! This was nearly one year before I seriously got in
contact with D for the first time. I remember that the "creal/ireal"
names offended me right away when I read the specification. I wrote a
message about it to the newsgroup and people started discussing about
the type naming in all directions, but there didn't seem to be anybody
who even understood the irony of "complex real" and "imaginary real"
numbers.


 Several people hated "imaginary real" and "complex real", though ?
 But I guess they left and never came back, or something like that.


It really seems that people with mathematical background really either
left of gave up on the issue back then.


 Therefore the final word still is: "Do in the library whatever you wan=




t,

 the language definition will not be changed again."


=20
 That's my understanding as well, with the 64-128 bit floating type.
 I'd rather have the basic D types be of a fixed size, but that's me.


Exactly my opinion: The basic types should have well-defined bit-sizes
and be portable across architectures.

The best names for a floating point types with fixed bit size are type
names that have the bit-size incorporated: float32, float64, float80 and
so on. Correspondingly there would be ifloat32, ifloat64 and ifloat80.
For complex numbers, the naming is not obvious, but I would go for
cfloat32 for a complex float made up of two float32 numbers.

Any library interfacing C code would then probably define
	alias float32 float;
	alias float64 double;

The standard library should then pre-define the precious type names
"real", "complex" and "imaginary" to some reasonable default, that may
be architecture dependent and can easily be changed. The regular user
should be encouraged to use these aliases without depending on a fixed
size. This will result in code that can easily be compiled with a
different precision or moved inside a template library where "real"
becomes a parameter.

This would solve several problems:

* currently, there is no type name for 80-bit floats

* the current naming scheme has no obvious extension towards 16-bit,
128-bit or other bit-size floating point numbers.

* the current definition of "real" is dangerous:
"largest hardware implemented floating point size"
If you implemented D on some future architecture that supports 1024-bit
floats in hardware, "real" would have a float1024, even if the high
data-rate makes this a very bad general choice.

* the mechanism that determines the size of "real" is not clear at all.
It may be hard-wired in the compiler or there may be a compiler-switch
which is different for every implementations. Using plain aliases, the
mechanism is completely transparent any can use the full flexibility of
conditional compilation.

* The ridiculous concept of "really complex numbers" and "irreal"
numbers is finally off the table and D can stop being ashamed in view of
the seriously mathematical world.

Greetings,
Norbert
Apr 09 2006
next sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
B.t.w: just added this point to the "unofficial wishlist":
	http://all-technology.com/eigenpolls/dwishlist/index.php
under the name "Precise names for floats"

Please vote for it if you think it is important.



Norbert Nemec wrote:

 Anders F Bj=F6rklund wrote:
=20

Norbert Nemec wrote:



That discussion was before my time and obviously nobody back
then had strong feelings against talking about "really complex numbers=






".

Walter didn't like the "extended" keyword, so he renamed it "real":
http://www.digitalmars.com/d/changelog.html#new054 [DMD 0.54, 2003]


=20
=20
 That's interesting! This was nearly one year before I seriously got in
 contact with D for the first time. I remember that the "creal/ireal"
 names offended me right away when I read the specification. I wrote a
 message about it to the newsgroup and people started discussing about
 the type naming in all directions, but there didn't seem to be anybody
 who even understood the irony of "complex real" and "imaginary real"
 numbers.
=20
=20

Several people hated "imaginary real" and "complex real", though ?
But I guess they left and never came back, or something like that.


=20
=20
 It really seems that people with mathematical background really either
 left of gave up on the issue back then.
=20
=20

Therefore the final word still is: "Do in the library whatever you wan=






t,

the language definition will not be changed again."


That's my understanding as well, with the 64-128 bit floating type.
I'd rather have the basic D types be of a fixed size, but that's me.


=20
=20
 Exactly my opinion: The basic types should have well-defined bit-sizes
 and be portable across architectures.
=20
 The best names for a floating point types with fixed bit size are type
 names that have the bit-size incorporated: float32, float64, float80 an=


d

 so on. Correspondingly there would be ifloat32, ifloat64 and ifloat80.
 For complex numbers, the naming is not obvious, but I would go for
 cfloat32 for a complex float made up of two float32 numbers.
=20
 Any library interfacing C code would then probably define
 	alias float32 float;
 	alias float64 double;
=20
 The standard library should then pre-define the precious type names
 "real", "complex" and "imaginary" to some reasonable default, that may
 be architecture dependent and can easily be changed. The regular user
 should be encouraged to use these aliases without depending on a fixed
 size. This will result in code that can easily be compiled with a
 different precision or moved inside a template library where "real"
 becomes a parameter.
=20
 This would solve several problems:
=20
 * currently, there is no type name for 80-bit floats
=20
 * the current naming scheme has no obvious extension towards 16-bit,
 128-bit or other bit-size floating point numbers.
=20
 * the current definition of "real" is dangerous:
 "largest hardware implemented floating point size"
 If you implemented D on some future architecture that supports 1024-bit=



 floats in hardware, "real" would have a float1024, even if the high
 data-rate makes this a very bad general choice.
=20
 * the mechanism that determines the size of "real" is not clear at all.=



 It may be hard-wired in the compiler or there may be a compiler-switch
 which is different for every implementations. Using plain aliases, the
 mechanism is completely transparent any can use the full flexibility of=



 conditional compilation.
=20
 * The ridiculous concept of "really complex numbers" and "irreal"
 numbers is finally off the table and D can stop being ashamed in view o=


f

 the seriously mathematical world.
=20
 Greetings,
 Norbert
Apr 09 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Norbert Nemec wrote:


I'd rather have the basic D types be of a fixed size, but that's me.


 
 Exactly my opinion: The basic types should have well-defined bit-sizes
 and be portable across architectures.


It could just be a side-effect of DMD only targetting one architecture ?

The real type is 80 bits in register on all the supported platforms, it
just varies in size when stored to mem/disk (80 on Windows, 96 on Linux,
and will probably increase to 128 bit when 64-bit Linux is supported ?)
Usually it just follows the platform definition of "long double", for C.


 The best names for a floating point types with fixed bit size are type
 names that have the bit-size incorporated: float32, float64, float80 and
 so on. Correspondingly there would be ifloat32, ifloat64 and ifloat80.
 For complex numbers, the naming is not obvious, but I would go for
 cfloat32 for a complex float made up of two float32 numbers.
 
 Any library interfacing C code would then probably define
 	alias float32 float;
 	alias float64 double;
 
 The standard library should then pre-define the precious type names
 "real", "complex" and "imaginary" to some reasonable default, that may
 be architecture dependent and can easily be changed. The regular user
 should be encouraged to use these aliases without depending on a fixed
 size. This will result in code that can easily be compiled with a
 different precision or moved inside a template library where "real"
 becomes a parameter.


I had a similar suggestion, but the other way around... Keep the
current type names, and added the bitsizenames as aliases instead.
(my original post had names similar to stdint, such as float32_t)

I thought including the bit size in the name made it a bit harder to
read and more unattractive, quite similar to the case with integers ?
(i.e. naming those types as int8, int16, int32, int64, int128 instead)


But I haven't heard anything suggesting that "real" will ever change...
As far as I know, that part of the D specification is already decided.

--anders
Apr 09 2006
next sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Anders F Bj=F6rklund wrote:

 Exactly my opinion: The basic types should have well-defined bit-sizes=





 and be portable across architectures.


=20
 It could just be a side-effect of DMD only targetting one architecture =


?

That certainly is the core of the issue. The D specification contains a
bit of theoretical talk about portability, but effectively the language
is an x86-only language only.


 The real type is 80 bits in register on all the supported platforms, it=



 just varies in size when stored to mem/disk (80 on Windows, 96 on Linux=


,

 and will probably increase to 128 bit when 64-bit Linux is supported ?)=



 Usually it just follows the platform definition of "long double", for C=


=2E

This confusion is exactly what I have problems with.


 I had a similar suggestion, but the other way around... Keep the
 current type names, and added the bitsizenames as aliases instead.
 (my original post had names similar to stdint, such as float32_t)


That means trying to build something well-defined on top of shaky ground
which is exactly what causes the huge mess of C/C++-build systems like
"automake" and "autoconf". The build system has to do a number of tests
to find out what the implementation-dependend things are on a given
system to define portable types. This is just the thing I believed D was
supposed to solve.


 I thought including the bit size in the name made it a bit harder to
 read and more unattractive, quite similar to the case with integers ?
 (i.e. naming those types as int8, int16, int32, int64, int128 instead)


Harder to read? That's exactly what aliases should be used for. The
names including bit sizes are precise, well defined and to the point,
which is the best ground to build something on top


 But I haven't heard anything suggesting that "real" will ever change...=



 As far as I know, that part of the D specification is already decided.


Yes, it is decided and Walter considers the topic closed. The whole
discussion that is going on here is completely academic as is the whole
question of portability. But one day, somebody might actually try to
port D to a seriously different architecture, and latest at that point,
this issue will have to be rolled up again.
Apr 09 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
Norbert Nemec wrote:

 Anders F Björklund wrote:

 Exactly my opinion: The basic types should have well-defined bit-sizes
 and be portable across architectures.


 It could just be a side-effect of DMD only targetting one architecture ?


 
 That certainly is the core of the issue. The D specification contains a
 bit of theoretical talk about portability, but effectively the language
 is an x86-only language only.
 


Hrm, that's a little strong: http://home.earthlink.net/~dvdfrdmn/d/

GDC's been running on AIX and non-intel Mac for a while now. IIRC, 
elsewhere there has been a working port for HPUX as well.

The bottom line is that 'i/c/real' are the only native types where the 
size is not specified by the language, but by the underlying hardware. 
This is a big improvement for portability over C/++. According to the 
rationale, the 'real' type is to encourage programmers to use the max. 
hardware precision available for fp operations and port things that way.

Let's not over-guru things here:
- float and double are widely understood as 32 bit and 64 bit for a 
C-lineage language.
- There seems to be little complaint about i/c/float and i/c/double as well.
- The big complaint is from numerics programmers who don't like the 
irony of ireal and creal. *Just change those to be 'imag' and 'comp'*.
- Walter understandably doesn't want to change the spec. for every 
floating point type, but this would be a change involving just two of 
them that we hear constant complaints about and are not yet used 
ubiquitously.
- If it breaks your code, you can simply alias the old creal and ireal 
types until you get time to change it.

So you have:

float
ifloat
cfloat

double
idouble
cdouble

real
imag
comp

If Walter would handle the compiler end of things, I would be glad to 
grep the phobos math libs. and docs. to make the changes there.

Besides getting rid of ireal and creal, imag and comp are short yet 
descriptive to those who would most likely use them. They will not 
confuse newbies or make the type system any harder to understand. And 
they imply a type that is 'native' to the machine like 'real' does 
because they don't have any connotations of absolute size.

Let's face it, there is no way Walter is going to again change the base 
fp types (float, double, real). And speaking from the point of view of a 
humble user who may want to use yet-to-be-built math libraries sometime, 
I would immediately search for an alternative for a D math library built 
with aliased types because that would just be one more inconsistency, 
another thing to learn and remember, and more to concern myself with for 
porting.

- Dave
Apr 09 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Dave wrote:


 That certainly is the core of the issue. The D specification contains a
 bit of theoretical talk about portability, but effectively the language
 is an x86-only language only.


 
 Hrm, that's a little strong: http://home.earthlink.net/~dvdfrdmn/d/
 GDC's been running on AIX and non-intel Mac for a while now. IIRC, 
 elsewhere there has been a working port for HPUX as well.


On PowerPC, the "real" type is the same as the "double" type.

The new 128-bit long double type in GCC 4.0 and Mac OS X 10.4
can't be used for D language since it is not fully compliant.
(being made out of two linked double registers, it doesn't do
all of the exceptions in the same way. Same format, though...)

SPARC should have a real 128-bit long double type, I think.
Not sure if it's in hardware or if it is emulated, though ?


The silly thing about the 80-bit/long double on X86, besides
that not every compiler supports it, is the size/alignment:

                         size    align
DM Windows (32-bit)     10      2
Mac OS X86 (32-bit)     16      16
GCC Linux (32-bit)      12      4
GCC Linux (64-bit)      16      16

Not that the larger storage formats buys you extra precision,
it's just padded with zeros... (for better alignment I think)

--anders
Apr 10 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Norbert Nemec wrote:


 I had a similar suggestion, but the other way around... Keep the
 current type names, and added the bitsizenames as aliases instead.
 (my original post had names similar to stdint, such as float32_t)


 
 That means trying to build something well-defined on top of shaky ground
 which is exactly what causes the huge mess of C/C++-build systems like
 "automake" and "autoconf". The build system has to do a number of tests
 to find out what the implementation-dependend things are on a given
 system to define portable types. This is just the thing I believed D was
 supposed to solve.


AFAIK, the only D things undecided are the size of a real and the param
format of a dynamic array. At least those are the ones I've run into...

Size of the other types should be pretty constant ? Even size of a bool.
Already had stdint aliases for integers, so I thought about "stdfloat".

I dropped the idea, since it's not as common to need to set the size of
a float/double in bits, as compared to when using short/long int types.


The D number types are also the same as in Java, which is another plus.
(D adds the unsigned and imaginary/complex variants, which is a bonus)

I renamed real into "extended" here, and just treat "real" as an alias.
But usually I just use float and double, to keep the code portable...



 I thought including the bit size in the name made it a bit harder to
 read and more unattractive, quite similar to the case with integers ?
 (i.e. naming those types as int8, int16, int32, int64, int128 instead)


 
 Harder to read? That's exactly what aliases should be used for. The
 names including bit sizes are precise, well defined and to the point,
 which is the best ground to build something on top


I've been doing some coding with Mac's C types, which include the bit
size, and it's not *that* bad in practice actually. Just a bit strange:

     typedef unsigned char           UInt8;
     typedef signed char             SInt8;
     typedef unsigned short          UInt16;
     typedef signed short            SInt16;
     typedef unsigned long           UInt32;
     typedef signed long             SInt32;
     typedef uint64_t		    UInt64;
     typedef int64_t		    SInt64;
     typedef float                   Float32;
     typedef double                  Float64;

But when writing regular ANSI C code, using things like "int" or "float"
just feels more readable (to me) than using e.g. "SInt32" or "Float32" ?


So I don't think there are too many problems with all the old "regular"
types, it's just the "real" type that I'm having some minor issues with.

And like suggested, it's easy enough to add a few "alias" and live with.
(I'm going to continue to call the X87 80-bit type "extended", I think)

--anders
Apr 09 2006
parent Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:

 Norbert Nemec wrote:
 

 I had a similar suggestion, but the other way around... Keep the
 current type names, and added the bitsizenames as aliases instead.
 (my original post had names similar to stdint, such as float32_t)



 That means trying to build something well-defined on top of shaky ground
 which is exactly what causes the huge mess of C/C++-build systems like
 "automake" and "autoconf". The build system has to do a number of tests
 to find out what the implementation-dependend things are on a given
 system to define portable types. This is just the thing I believed D was
 supposed to solve.


 
 
 AFAIK, the only D things undecided are the size of a real and the param
 format of a dynamic array. At least those are the ones I've run into...
 
 Size of the other types should be pretty constant ? Even size of a bool.
 Already had stdint aliases for integers, so I thought about "stdfloat".
 
 I dropped the idea, since it's not as common to need to set the size of
 a float/double in bits, as compared to when using short/long int types.
 
 
 The D number types are also the same as in Java, which is another plus.
 (D adds the unsigned and imaginary/complex variants, which is a bonus)
 
 I renamed real into "extended" here, and just treat "real" as an alias.
 But usually I just use float and double, to keep the code portable...
 
 

 I thought including the bit size in the name made it a bit harder to
 read and more unattractive, quite similar to the case with integers ?
 (i.e. naming those types as int8, int16, int32, int64, int128 instead)



 Harder to read? That's exactly what aliases should be used for. The
 names including bit sizes are precise, well defined and to the point,
 which is the best ground to build something on top


 
 
 I've been doing some coding with Mac's C types, which include the bit
 size, and it's not *that* bad in practice actually. Just a bit strange:
 
     typedef unsigned char           UInt8;
     typedef signed char             SInt8;
     typedef unsigned short          UInt16;
     typedef signed short            SInt16;
     typedef unsigned long           UInt32;
     typedef signed long             SInt32;
     typedef uint64_t            UInt64;
     typedef int64_t            SInt64;
     typedef float                   Float32;
     typedef double                  Float64;
 
 But when writing regular ANSI C code, using things like "int" or "float"
 just feels more readable (to me) than using e.g. "SInt32" or "Float32" ?
 
 
 So I don't think there are too many problems with all the old "regular"
 types, it's just the "real" type that I'm having some minor issues with.
 
 And like suggested, it's easy enough to add a few "alias" and live with.
 (I'm going to continue to call the X87 80-bit type "extended", I think)
 
 --anders


Let's put it this way: until _all_ of the here discussed parameters have 
become chiseled in stone, and matured till petrification, any serious 
math user, or library writer, would do well in aliasing (whatever type 
they that day choose) and using that alias in the entire code.

Only doing that can save them if "the world" changes around them.
(Which really is likely -- until the above said "chiseled in stone and 
matured till petrification" has materialized.)
Apr 09 2006
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:

 I had a similar suggestion, but the other way around... Keep the
 current type names, and added the bitsizenames as aliases instead.


Ehh, if I understand this correctly, this would be the opposite from:

Define "bitsizenames" as the ultimate "Genuine Types", and only alias 
them to the "usually used" types.


This "opposite" is what I have a problem with. I start seeing ghosts in 
the bedroom as soon as somebody tries to define "reality" with a set of 
incongruent "colloquial" names, and only then -- and as defined by them, 
define the "reality" types.

I hope I've seriously misunderstood the above post.
Apr 09 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:


 Ehh, if I understand this correctly, this would be the opposite from:
 
 Define "bitsizenames" as the ultimate "Genuine Types", and only alias 
 them to the "usually used" types.


Yes, this would be the opposite from changing the base type names...

But all those D types (again: except for real) have a fixed size, so
it's nothing like what you encounter in the old C headers/libraries ?

The only question is which of them is genuine and which is the alias.


 This "opposite" is what I have a problem with. I start seeing ghosts in 
 the bedroom as soon as somebody tries to define "reality" with a set of 
 incongruent "colloquial" names, and only then -- and as defined by them, 
 define the "reality" types.
 
 I hope I've seriously misunderstood the above post.


Depends on what you read into it. It's only a pragmatic approach, based
on the assumption that the names in the current type list won't change.

Thus, adding types with embedded bit sizes would *have* to be aliases ?
Here was the entire list, with the floating points changed and added to:

INTEGER
byte (8)
short (16)
int (32)
long (64)
cent (128)

FLOATING-POINT
half (16)
float (32)
double (64)
extended (80)
quad (128)

I don't think the current D names are that bad. Similar to C and Java...
And I don't think that they (D) are going to change, either ? Do you ?

And whether you use "int" or "int32_t", and perhaps "double" or e.g.
"Float64", is more a matter of style and taste than of the D language ?

--anders
Apr 09 2006
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Björklund wrote:

 Georg Wrede wrote:
 

 Ehh, if I understand this correctly, this would be the opposite from:

 Define "bitsizenames" as the ultimate "Genuine Types", and only alias 
 them to the "usually used" types.


 
 Yes, this would be the opposite from changing the base type names...
 
 But all those D types (again: except for real) have a fixed size, so
 it's nothing like what you encounter in the old C headers/libraries ?
 
 The only question is which of them is genuine and which is the alias.
 

 This "opposite" is what I have a problem with. I start seeing ghosts 
 in the bedroom as soon as somebody tries to define "reality" with a 
 set of incongruent "colloquial" names, and only then -- and as defined 
 by them, define the "reality" types.

 I hope I've seriously misunderstood the above post.


 
 Depends on what you read into it. It's only a pragmatic approach, based
 on the assumption that the names in the current type list won't change.
 
 Thus, adding types with embedded bit sizes would *have* to be aliases ?
 Here was the entire list, with the floating points changed and added to:
 
 INTEGER
 byte (8)
 short (16)
 int (32)
 long (64)
 cent (128)
 
 FLOATING-POINT
 half (16)
 float (32)
 double (64)
 extended (80)
 quad (128)
 
 I don't think the current D names are that bad. Similar to C and Java...
 And I don't think that they (D) are going to change, either ? Do you ?
 
 And whether you use "int" or "int32_t", and perhaps "double" or e.g.
 "Float64", is more a matter of style and taste than of the D language ?


"911? Er, yes, can I get Ghost Busters! And don't hang up on me, please!!"
Apr 10 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:


 I don't think the current D names are that bad. Similar to C and Java...
 And I don't think that they (D) are going to change, either ? Do you ?

 And whether you use "int" or "int32_t", and perhaps "double" or e.g.
 "Float64", is more a matter of style and taste than of the D language ?


 
 "911? Er, yes, can I get Ghost Busters! And don't hang up on me, please!!"


I'm still not sure what the nature of your particular ghouls was here ?

Did you want the basic D types to be renamed to something including
the general type and the bit size instead ? (int32, float64, etc.)

Because I just don't see that name change coming to the D language...
Of course, Walter is the one that would know. Us others hack aliases.

--anders
Apr 10 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Norbert Nemec wrote:

 Don Clugston wrote:

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


 
 Well, the whole discussion is pretty much pointless unless Walter is
 willing to touch the topic again. When the topic came up two years ago,
 the final sentence was something like: "Well, I agree that creal sounds
 stupid, but we are not going to roll this up yet again." Obviously, the
 name "creal" was the result of a tedious discussion a little while
 before. That discussion was before my time and obviously nobody back
 then had strong feelings against talking about "really complex numbers".
 Therefore the final word still is: "Do in the library whatever you want,
 the language definition will not be changed again."


I'm OK with that, I really think it's all we need.
* Add the following lines to object.d:

alias ireal imaginary;
alias creal complex;

* Replace all uses of 'creal' in math.d with 'complex'.
* In the documentation, replace 'creal' in the docs with 'complex'.
A simple search-and-replace in both cases. It would only take five 
minutes. No change to the compiler is required. It wouldn't break any 
existing code.

Similar to, but much less disruptive than, the bit/bool change that was 
just made.

I completely agree with Walter that 'extended' was a dreadful name for 
80 bit floats. I really like 'real'. But since it's not a fixed size, 
it's behaving exactly like an alias. It would be natural to have 
corresponding aliases for 'imaginary' and 'complex'.
Apr 09 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Don Clugston wrote:


 I completely agree with Walter that 'extended' was a dreadful name for 
 80 bit floats. I really like 'real'. But since it's not a fixed size, 
 it's behaving exactly like an alias. It would be natural to have 
 corresponding aliases for 'imaginary' and 'complex'.


"extended" is the name of the FP format, though ? But maybe it needed a 
spiffier name, like "ext" (just like "quadruple" is shortened to "quad")

And "extended" isn't that much worse than "long double", is it... ? :-)

--anders
Apr 10 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Anders F Björklund wrote:

 Don Clugston wrote:
 

 I completely agree with Walter that 'extended' was a dreadful name for 
 80 bit floats. I really like 'real'. But since it's not a fixed size, 
 it's behaving exactly like an alias. It would be natural to have 
 corresponding aliases for 'imaginary' and 'complex'.


 
 "extended" is the name of the FP format, though ? But maybe it needed a 
 spiffier name, like "ext" (just like "quadruple" is shortened to "quad")
 
 And "extended" isn't that much worse than "long double", is it... ? :-)


IMHO, it is much worse. It has absolutely no indication that it's a 
floating-point number. The full name is "extended precision float".
"double" has a very long history in C-related languages. Extended doesn't.

I think it doesn't matter much what it is called. It should almost never 
appear in code. (Code that uses it is CPU-specific, so some low-level 
library code like isfinite() will use it, but not much else). User code 
should almost always use "real".

(Arguably, they could even be called float80_80 for Windows, float80_96 
for Linux32, float80_128 for Linux64, because of the differences in 
padding. The Linux64 format is binary compatible with the IEEE quadruple 
format; it behaves identically to a quad where the precision has been 
set low).
Apr 10 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Don Clugston wrote:


 I think it doesn't matter much what it is called. It should almost never 
 appear in code. (Code that uses it is CPU-specific, so some low-level 
 library code like isfinite() will use it, but not much else). User code 
 should almost always use "real".


Sounds good to me. Bringing back imaginary and complex would be enough,
then user code could use "real" and "complex" and not worry about it...
Like you mentioned, that's simple to do by using alias in the interim.

Any "extended" and "quadruple" would only be in lowlevel future layers.
("real" would automatically alias to type double, extended or quadruple)
If they're not used much, maybe they don't even need any "short forms".


 (Arguably, they could even be called float80_80 for Windows, float80_96 
 for Linux32, float80_128 for Linux64, because of the differences in 
 padding. 


Then again, on any single platform you would only encounter one of them?
For instance "register" variables holding them would be the same on all.

Cross-platform data would be more work, but could use different padding.
(i.e. storing/reading 10 bytes, and adjust the padding according to ABI)


 The Linux64 format is binary compatible with the IEEE quadruple 
 format; it behaves identically to a quad where the precision has been 
 set low).


Interesting, hadn't thought of that... But it's very good news I think.
(Mac uses the same 128-bit format, in the Intel ABI for Mac OS X 10.4)

It's cool because you can then use the quad format for data exchange,
even if neither PowerPC/Intel will use it internally. (just 64+64/80)

--anders
Apr 10 2006