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

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

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

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

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

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

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

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

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

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