> Kinda sad that this war has been going on for almost two years ? (I'm not sure if that is longer than the Boolean War, but still)

It's not!

Maybe everyone knows this but I thought I'd jump in.

>> Both float and double are equally "real numbers" too.

Which is to say, not real numbers at all.  (-:

> Yes, but float and double are computer science terms.  The mistake was treating "real" as having the same heritage as those two types.  The progression becomes inappropriate, especially with the mathematical definiton of "real" being so clear.  It looks like "real" was used to describe a hardware register size... Perhaps this was a clumsy moniker that Intel choose?  I don't know for sure.

I'm not sure if "real" is used in D right now, but "float" is appropriately non-committal.  Since there are an infinite number of real values between any two real numbers, you can never truly express them in a computer.  The astute reader is now thinking that there are an infinite number of integers as well, but we have "int".  As it turns out we should probably have avoided "int" and stuck with the computer science terms "float" and "fixed" for real and integer.

In both cases you are simply trying to use an allotted number of bits to express a slice of an infinite number.  For integers you can used a "fixed" notation - base 2 - that is in the range [-(2^n)/2 - 1, (2^n)/2].  This turns out very useful, although it can't really handle any integer, and the user has to pick bigger "fixed" notations (8-bit, 32-bit) if he needs them.

For reals you can use a mixed notation that holds the exponent and an integer, such as 4.301 x 10^23.  You store 4301 like a fixed number in some of the bits, then the exponent also.  Special math co-processors can handle this mixed style quickly.  Notice that you can only have so much precision (4301) but you give up bits for the exponent so you can "float" it up and down the number scale (10^-5 means .0004301).  Also note that the larger (positive or negative) the number, the less accuracy there is between each two consecutive numbers you can represent.  Again, not a real number, but a good representation for many uses and again you can use more bits if a program needs it.

Phew.  Just remembering a day when specific things meant specific things.

Here is the revised list of type aliases and names:

    TYPE        ALIAS    // RANGE
Floating Point: (std.stdfloat)
     float               // 32-bit single precision (about 6 digits)
    double               // 64-bit double precision (about 15 digits)
  extended     real      // 64/80/128-bit extended precision (platform)

    ifloat               // \
   idouble               // imaginary versions of the above
 iextended   imaginary   // /

    cfloat               // \
   cdouble               // complex (both real and imaginary parts)
 cextended    complex    // /


This way, Walter can avoid the "extended" name that
he doesn't like, while D can avoid looking silly...

Thank heavens the DMD code only talks about:
	TOKfloat32
	TOKfloat64
	TOKfloat80

And avoids the religously colored words, mostly.
Note that extended==double, on PowerPC and Sparc.

--anders

Implementation:

> module std.stdfloat;
> 
> /* floating point types */
> 
> alias   extended        real;
> alias  iextended   imaginary;
> alias  cextended     complex;

Charlie Patterson wrote:

>>>Both float and double are equally "real numbers" too.
> 
> Which is to say, not real numbers at all.  (-:

How does "sample approximations of" feel for you ? :-)

Otherwise you'd soon be saying that the image I'm seeing
is not real and the sound I'm hearing is not real either.
(since they're just samples of the continuous reality...)

http://en.wikipedia.org/wiki/Image:MagrittePipe.jpg

--anders

PS. As a side note, Mac OS X is using float for sounds now
    and will be using float RGB values for images in 10.4.
    It's really good when working with lots of filters,
    since the loss is *much* smaller than with integers...
    http://www.apple.com/macosx/features/audio/
    http://www.apple.com/macosx/tiger/coreimage.html
    (at this rate, Apple is *got* to start paying me soon!)

Anders F Björklund wrote:

> Thank heavens the DMD code only talks about:
> TOKfloat32
> TOKfloat64
> TOKfloat80

Actually, I would prefer that kind of naming for all the types. If the specs define the various integer and floating point types by the bit-length, it would be the clearest if the original names for the types did reflect this (int8, int16, int32, uint8, uint16, uint32, float32, float64, ...)

The only uglyness of that comes in with complex, where it is not completely obvious whether complex64 means on complex made up of two float64 or one complex that has a total of 64 bits.

All the other names like int, long, float, double and so on could then be defined as aliases depending on the taste of the library author. The language specs would be simpler and more definite. (It might be up to the implementation whether certain types exist, but not what they mean.) And there would be less confusion with C/C++, where the definitions of the types are usually similar but not platform independent.

Anyhow, at this point I really did not want to touch this old subject in its entirety, but restrict myself to the killer absurdities: 'creal' and 'ireal'

Norbert Nemec wrote:

> Actually, I would prefer that kind of naming for all the types. If the specs
> define the various integer and floating point types by the bit-length, it
> would be the clearest if the original names for the types did reflect this
> (int8, int16, int32, uint8, uint16, uint32, float32, float64, ...)

There are *already* perfectly usable int alternatives, in std.stdint ?

std.stdfloat could add:
float32_t, float64_t, float80_t (where "80" is not always the bit size)

real32_t, real64_t, real80_t  (same as "float")
imag32_t, imag32_t, imag80_t  (for "imaginary")
comp32_t, comp64_t, comp80_t  (for "complex")

As you saw in the table I posted, I suggested doing the same for UTF...

> The only uglyness of that comes in with complex, where it is not completely
> obvious whether complex64 means on complex made up of two float64 or one
> complex that has a total of 64 bits.

I think this is pretty straightforward, that is uses two of the original types. Complex is not even a single literal, but made up from one real and one imaginary that is then added together at runtime. (1.0 + 1.0i)

> All the other names like int, long, float, double and so on could then be
> defined as aliases depending on the taste of the library author. The
> language specs would be simpler and more definite. (It might be up to the
> implementation whether certain types exist, but not what they mean.) And
> there would be less confusion with C/C++, where the definitions of the
> types are usually similar but not platform independent.

I think the opposite is path of least resistance, would work the same?

And since everyone else on the planet is using "extended" (well, except
C that uses "long double" but anyway)- why couldn't D just use the same?

For ultimate coherence, could even offer "single" as a name for float ?

> Anyhow, at this point I really did not want to touch this old subject in its
> entirety, but restrict myself to the killer absurdities: 'creal' and
> 'ireal'

Yes, those two have *got* to die... "cereal" and "irreal" ?

I can't imagine how Walter kept a straight face while posting:

> So, I'm thinking of renaming and adding a few types:
> 
> extended = no longer a keyword
> real = 80 bit floating point
> creal = complex real
> ireal = imaginary real 

As in:
"a complex real is made from a real real and an imaginary real" ?

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:cugpih$6j1$1@digitaldaemon.com...
> Charlie Patterson wrote:
>
>>>>Both float and double are equally "real numbers" too.
>>
>> Which is to say, not real numbers at all.  (-:
>
> How does "sample approximations of" feel for you ? :-)
>
> Otherwise you'd soon be saying that the image I'm seeing
> is not real and the sound I'm hearing is not real either.
> (since they're just samples of the continuous reality...)

Heh.  I'm not aware of image or sound being scientifically specific terms like real and integer are.

Kris wrote:
> In article <cugjt3$8f$1@digitaldaemon.com>, Norbert Nemec says...
> 
>>To make it short, the names 'creal' and 'ireal' will simply lead anyone with
>>some background in mathematics laugh out loud and lead him to refuse taking
>>D serious.
> 
> 
> I vote they should be called 'unreal' and 'surreal' instead 
> 
> :~)
> 
> 
I believe that mathematicians already have a (different) meaning for surreal numbers.