www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - half and quad

reply Olifant <olifant gmail.com> writes:
Unlike C++, D seems to be pretty consistent with basic numeric types, such as
clearly defining the exact bitsize of integers ranging from 8 to 128 bits, and
floating point numbers ranging from 32 and 64 bit.

However, what appears to be missing are half precision and quad precision
floating point numbers. I know they're not really standard yet, but they will
be soon (http://en.wikipedia.org/wiki/IEEE_754r). The range of exact bitsizes
for floating point numbers in D could be extended from 16 to 128 bit.

The keyword "cent" is reserved for 128-bit integers. Could "half" and "quad" be
reserved for respectively 16-bit and 128-bit floating point numbers?

If the 128-bit floating point numbers are standard, then it will be nice to
have "quad" to cover those, instead of using the type "real" that doesn't
really specify the size.

And "half" could be very useful in some algorithms such as those on GPU-like
processors.

It would be quite dirty if D would after so many years when those things are
standard, have to come up with some bad names for those types similar to how
"wchar_t" in C++ is a bad name.
Oct 11 2007
next sibling parent Paul Anderson <paul.d.anderson.removethis comcast.andthis.net> writes:
Olifant Wrote:


 Unlike C++, D seems to be pretty consistent with basic numeric types, such as
clearly defining the exact bitsize of integers ranging from 8 to 128 bits, and
floating point numbers ranging from 32 and 64 bit.
 
 However, what appears to be missing are half precision and quad precision
floating point numbers. I know they're not really standard yet, but they will
be soon (http://en.wikipedia.org/wiki/IEEE_754r). The range of exact bitsizes
for floating point numbers in D could be extended from 16 to 128 bit.
 
 The keyword "cent" is reserved for 128-bit integers. Could "half" and "quad"
be reserved for respectively 16-bit and 128-bit floating point numbers?
 
 If the 128-bit floating point numbers are standard, then it will be nice to
have "quad" to cover those, instead of using the type "real" that doesn't
really specify the size.
 
 And "half" could be very useful in some algorithms such as those on GPU-like
processors.
 
 It would be quite dirty if D would after so many years when those things are
standard, have to come up with some bad names for those types similar to how
"wchar_t" in C++ is a bad name.


And this would imply reserving chalf, cquad, ihalf & iquad as well.

As usual, the problem is breaking existing code. I've never (IIRC) used "quad"
as a variable name, but I've used "half" on numerous occasions.

But I think this is a good idea.

Paul
Oct 11 2007
prev sibling next sibling parent Paul Anderson <paul.d.anderson.removethis comcast.andthis.net> writes:
Olifant Wrote:


 Unlike C++, D seems to be pretty consistent with basic numeric types, such as
clearly defining the exact bitsize of integers ranging from 8 to 128 bits, and
floating point numbers ranging from 32 and 64 bit.
 
 However, what appears to be missing are half precision and quad precision
floating point numbers. I know they're not really standard yet, but they will
be soon (http://en.wikipedia.org/wiki/IEEE_754r). The range of exact bitsizes
for floating point numbers in D could be extended from 16 to 128 bit.
 
 The keyword "cent" is reserved for 128-bit integers. Could "half" and "quad"
be reserved for respectively 16-bit and 128-bit floating point numbers?
 
 If the 128-bit floating point numbers are standard, then it will be nice to
have "quad" to cover those, instead of using the type "real" that doesn't
really specify the size.
 
 And "half" could be very useful in some algorithms such as those on GPU-like
processors.
 
 It would be quite dirty if D would after so many years when those things are
standard, have to come up with some bad names for those types similar to how
"wchar_t" in C++ is a bad name.


And this would imply reserving chalf, cquad, ihalf & iquad as well.

As usual, the problem is breaking existing code. I've never (IIRC) used "quad"
as a variable name, but I've used "half" on numerous occasions.

But I think this is a good idea.

Paul
Oct 11 2007
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Olifant wrote:


 The keyword "cent" is reserved for 128-bit integers. Could "half" and "quad"
be reserved for respectively 16-bit and 128-bit floating point numbers?


I don't think there is any hope for quad or cent, until they're
implemented on standard processors... (i.e ones that run Windows)

But I do have a port of "half" (from OpenEXR) kicking around here
somewhere, it's basically using ushort and converts over to float.

See http://www.digitalmars.com/d/archives/digitalmars/D/31899.html

--anders
Oct 11 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Anders F Björklund wrote:

 Olifant wrote:
 

 The keyword "cent" is reserved for 128-bit integers. Could "half" and 
 "quad" be reserved for respectively 16-bit and 128-bit floating point 
 numbers?


 
 I don't think there is any hope for quad or cent, until they're
 implemented on standard processors... (i.e ones that run Windows)
 
 But I do have a port of "half" (from OpenEXR) kicking around here
 somewhere, it's basically using ushort and converts over to float.
 
 See http://www.digitalmars.com/d/archives/digitalmars/D/31899.html


I wonder if 'half' is really worth it though.  It seems like more of a 
temporary stop-gap measure to deal with memory and throughput problems 
on a GPU.  In 5 years maybe people will look at 'half' and laugh about 
how primitive the architectures were back in the 00's.  Also since D 
isn't going to run on a GPU any time soon, and CPUs aren't going to 
implement 'half' any time soon (AFAIK), maybe this doesn't make too much 
sense.

'quad' on the other hand, seems at least as likely to have a future as 
'cent' does, so seems reasonable to reserve it to me.

--bb
Oct 11 2007
next sibling parent Nathan Reed <nathaniel.reed gmail.com> writes:
Bill Baxter wrote:

 Anders F Björklund wrote:

 Olifant wrote:


 The keyword "cent" is reserved for 128-bit integers. Could "half" and 
 "quad" be reserved for respectively 16-bit and 128-bit floating point 
 numbers?


 I don't think there is any hope for quad or cent, until they're
 implemented on standard processors... (i.e ones that run Windows)

 But I do have a port of "half" (from OpenEXR) kicking around here
 somewhere, it's basically using ushort and converts over to float.

 See http://www.digitalmars.com/d/archives/digitalmars/D/31899.html


 
 I wonder if 'half' is really worth it though.  It seems like more of a 
 temporary stop-gap measure to deal with memory and throughput problems 
 on a GPU.  In 5 years maybe people will look at 'half' and laugh about 
 how primitive the architectures were back in the 00's.  Also since D 
 isn't going to run on a GPU any time soon, and CPUs aren't going to 
 implement 'half' any time soon (AFAIK), maybe this doesn't make too much 
 sense.
 
 'quad' on the other hand, seems at least as likely to have a future as 
 'cent' does, so seems reasonable to reserve it to me.
 
 --bb


More useful than these, I suspect, would be some language support for 
vectorized types, e.g. a 128 bit value consisting of four 32-bit floats, 
which you can then use to write SIMD code.

Of course, this can be done in the current language using structs, and 
operator overloading with some asm blocks to actually call the 
vectorized instructions for your specific architecture (or fall back to 
serial computation on architectures without SIMD support).  But it would 
be much nicer if the compiler's back-end could do that for us, 
especially since it could then do proper register allocation and so forth.

Thanks,
Nathan Reed
Oct 11 2007
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bill Baxter wrote:


 But I do have a port of "half" (from OpenEXR) kicking around here
 somewhere, it's basically using ushort and converts over to float.

 See http://www.digitalmars.com/d/archives/digitalmars/D/31899.html


 
 I wonder if 'half' is really worth it though.  It seems like more of a 
 temporary stop-gap measure to deal with memory and throughput problems 
 on a GPU.  In 5 years maybe people will look at 'half' and laugh about 
 how primitive the architectures were back in the 00's.  Also since D 
 isn't going to run on a GPU any time soon, and CPUs aren't going to 
 implement 'half' any time soon (AFAIK), maybe this doesn't make too much 
 sense.


D doesn't have to be run *on* the GPU in order to need the same type...
(it's useful for manipulating data that is later going to be sent over)

But you are right that half is just a lower resolution version of float,
just like 16-bit color and 16-bit integers. And while you could just
use 32-bit always (or 64-bit, just for the overkill), sometimes you do
have to worry about performance or memory or bandwidth constraints ?

--anders
Oct 11 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Anders F Björklund wrote:

 Bill Baxter wrote:
 

 But I do have a port of "half" (from OpenEXR) kicking around here
 somewhere, it's basically using ushort and converts over to float.

 See http://www.digitalmars.com/d/archives/digitalmars/D/31899.html


 I wonder if 'half' is really worth it though.  It seems like more of a 
 temporary stop-gap measure to deal with memory and throughput problems 
 on a GPU.  In 5 years maybe people will look at 'half' and laugh about 
 how primitive the architectures were back in the 00's.  Also since D 
 isn't going to run on a GPU any time soon, and CPUs aren't going to 
 implement 'half' any time soon (AFAIK), maybe this doesn't make too 
 much sense.


 
 D doesn't have to be run *on* the GPU in order to need the same type...
 (it's useful for manipulating data that is later going to be sent over)
 
 But you are right that half is just a lower resolution version of float,
 just like 16-bit color and 16-bit integers. And while you could just
 use 32-bit always (or 64-bit, just for the overkill), sometimes you do
 have to worry about performance or memory or bandwidth constraints ?


I don't have anything against putting a half type in.
I guess I'd rather see it as something like an intrinsic module than a 
reserved keyword, though.  Something implemented by the compiler, but 
you have to do an import to get at it.

Realistically, not that large a percentage of the whole user base is 
going to have a need for it, so this keeps it out of the hair of e.g. 
web developers and DB programmers.

--bb
Oct 12 2007
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bill Baxter wrote:


 I don't have anything against putting a half type in.
 I guess I'd rather see it as something like an intrinsic module than a 
 reserved keyword, though.  Something implemented by the compiler, but 
 you have to do an import to get at it.


That's how it works now, with "half" being a typedef for ushort...
All math is done in the "float" type, half is just for the storage.

It can be used from C even, using the appropriate function calls.
But it's easier to use in C++, with the overloaded operators etc ?

//	    half a (3.5);
//	    float b (a + sqrt (a));
//	    a += b;
//	    b += a;
//	    b = a + 7;

--anders
Oct 12 2007
prev sibling parent Don Clugston <dac nospam.com.au> writes:
Bill Baxter wrote:

 Anders F Björklund wrote:

 Olifant wrote:


 The keyword "cent" is reserved for 128-bit integers. Could "half" and 
 "quad" be reserved for respectively 16-bit and 128-bit floating point 
 numbers?


 I don't think there is any hope for quad or cent, until they're
 implemented on standard processors... (i.e ones that run Windows)

 But I do have a port of "half" (from OpenEXR) kicking around here
 somewhere, it's basically using ushort and converts over to float.

 See http://www.digitalmars.com/d/archives/digitalmars/D/31899.html


 
 I wonder if 'half' is really worth it though.  It seems like more of a 
 temporary stop-gap measure to deal with memory and throughput problems 
 on a GPU.  In 5 years maybe people will look at 'half' and laugh about 
 how primitive the architectures were back in the 00's.  Also since D 
 isn't going to run on a GPU any time soon, and CPUs aren't going to 
 implement 'half' any time soon (AFAIK)


Actually 'half' is in AMD's recently announced SSE5. Admittedly the only 
instructions it seems to support are conversions from 'half' to 'float'.
I agree that it probably won't have much future, though.


 'quad' on the other hand, seems at least as likely to have a future as 
 'cent' does, so seems reasonable to reserve it to me.
 
 --bb
Oct 12 2007
prev sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 10/11/07, Olifant <olifant gmail.com> wrote:

 The keyword "cent" is reserved for 128-bit integers. Could "half" and "quad"
be reserved for respectively 16-bit and 128-bit floating point numbers?


I've always thought the names we have for built-in types are (mostly)
horrible. Consider "short", "int" and "long". Seems fine on a 32 bit
processor, but in the far, far future, when even longs are considered
tiny, those words would all be wrong. "cent". - why cent? Cent means
100. So if you use "cent" for a 128 bit integer, what do you use for a
256 bit integer? And what does the "d" stand for in "dchar"? And as
for "quad" and "half" - it's not intuitively obvious that these are
floating point.

I'd vote for more obvious names any day:
int8, int16, int32, int64, int128...
uint8, uint16, uint32, uint64, uint128...
real16, real32, real64, real80, real128...

with "int", "uint" and "real" being aliases for whatever type is
"machine native".
Oct 12 2007
next sibling parent 0ffh <spam frankhirsch.net> writes:
Janice Caron wrote:

 And as for "quad" and "half" - it's not intuitively obvious that these
 are floating point.


Single and double are floats after all. Quad and half fit in nicely.
And the days "when even longs are considered tiny" will probably
never come. Increasing machine word size only makes sense as long
as lots of code needs bigger numbers, which have to be emulated
with multi-instruction mathematical operations.
So quite obviously, 8 and 16 bit were too small. 32 bit word size
is mostly good enough, especially as hardware support for floats
with their own word sizes has become near-ubiquitous. More than 64
bit word size does not pay any more. And I'll probably have my own
quantum computer at home, before I ever own a 256 bit box!

Regards, Frank
Oct 12 2007
prev sibling next sibling parent Paul Anderson <paul.d.anderson.removethis comcast.andthis.net> writes:
Janice Caron Wrote:


 On 10/11/07, Olifant <olifant gmail.com> wrote:

 The keyword "cent" is reserved for 128-bit integers. Could "half" and "quad"
be reserved for respectively 16-bit and 128-bit floating point numbers?


 
 I've always thought the names we have for built-in types are (mostly)
 horrible. Consider "short", "int" and "long". Seems fine on a 32 bit
 processor, but in the far, far future, when even longs are considered
 tiny, those words would all be wrong. "cent". - why cent? Cent means
 100. So if you use "cent" for a 128 bit integer, what do you use for a
 256 bit integer? And what does the "d" stand for in "dchar"? And as
 for "quad" and "half" - it's not intuitively obvious that these are
 floating point.
 
 I'd vote for more obvious names any day:
 int8, int16, int32, int64, int128...
 uint8, uint16, uint32, uint64, uint128...
 real16, real32, real64, real80, real128...
 
 with "int", "uint" and "real" being aliases for whatever type is
 "machine native".


I like this naming scheme, although I have a little trouble with the size of
int being machine dependent. (Isn't there an old language that did that? ;-))

Of course, we'd have to accommodate all the code out there already using long
and short. But new type names for new types should be okay and I like real16
and real128 better than half and quad.

I'm also dubious that long will ever be tiny -- the use cases for very long
integers, while important, aren't that numerous. There's a point of diminishing
returns on processor word size, at least for general purpose machines, that may
well be 64 bits, IMHO.

Paul

(Now if I can just avoid posting this twice!)

I
Oct 12 2007
prev sibling next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Janice Caron wrote:

 real16, real32, real64, real80, real128...


I'd prefer floatN over realN, as that's a more accurate description of 
the type.
(Floating-point types can't represent all real numbers)


(P.S. This is not an approval of this idea, just a suggested 
modification to use *if* it's implemented)
Oct 12 2007
parent reply Nathan Reed <nathaniel.reed gmail.com> writes:
Frits van Bommel wrote:

 Janice Caron wrote:

 real16, real32, real64, real80, real128...


 
 I'd prefer floatN over realN, as that's a more accurate description of 
 the type.
 (Floating-point types can't represent all real numbers)


Integer types can't represent all integers, either...

Thanks,
Nathan Reed
Oct 12 2007
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 10/13/07, Nathan Reed <nathaniel.reed gmail.com> wrote:

 Frits van Bommel wrote:

 Janice Caron wrote:

 real16, real32, real64, real80, real128...


 I'd prefer floatN over realN, as that's a more accurate description of
 the type.
 (Floating-point types can't represent all real numbers)


 Integer types can't represent all integers, either...


Yeah, I had that in mind. An "intN" may represent that subset of the
integers which may be expressed in N bits. Likewise "realN" may
represent that subset of the reals which may be expressed in N bits.

You could certainly argue that all floats are rational, but they don't
store all rational numbers exactly either. As soon as an operation
requires it, they start rounding. A float actually represents a kind
of "fuzzy real" - that is, the true real that it tries to represent
exists somewhere within plus or minus some error bound of the rational
value, and it tries to keep that error bound as small as possible.

That said, realN or floatN -- I'd be happy either way. If we get
realN, then I'd want complexN, not crealN (Yuk!), but if we get floatN
then I guess cfloatN would do.
Oct 12 2007
parent reply Don Clugston <dac nospam.com.au> writes:
Janice Caron wrote:

 On 10/13/07, Nathan Reed <nathaniel.reed gmail.com> wrote:

 Frits van Bommel wrote:

 Janice Caron wrote:

 real16, real32, real64, real80, real128...


 I'd prefer floatN over realN, as that's a more accurate description of
 the type.
 (Floating-point types can't represent all real numbers)


 Integer types can't represent all integers, either...


 
 Yeah, I had that in mind. An "intN" may represent that subset of the
 integers which may be expressed in N bits. Likewise "realN" may
 represent that subset of the reals which may be expressed in N bits.
 
 You could certainly argue that all floats are rational, but they don't
 store all rational numbers exactly either. As soon as an operation
 requires it, they start rounding. A float actually represents a kind
 of "fuzzy real" - that is, the true real that it tries to represent
 exists somewhere within plus or minus some error bound of the rational
 value, and it tries to keep that error bound as small as possible.


That's not right. There's nothing fuzzy about floats. They're just a mapping 
from the infinite set of real numbers into a small subset. A float always 
represents a single true real, and it represents it exactly. It's just that not 
many reals are representable. (The roundoff error exists in the operations, not 
the representation).

The representable reals are all rational, except -0, +/- Infinity, and NaN.


 That said, realN or floatN -- I'd be happy either way. If we get
 realN, then I'd want complexN, not crealN (Yuk!), but if we get floatN
 then I guess cfloatN would do.
Oct 15 2007
parent "Janice Caron" <caron800 googlemail.com> writes:
On 10/15/07, Don Clugston <dac nospam.com.au> wrote:

 Janice Caron wrote:

 You could certainly argue that all floats are rational, but they don't
 store all rational numbers exactly either. As soon as an operation
 requires it, they start rounding. A float actually represents a kind
 of "fuzzy real" - that is, the true real that it tries to represent
 exists somewhere within plus or minus some error bound of the rational
 value, and it tries to keep that error bound as small as possible.


 That's not right. There's nothing fuzzy about floats. They're just a mapping
 from the infinite set of real numbers into a small subset. A float always
 represents a single true real, and it represents it exactly. It's just that not
 many reals are representable. (The roundoff error exists in the operations, not
 the representation).


If you take the point of view that floats are an /exact/
representation of something, then obviously you're right and no one's
going to argue with you.

But I've always taken the view that floats are an /approximate/
representation of stuff. For example, the constant PI. We all know
that the real pi is a transcendental number which /cannot/ be
represented as a rational, but nonetheless float math libraries never
name their constant APPROXIMATELY_PI - we just take that for granted.

You can look at it either way. Yes, a float can be considered as the
set of exactly 2^N reals and special values representable by all
possible float bit patterns. But I don't believe that's a particularly
useful way of looking at it. (With that interpretation, you can't even
represent 1/3). A more useful interpretation, and the one actually
used in real programs, is that floats let us play with real numbers,
so long as we remember that they're only ever going to be approximate.

Everyone's right! :-)
Oct 15 2007
prev sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
Of course this is never going to happen! :-)
Oct 12 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Janice Caron wrote:

 Of course this is never going to happen! :-)


And thank God for that.  No offense, but I get annoyed having to type
"toUtf8" every once in a while with Tango; having to qualify every damn
type with a bit size would drive me up the wall.

	-- Daniel
Oct 12 2007
parent "Janice Caron" <caron800 googlemail.com> writes:
On 10/13/07, Daniel Keep <daniel.keep.lists gmail.com> wrote:

 Janice Caron wrote:

 Of course this is never going to happen! :-)


 And thank God for that.  No offense, but I get annoyed having to type
 "toUtf8" every once in a while with Tango; having to qualify every damn
 type with a bit size would drive me up the wall.


Well, except that you'd just use int, uint and real most of the time,
so no biggie.

That said, if new types are going to be introduced, we might as well
at least consider what they should be called, and whether "half" and
"quad" are the best names.
Oct 13 2007
prev sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Janice Caron wrote:

 On 10/11/07, Olifant <olifant gmail.com> wrote:
 
 I've always thought the names we have for built-in types are (mostly)
 horrible. ...


[snip]

 
 I'd vote for more obvious names any day:
 int8, int16, int32, int64, int128...
 uint8, uint16, uint32, uint64, uint128...
 real16, real32, real64, real80, real128...
 
 with "int", "uint" and "real" being aliases for whatever type is
 "machine native".


I agree, though I'd rather "int" be a big integer type that really does 
handle all integers.  Perhaps something like "word" for the machine 
sized number.

Rationals would be cool too, though I doubt they are worthy of language 
built-in-edness.  If your language can mimic built in types perfectly 
from a library implementation, then the doors are open for frac8, 
frac16, frac32, etc.  "frac" for fraction, since I'm not sure how I feel 
about "rat" :)  It seems that D is headed in this direction of 
user-defined types that can mimic builtins, which is quite awesome.
Oct 13 2007