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 next 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 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
prev sibling parent 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...

the type. (Floating-point types can't represent all real numbers)


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

 
 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
prev sibling next sibling parent "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
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
Of course this is never going to happen! :-)
Oct 12 2007
prev sibling next sibling 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 "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