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=


 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.

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



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

 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=

 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.

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=

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.


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