www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - half datatype?

reply Manu <turkeyman gmail.com> writes:
I've often wondered about having an official 'half' type.
It's very common in rendering/image processing, supported by most video
cards (so compression routines interacting with this type are common), and
it's also supported in hardware by some cpu's.

ARM for instance supports 'half's in hardware, and GCC has an __fp16 type
which would map nicely if D supported the type in the front end.

The alternative us to use ushort everywhere, which is awkward, because it
is neither unsigned, nor is it an integer, and it's not typesafe (allows
direct assignment to ints and stuff)...
It would be nice if: cast(half)someFloat would yield the proper value, even
if it is performed in software in most architectures, it could be mapped to
hardware for those that do it.

It could be done in a library, but then GCC couldn't map it properly to the
hardware type, and since D has no way to describe implicit casts (that I
know of?) it becomes awkward to use.
someFloat = someHalf <- doesn't work, because a cast operator expects an
explicit cast, even though this is a lossless conversion and should be
exactly the same as someDouble = someFloat.

Thoughts?
Nov 18 2012
next sibling parent "Zoadian" <github zoadian.de> writes:
+1

i'm using halffloat regularly, would be nice to have them builtin.
Nov 18 2012
prev sibling next sibling parent "ponce" <spam spam.org> writes:
I tend to agree with your aguments, because the half type could
be very useful to reduce memory usage of data stored as float for
lack of a smaller type.

 The alternative us to use ushort everywhere, which is awkward, 
 because it
 is neither unsigned, nor is it an integer, and it's not 
 typesafe (allows
 direct assignment to ints and stuff)...

For better or worse, you can use a wrapper type around this ushort: https://github.com/p0nce/gfm/blob/master/math/half.d
 It would be nice if: cast(half)someFloat would yield the proper 
 value, even
 if it is performed in software in most architectures, it could 
 be mapped to
 hardware for those that do it.

 It could be done in a library, but then GCC couldn't map it 
 properly to the
 hardware type, and

 since D has no way to describe implicit casts (that I
 know of?) it becomes awkward to use.
 someFloat = someHalf <- doesn't work, because a cast operator 
 expects an
 explicit cast, even though this is a lossless conversion and 
 should be
 exactly the same as someDouble = someFloat.

When I first implemented half floats in D I came to the same conclusion. Built-ins types have implicit conversion but one can't define new ones. Yet it's a trade-off probably choosen for good reasons. How to make sure people won't abuse them? What to do with chained implicit conversions?
Nov 18 2012
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 18 November 2012 at 11:21:37 UTC, Manu wrote:
 someFloat = someHalf <- doesn't work, because a cast operator 
 expects an
 explicit cast, even though this is a lossless conversion and 
 should be
 exactly the same as someDouble = someFloat.

 Thoughts?

--- struct Half { float toFloat() { return 3.14f; } alias toFloat this; } void test() { Half h; float f = h; double d = h; } --- Works for you? David
Nov 18 2012
parent reply Manu <turkeyman gmail.com> writes:
On 18 November 2012 14:01, David Nadlinger <see klickverbot.at> wrote:

 On Sunday, 18 November 2012 at 11:21:37 UTC, Manu wrote:

 someFloat = someHalf <- doesn't work, because a cast operator expects an
 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble = someFloat.

 Thoughts?

--- struct Half { float toFloat() { return 3.14f; } alias toFloat this; } void test() { Half h; float f = h; double d = h; } --- Works for you?

Interesting approach to the implicit cast problem. Very handy trick.
Nov 18 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/18/12 7:30 AM, Manu wrote:
 On 18 November 2012 14:01, David Nadlinger <see klickverbot.at
 <mailto:see klickverbot.at>> wrote:

     On Sunday, 18 November 2012 at 11:21:37 UTC, Manu wrote:

         someFloat = someHalf <- doesn't work, because a cast operator
         expects an
         explicit cast, even though this is a lossless conversion and
         should be
         exactly the same as someDouble = someFloat.

         Thoughts?


     ---
     struct Half {
          float toFloat() { return 3.14f; }
          alias toFloat this;
     }

     void test() {
          Half h;
          float f = h;
          double d = h;
     }
     ---

     Works for you?


 Interesting approach to the implicit cast problem. Very handy trick.

Well that was quite explicitly part of the purpose of alias this. Andrei
Nov 18 2012
next sibling parent Manu <turkeyman gmail.com> writes:
I'm sure that's true, I've just always used it to gain access to members of
embedded types, kinda of like abstraction for 'struct's. It hadn't occurred
to me to support explicit casting in that way.


On 18 November 2012 18:31, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:

 On 11/18/12 7:30 AM, Manu wrote:

 On 18 November 2012 14:01, David Nadlinger <see klickverbot.at

 <mailto:see klickverbot.at>> wrote:

     On Sunday, 18 November 2012 at 11:21:37 UTC, Manu wrote:

         someFloat = someHalf <- doesn't work, because a cast operator
         expects an
         explicit cast, even though this is a lossless conversion and
         should be
         exactly the same as someDouble = someFloat.

         Thoughts?


     ---
     struct Half {
          float toFloat() { return 3.14f; }
          alias toFloat this;
     }

     void test() {
          Half h;
          float f = h;
          double d = h;
     }
     ---

     Works for you?


 Interesting approach to the implicit cast problem. Very handy trick.

Well that was quite explicitly part of the purpose of alias this. Andrei

Nov 18 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
On 19 November 2012 01:58, Manu <turkeyman gmail.com> wrote:

 I'm sure that's true, I've just always used it to gain access to members
 of embedded types, kinda of like abstraction for 'struct's. It hadn't
 occurred to me to support explicit casting in that way.

**cough** IMPLICIT casting. On 18 November 2012 18:31, Andrei Alexandrescu <
 SeeWebsiteForEmail erdani.org> wrote:

 On 11/18/12 7:30 AM, Manu wrote:

 On 18 November 2012 14:01, David Nadlinger <see klickverbot.at

 <mailto:see klickverbot.at>> wrote:

     On Sunday, 18 November 2012 at 11:21:37 UTC, Manu wrote:

         someFloat = someHalf <- doesn't work, because a cast operator
         expects an
         explicit cast, even though this is a lossless conversion and
         should be
         exactly the same as someDouble = someFloat.

         Thoughts?


     ---
     struct Half {
          float toFloat() { return 3.14f; }
          alias toFloat this;
     }

     void test() {
          Half h;
          float f = h;
          double d = h;
     }
     ---

     Works for you?


 Interesting approach to the implicit cast problem. Very handy trick.

Well that was quite explicitly part of the purpose of alias this. Andrei


Nov 18 2012
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11/18/2012 3:21 PM, Manu пишет:
 I've often wondered about having an official 'half' type.
 It's very common in rendering/image processing, supported by most video
 cards (so compression routines interacting with this type are common),
 and it's also supported in hardware by some cpu's.

 ARM for instance supports 'half's in hardware, and GCC has an __fp16
 type which would map nicely if D supported the type in the front end.

 The alternative us to use ushort everywhere, which is awkward, because
 it is neither unsigned, nor is it an integer, and it's not typesafe
 (allows direct assignment to ints and stuff)...
 It would be nice if: cast(half)someFloat would yield the proper value,
 even if it is performed in software in most architectures, it could be
 mapped to hardware for those that do it.

I guess half(someFloat) will do for conversion.
 It could be done in a library, but then GCC couldn't map it properly to
 the hardware type, and since D has no way to describe implicit casts
 (that I know of?) it becomes awkward to use.

alias this should work. Just tried it, works wonders: import std.math; struct half{ ushort data; //this one should be __fp16 where it works //other overloaded ops, etc. alias getFloat this; //***only for the purpose of showing implicit conversion *** float getFloat(){ return data * 0.1; } } void main(){ float x = half(12); assert(abs(x - 1.2) < 1e-6); }
 someFloat = someHalf <- doesn't work, because a cast operator expects an
 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble = someFloat.

 Thoughts?

Everything but hardware support is doable as is. I'm not sure if it's possible and/or feasible to make _efficient_ wrapper type that uses hardware support. The easiest path seems to be: - convince GDC to add __fp16 type as an extension that maps to GCC's one - use it on GDC, and fallback to emulation on DMD That being said I personally have no objections to add half type to built-ins in DMD. -- Dmitry Olshansky
Nov 18 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 18 November 2012 14:13, Dmitry Olshansky <dmitry.olsh gmail.com> wrote:

 11/18/2012 3:21 PM, Manu =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

 I've often wondered about having an official 'half' type.
 It's very common in rendering/image processing, supported by most video
 cards (so compression routines interacting with this type are common),
 and it's also supported in hardware by some cpu's.

 ARM for instance supports 'half's in hardware, and GCC has an __fp16
 type which would map nicely if D supported the type in the front end.

 The alternative us to use ushort everywhere, which is awkward, because
 it is neither unsigned, nor is it an integer, and it's not typesafe
 (allows direct assignment to ints and stuff)...
 It would be nice if: cast(half)someFloat would yield the proper value,
 even if it is performed in software in most architectures, it could be
 mapped to hardware for those that do it.

I guess half(someFloat) will do for conversion.

How do you define 'will do'? It still behaves differently than proper types= . someFloat =3D someDouble without a cast is a compile error, likewise should be true in this case, but I don't know how to do that. someHalf =3D someFloat should require an explicit cast too, or use a 1.0h literal ;) It could be done in a library, but then GCC couldn't map it properly to
 the hardware type, and since D has no way to describe implicit casts
 (that I know of?) it becomes awkward to use.

alias this should work. Just tried it, works wonders: import std.math; struct half{ ushort data; //this one should be __fp16 where it works //other overloaded ops, etc. alias getFloat this; //***only for the purpose of showing implicit conversion *** float getFloat(){ return data * 0.1; } } void main(){ float x =3D half(12); assert(abs(x - 1.2) < 1e-6); }

Yup, that solves the up-cast problem perfectly! I didn't think of that trick. someFloat =3D someHalf <- doesn't work, because a cast operator expects an
 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble =3D someFloat.

 Thoughts?

Everything but hardware support is doable as is. I'm not sure if it's possible and/or feasible to make _efficient_ wrapper type that uses hardware support. The easiest path seems to be: - convince GDC to add __fp16 type as an extension that maps to GCC's one - use it on GDC, and fallback to emulation on DMD That being said I personally have no objections to add half type to built-ins in DMD.

I'm sure it's already accessible in GDC, but it's not portable unless it gets a proper name in the front end. The point would be to name the type, add the conversion functions to druntime for fallback/portability, and a literal 1.0h would be handy to identify the type to templates.
Nov 18 2012
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11/18/2012 4:41 PM, Manu пишет:
         The alternative us to use ushort everywhere, which is awkward,
         because
         it is neither unsigned, nor is it an integer, and it's not typesafe
         (allows direct assignment to ints and stuff)...
         It would be nice if: cast(half)someFloat would yield the proper
         value,
         even if it is performed in software in most architectures, it
         could be
         mapped to hardware for those that do it.


     I guess half(someFloat) will do for conversion.


 How do you define 'will do'? It still behaves differently than proper types.
 someFloat = someDouble without a cast is a compile error, likewise
 should be true in this case, but I don't know how to do that.
 someHalf = someFloat should require an explicit cast too, or use a 1.0h
 literal ;)

The point was it does now. Wrapper struct doesn't accept direct assignments from float (unless you want it to and defined opAssign to do that). alias this trick makes it magical r-value of type float where it makes sense. Obviously on assignment it doesn't ;) In code: half myHalf = half(1.23); myHalf = 35; //doesn't compile myHalf = half(35); //works The example though demonstrates one painful limitation of a wrapper - no value range propagation. Basically since 35 fits into a half, no explicit cast should be needed. And that's a big deal sometimes: ubyte flags = 0x80 | 0x40; //no casts, thank God
     Everything but hardware support is doable as is. I'm not sure if
     it's possible and/or feasible to make _efficient_ wrapper type that
     uses hardware support.

     The easiest path seems to be:
     - convince GDC to add __fp16 type as an extension that maps to GCC's one
     - use it on GDC, and fallback to emulation on DMD

     That being said I personally have no objections to add half type to
     built-ins in DMD.


 I'm sure it's already accessible in GDC,

Good to know.
 The point would be to name the type, add the conversion functions to
 druntime for fallback/portability, and a literal 1.0h would be handy to
 identify the type to templates.

Mmm the literal. Dunno but '1h' looks like 1 hour to me :) Another trick to pull is to use UFCS: property auto hf(T)(T value) if(isFloatingPoint!T || isIntegral!T) { return half(value); } Then 1.0.hf && 32.hf both should work. Not as nice as true suffix but damn close. -- Dmitry Olshansky
Nov 18 2012
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 18 November 2012 12:41, Manu <turkeyman gmail.com> wrote:
 On 18 November 2012 14:13, Dmitry Olshansky <dmitry.olsh gmail.com> wrote=

:
 11/18/2012 3:21 PM, Manu =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
 I've often wondered about having an official 'half' type.
 It's very common in rendering/image processing, supported by most video
 cards (so compression routines interacting with this type are common),
 and it's also supported in hardware by some cpu's.

 ARM for instance supports 'half's in hardware, and GCC has an __fp16
 type which would map nicely if D supported the type in the front end.

 The alternative us to use ushort everywhere, which is awkward, because
 it is neither unsigned, nor is it an integer, and it's not typesafe
 (allows direct assignment to ints and stuff)...
 It would be nice if: cast(half)someFloat would yield the proper value,
 even if it is performed in software in most architectures, it could be
 mapped to hardware for those that do it.

I guess half(someFloat) will do for conversion.

How do you define 'will do'? It still behaves differently than proper typ=

es.
 someFloat =3D someDouble without a cast is a compile error, likewise shou=

ld be
 true in this case, but I don't know how to do that.
 someHalf =3D someFloat should require an explicit cast too, or use a 1.0h
 literal ;)

 It could be done in a library, but then GCC couldn't map it properly to
 the hardware type, and since D has no way to describe implicit casts
 (that I know of?) it becomes awkward to use.

alias this should work. Just tried it, works wonders: import std.math; struct half{ ushort data; //this one should be __fp16 where it works //other overloaded ops, etc. alias getFloat this; //***only for the purpose of showing implicit conversion *** float getFloat(){ return data * 0.1; } } void main(){ float x =3D half(12); assert(abs(x - 1.2) < 1e-6); }

Yup, that solves the up-cast problem perfectly! I didn't think of that trick.
 someFloat =3D someHalf <- doesn't work, because a cast operator expects=



an
 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble =3D someFloat.

 Thoughts?

Everything but hardware support is doable as is. I'm not sure if it's possible and/or feasible to make _efficient_ wrapper type that uses hard=


ware
 support.

 The easiest path seems to be:
 - convince GDC to add __fp16 type as an extension that maps to GCC's one
 - use it on GDC, and fallback to emulation on DMD

 That being said I personally have no objections to add half type to
 built-ins in DMD.

I'm sure it's already accessible in GDC, but it's not portable unless it gets a proper name in the front end. The point would be to name the type, add the conversion functions to druntime for fallback/portability, and a literal 1.0h would be handy to identify the type to templates.

The two modes guaranteed to exist in GDC are single and double (reals could be a vagarity of sizes). Half I believe is only defined (internally) for ARM. --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Nov 18 2012
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 18 Nov 2012 05:21:27 -0600, Manu <turkeyman gmail.com> wrote:

 I've often wondered about having an official 'half' type.
 It's very common in rendering/image processing, supported by most video
 cards (so compression routines interacting with this type are common), and
 it's also supported in hardware by some cpu's.

 ARM for instance supports 'half's in hardware, and GCC has an __fp16 type
 which would map nicely if D supported the type in the front end.

 The alternative us to use ushort everywhere, which is awkward, because it
 is neither unsigned, nor is it an integer, and it's not typesafe (allows
 direct assignment to ints and stuff)...
 It would be nice if: cast(half)someFloat would yield the proper value, even
 if it is performed in software in most architectures, it could be mapped to
 hardware for those that do it.

 It could be done in a library, but then GCC couldn't map it properly to the
 hardware type, and since D has no way to describe implicit casts (that I
 know of?) it becomes awkward to use.
 someFloat = someHalf <- doesn't work, because a cast operator expects an
 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble = someFloat.

 Thoughts?

Vote--. The a half data type is already part of std.numeric. From the docs: // Define a 16-bit floating point values CustomFloat!16 x; // Using the number of bits CustomFloat!(10, 5) y; // Using the precision and exponent width CustomFloat!(10, 5,CustomFloatFlags.ieee) z; // Using the precision, exponent width and format flags CustomFloat!(10, 5,CustomFloatFlags.ieee, 15) w; // Using the precision, exponent width, format flags and exponent offset bias // Use the 16-bit floats mostly like normal numbers w = x*y - 1; writeln(w); // Functions calls require conversion z = sin(+x) + cos(+y); // Use uniary plus to concisely convert to a real z = sin(x.re) + cos(y.re); // Or use the .re property to convert to a real z = sin(x.get!float) + cos(y.get!float); // Or use get!T z = sin(cast(float)x) + cos(cast(float)y); // Or use cast(T) to explicitly convert // Define a 8-bit custom float for storing probabilities alias CustomFloat!(4, 4, CustomFloatFlags.ieee^CustomFloatFlags.probability^CustomFloatFlags.signed ) Probability; auto p = Probability(0.5);
Nov 18 2012
parent reply Manu <turkeyman gmail.com> writes:
On 19 November 2012 01:08, Robert Jacques <sandford jhu.edu> wrote:

 On Sun, 18 Nov 2012 05:21:27 -0600, Manu <turkeyman gmail.com> wrote:

  I've often wondered about having an official 'half' type.
 It's very common in rendering/image processing, supported by most video
 cards (so compression routines interacting with this type are common), and
 it's also supported in hardware by some cpu's.

 ARM for instance supports 'half's in hardware, and GCC has an __fp16 type
 which would map nicely if D supported the type in the front end.

 The alternative us to use ushort everywhere, which is awkward, because it
 is neither unsigned, nor is it an integer, and it's not typesafe (allows
 direct assignment to ints and stuff)...
 It would be nice if: cast(half)someFloat would yield the proper value,
 even
 if it is performed in software in most architectures, it could be mapped
 to
 hardware for those that do it.

 It could be done in a library, but then GCC couldn't map it properly to
 the
 hardware type, and since D has no way to describe implicit casts (that I
 know of?) it becomes awkward to use.
 someFloat = someHalf <- doesn't work, because a cast operator expects an
 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble = someFloat.

 Thoughts?

Vote--. The a half data type is already part of std.numeric. From the docs: // Define a 16-bit floating point values CustomFloat!16 x; // Using the number of bits CustomFloat!(10, 5) y; // Using the precision and exponent width CustomFloat!(10, 5,CustomFloatFlags.ieee) z; // Using the precision, exponent width and format flags CustomFloat!(10, 5,CustomFloatFlags.ieee, 15) w; // Using the precision, exponent width, format flags and exponent offset bias // Use the 16-bit floats mostly like normal numbers w = x*y - 1; writeln(w); // Functions calls require conversion z = sin(+x) + cos(+y); // Use uniary plus to concisely convert to a real z = sin(x.re) + cos(y.re); // Or use the .re property to convert to a real z = sin(x.get!float) + cos(y.get!float); // Or use get!T z = sin(cast(float)x) + cos(cast(float)y); // Or use cast(T) to explicitly convert // Define a 8-bit custom float for storing probabilities alias CustomFloat!(4, 4, CustomFloatFlags.ieee^** CustomFloatFlags.probability^**CustomFloatFlags.signed ) Probability; auto p = Probability(0.5);

I still can't buy arguments like this. It completely changes the syntax. If I told you this is how real should be implemented, would you vote ++? What about double? Why? Why not float for that matter? There seems like no reason for the language to define any floating point type at all if you consider this acceptable... 'half' isn't some custom float for niche use, it's an established standard, implemented in vastly more hardware than implements 'real'.
Nov 18 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/18/2012 4:31 PM, Manu wrote:
 If I told you this is how real should be implemented, would you vote ++? What
 about double? Why?
 Why not float for that matter? There seems like no reason for the language to
 define any floating point type at all if you consider this acceptable...

Because they are implemented in hardware. It's pretty dang hard for a compiler to look at a floating point emulator and figure out "gee, I have a nice hardware instruction that does the same thing as this 2K of code!"
 'half' isn't some custom float for niche use, it's an established standard,
 implemented in vastly more hardware than implements 'real'.

It's implemented in GPUs, sure, but it is it implemented in hardware that D runs on? (I do know about this: http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.html) There is no major technical difficulty in implementing it as a basic type, but I want to be sure we've exhausted the library approach first.
Nov 18 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 19 November 2012 06:19, Walter Bright <newshound2 digitalmars.com> wrote:

 On 11/18/2012 4:31 PM, Manu wrote:

 If I told you this is how real should be implemented, would you vote ++?
 What
 about double? Why?
 Why not float for that matter? There seems like no reason for the
 language to
 define any floating point type at all if you consider this acceptable...

Because they are implemented in hardware. It's pretty dang hard for a compiler to look at a floating point emulator and figure out "gee, I have a nice hardware instruction that does the same thing as this 2K of code!"

Right, and this is my point precisely. It's hard for GDC for instance to hook some complex library because it happens to have hardware to do it. 'half' isn't some custom float for niche use, it's an established standard,
 implemented in vastly more hardware than implements 'real'.

It's implemented in GPUs, sure, but it is it implemented in hardware that D runs on? (I do know about this: http://gcc.gnu.org/onlinedocs/** gcc/Half_002dPrecision.html<http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.html> ) There is no major technical difficulty in implementing it as a basic type, but I want to be sure we've exhausted the library approach first.

Well it's available in hardware on basically all mobile devices (that's a LOT of devices (in the billions)), but even if it's just implemented in software (x86), the values are consumed by the GPU, and the validity of the values is no less important. It still seems like a valuable 1st class type; why shouldn't it enjoy the same casting, assignment, literal, range checking rules as the rest of the floats? Additionally, convenience and compatibility with generic code would be significantly improved. I don't see how it can be made to feel seamless with a lib... and that sounds like an awful lot more work. Anyway, I'm not desperate for this personally. I just wondered how people felt about it in general, and if it was something that should/would be seriously considered.
Nov 19 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/19/2012 8:04 AM, Manu wrote:
 Well it's available in hardware on basically all mobile devices (that's a LOT
of
 devices (in the billions)), but even if it's just implemented in software
(x86),
 the values are consumed by the GPU, and the validity of the values is no less
 important. It still seems like a valuable 1st class type; why shouldn't it
enjoy
 the same casting, assignment, literal, range checking rules as the rest of the
 floats? Additionally, convenience and compatibility with generic code would be
 significantly improved.
 I don't see how it can be made to feel seamless with a lib... and that sounds
 like an awful lot more work.

By making a library type that implicitly converts to/from float, and then doing the operations on float, that should about cover it. For the ARM, the conversion itself could be done by a builtin function, which can use the ARM hardware instruction for it. For literals, I think: __fp16(3.5) coupled with UTFE can work.
 Anyway, I'm not desperate for this personally. I just wondered how people felt
 about it in general, and if it was something that should/would be seriously
 considered.

I think it should be considered.
Nov 19 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 19 November 2012 16:04, Manu <turkeyman gmail.com> wrote:
 On 19 November 2012 06:19, Walter Bright <newshound2 digitalmars.com> wrote:
 On 11/18/2012 4:31 PM, Manu wrote:
 If I told you this is how real should be implemented, would you vote ++?
 What
 about double? Why?
 Why not float for that matter? There seems like no reason for the
 language to
 define any floating point type at all if you consider this acceptable...

Because they are implemented in hardware. It's pretty dang hard for a compiler to look at a floating point emulator and figure out "gee, I have a nice hardware instruction that does the same thing as this 2K of code!"

Right, and this is my point precisely. It's hard for GDC for instance to hook some complex library because it happens to have hardware to do it.
 'half' isn't some custom float for niche use, it's an established
 standard,
 implemented in vastly more hardware than implements 'real'.

It's implemented in GPUs, sure, but it is it implemented in hardware that D runs on? (I do know about this: http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.html) There is no major technical difficulty in implementing it as a basic type, but I want to be sure we've exhausted the library approach first.

Well it's available in hardware on basically all mobile devices (that's a LOT of devices (in the billions)), but even if it's just implemented in software (x86), the values are consumed by the GPU, and the validity of the values is no less important. It still seems like a valuable 1st class type; why shouldn't it enjoy the same casting, assignment, literal, range checking rules as the rest of the floats? Additionally, convenience and compatibility with generic code would be significantly improved. I don't see how it can be made to feel seamless with a lib... and that sounds like an awful lot more work. Anyway, I'm not desperate for this personally. I just wondered how people felt about it in general, and if it was something that should/would be seriously considered.

I'm neither here nor there. I'm just pointing out that you are proposing a dedicated type to be introduced that is supported on only one platform. :-) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 19 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On 19 November 2012 19:28, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On 19 November 2012 16:04, Manu <turkeyman gmail.com> wrote:
 On 19 November 2012 06:19, Walter Bright <newshound2 digitalmars.com>

wrote:
 On 11/18/2012 4:31 PM, Manu wrote:
 If I told you this is how real should be implemented, would you vote



++?
 What
 about double? Why?
 Why not float for that matter? There seems like no reason for the
 language to
 define any floating point type at all if you consider this



acceptable...
 Because they are implemented in hardware. It's pretty dang hard for a
 compiler to look at a floating point emulator and figure out "gee, I


have a
 nice hardware instruction that does the same thing as this 2K of code!"

Right, and this is my point precisely. It's hard for GDC for instance to hook some complex library because it happens to have hardware to do it.
 'half' isn't some custom float for niche use, it's an established
 standard,
 implemented in vastly more hardware than implements 'real'.

It's implemented in GPUs, sure, but it is it implemented in hardware


that
 D runs on? (I do know about this:
 http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.html)

 There is no major technical difficulty in implementing it as a basic


type,
 but I want to be sure we've exhausted the library approach first.

Well it's available in hardware on basically all mobile devices (that's a LOT of devices (in the billions)), but even if it's just implemented in software (x86), the values are consumed by the GPU, and the validity of

the
 values is no less important. It still seems like a valuable 1st class

type;
 why shouldn't it enjoy the same casting, assignment, literal, range

checking
 rules as the rest of the floats? Additionally, convenience and

compatibility
 with generic code would be significantly improved.
 I don't see how it can be made to feel seamless with a lib... and that
 sounds like an awful lot more work.


 Anyway, I'm not desperate for this personally. I just wondered how people
 felt about it in general, and if it was something that should/would be
 seriously considered.

I'm neither here nor there. I'm just pointing out that you are proposing a dedicated type to be introduced that is supported on only one platform. :-)

real is only supported on one platform (x86, it's deprecated in x64 and x87 will likely be removed/emulated in the future), but I think many here consider it valuable(?). And that's not strictly true either, virtually every machine has a GPU, and host software still has to process data for it. I'm mainly encouraging this for the sake of correctness/type safety, though hardware support on ARM would be a particularly nice bonus. I also wanted to gauge the interest/opposition.
Nov 19 2012
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 19 November 2012 17:57, Manu <turkeyman gmail.com> wrote:
 On 19 November 2012 19:28, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 On 19 November 2012 16:04, Manu <turkeyman gmail.com> wrote:
 On 19 November 2012 06:19, Walter Bright <newshound2 digitalmars.com>
 wrote:
 On 11/18/2012 4:31 PM, Manu wrote:
 If I told you this is how real should be implemented, would you vote
 ++?
 What
 about double? Why?
 Why not float for that matter? There seems like no reason for the
 language to
 define any floating point type at all if you consider this
 acceptable...

Because they are implemented in hardware. It's pretty dang hard for a compiler to look at a floating point emulator and figure out "gee, I have a nice hardware instruction that does the same thing as this 2K of code!"

Right, and this is my point precisely. It's hard for GDC for instance to hook some complex library because it happens to have hardware to do it.
 'half' isn't some custom float for niche use, it's an established
 standard,
 implemented in vastly more hardware than implements 'real'.

It's implemented in GPUs, sure, but it is it implemented in hardware that D runs on? (I do know about this: http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.html) There is no major technical difficulty in implementing it as a basic type, but I want to be sure we've exhausted the library approach first.

Well it's available in hardware on basically all mobile devices (that's a LOT of devices (in the billions)), but even if it's just implemented in software (x86), the values are consumed by the GPU, and the validity of the values is no less important. It still seems like a valuable 1st class type; why shouldn't it enjoy the same casting, assignment, literal, range checking rules as the rest of the floats? Additionally, convenience and compatibility with generic code would be significantly improved. I don't see how it can be made to feel seamless with a lib... and that sounds like an awful lot more work. Anyway, I'm not desperate for this personally. I just wondered how people felt about it in general, and if it was something that should/would be seriously considered.

I'm neither here nor there. I'm just pointing out that you are proposing a dedicated type to be introduced that is supported on only one platform. :-)

real is only supported on one platform (x86, it's deprecated in x64 and x87 will likely be removed/emulated in the future), but I think many here consider it valuable(?). And that's not strictly true either, virtually every machine has a GPU, and host software still has to process data for it. I'm mainly encouraging this for the sake of correctness/type safety, though hardware support on ARM would be a particularly nice bonus. I also wanted to gauge the interest/opposition.

Real is mapped to the target's long double. It could be 64bit, 80bit, 96bit, or 128bit. The phobos math library already caters for this. :-) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 19 2012
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 18 Nov 2012 05:21:27 -0600, Manu <turkeyman gmail.com> wrote:

 I've often wondered about having an official 'half' type.
 It's very common in rendering/image processing, supported by most video
 cards (so compression routines interacting with this type are common), and
 it's also supported in hardware by some cpu's.

 ARM for instance supports 'half's in hardware, and GCC has an __fp16 type
 which would map nicely if D supported the type in the front end.

 The alternative us to use ushort everywhere, which is awkward, because it
 is neither unsigned, nor is it an integer, and it's not typesafe (allows
 direct assignment to ints and stuff)...
 It would be nice if: cast(half)someFloat would yield the proper value, even
 if it is performed in software in most architectures, it could be mapped to
 hardware for those that do it.

 It could be done in a library, but then GCC couldn't map it properly to the
 hardware type, and since D has no way to describe implicit casts (that I
 know of?) it becomes awkward to use.
 someFloat = someHalf <- doesn't work, because a cast operator expects an
 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble = someFloat.

 Thoughts?

Vote--. The a half data type is already part of std.numeric. From the docs: // Define a 16-bit floating point values CustomFloat!16 x; // Using the number of bits CustomFloat!(10, 5) y; // Using the precision and exponent width CustomFloat!(10, 5,CustomFloatFlags.ieee) z; // Using the precision, exponent width and format flags CustomFloat!(10, 5,CustomFloatFlags.ieee, 15) w; // Using the precision, exponent width, format flags and exponent offset bias // Use the 16-bit floats mostly like normal numbers w = x*y - 1; writeln(w); // Functions calls require conversion z = sin(+x) + cos(+y); // Use uniary plus to concisely convert to a real z = sin(x.re) + cos(y.re); // Or use the .re property to convert to a real z = sin(x.get!float) + cos(y.get!float); // Or use get!T z = sin(cast(float)x) + cos(cast(float)y); // Or use cast(T) to explicitly convert // Define a 8-bit custom float for storing probabilities alias CustomFloat!(4, 4, CustomFloatFlags.ieee^CustomFloatFlags.probability^CustomFloatFlags.signed ) Probability; auto p = Probability(0.5);
Nov 18 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, November 19, 2012 19:57:37 Manu wrote:
 I also wanted to gauge the interest/opposition.

I'd never even _heard_ of half types before this discussion came up. But then again, the same goes for SIMD. And IIRC, there was some sort of function attribute relating to pointers and registers that you or some other gaming person was insisting on a while back, and I'd never heard of it existing in C++ either (as an extension or otherwise). You clearly program in a very different world than I do. I care about high performance in what I do but nothing on _that_ level. I suspect that this is another one of those things that certain folks would really like to have, and most of the rest of us don't have any real interest in and often know nothing about in the first place. I don't know that I really care whether it's added to the language though. I'll leave that sort of decision up to Walter. If anything, I just find it interesting how many low level things folks like you keep coming up with as must-haves or very strong wants that I've never even heard of and will almost certainly never care about aside perhaps from how having them in D might help D catch on. - Jonathan M Davis
Nov 19 2012
next sibling parent reply "Rob T" <rob ucora.com> writes:
On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis 
wrote:
 I'd never even _heard_ of half types before this discussion 
 came up. But then
 again, the same goes for SIMD. And IIRC, there was some sort of 
 function
 attribute relating to pointers and registers that you or some 
 other gaming
 person was insisting on a while back, and I'd never heard of it 
 existing in
 C++ either (as an extension or otherwise). You clearly program 
 in a very
 different world than I do. I care about high performance in 
 what I do but
 nothing on _that_ level. I suspect that this is another one of 
 those things
 that certain folks would really like to have, and most of the 
 rest of us don't
 have any real interest in and often know nothing about in the 
 first place. I
 don't know that I really care whether it's added to the 
 language though. I'll
 leave that sort of decision up to Walter.

 If anything, I just find it interesting how many low level 
 things folks like
 you keep coming up with as must-haves or very strong wants that 
 I've never
 even heard of and will almost certainly never care about aside 
 perhaps from
 how having them in D might help D catch on.

 - Jonathan M Davis

Anyone interested in the low precision float types, and what they are good for, can start here http://www.opengl.org/wiki/Small_Float_Formats I did not read through all of this thread, but my guess is that the people making the request for half float are mostly into game development and image processing. When I first started investigating D as a potential C++ replacement, I noted that a lot of the "visible" development (what I could see being publicized) was game development, so it seemed that for some reason a lot of the D users were also game developers, so there's perhaps something about D that they find attractive. Why game devs are interested so much in D is interesting considering the GC is noted to be a problem for game devs. The work of H. S. Teoh comes to mind with his work on a game engine, that pushed the limits of the GC and std lib. In any case, the point is that I don't think the D community should overlook what the game devs are doing, they're pushing D to its limits and are making D more visible than perhaps anyone. --rt
Nov 19 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/19/2012 12:28 PM, Rob T wrote:
 In any case, the point is that I don't think the D community should overlook
 what the game devs are doing, they're pushing D to its limits and are making D
 more visible than perhaps anyone.

I agree. I might also point out that adoption of a language (or any new technology) often happens because it solves a problem for an otherwise overlooked niche, and their adoption of it drives it into the mainstream.
Nov 19 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, November 19, 2012 12:55:11 Walter Bright wrote:
 On 11/19/2012 12:28 PM, Rob T wrote:
 In any case, the point is that I don't think the D community should
 overlook what the game devs are doing, they're pushing D to its limits
 and are making D more visible than perhaps anyone.

I agree. I might also point out that adoption of a language (or any new technology) often happens because it solves a problem for an otherwise overlooked niche, and their adoption of it drives it into the mainstream.

I don't disagree at all. I just find it interesting how many things that the game devs keep coming up with that they consider critical that most of the rest of us haven't ever even considered and frequently know absolutely nothing about. - Jonathan M Davis
Nov 19 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
On 20 November 2012 02:51, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Monday, November 19, 2012 12:55:11 Walter Bright wrote:
 On 11/19/2012 12:28 PM, Rob T wrote:
 In any case, the point is that I don't think the D community should
 overlook what the game devs are doing, they're pushing D to its limits
 and are making D more visible than perhaps anyone.

I agree. I might also point out that adoption of a language (or any new

technology)
 often happens because it solves a problem for an otherwise overlooked
 niche, and their adoption of it drives it into the mainstream.

I don't disagree at all. I just find it interesting how many things that the game devs keep coming up with that they consider critical that most of the rest of us haven't ever even considered and frequently know absolutely nothing about.

Dunno what to tell you. Gamedev is a strange union of 3-4-5 very distinct fields of programming, each with their own set of requirements, and often just the interaction between them is an interesting problem in its self. Engine programming is the most critical though, with virtually no room for compromise. D needs to be competitive in that space if it hopes to dislodge C/C++, and it's not far off.
Nov 19 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 19 November 2012 22:28, Rob T <rob ucora.com> wrote:

 On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis wrote:

 I'd never even _heard_ of half types before this discussion came up. But
 then
 again, the same goes for SIMD. And IIRC, there was some sort of function
 attribute relating to pointers and registers that you or some other gaming
 person was insisting on a while back, and I'd never heard of it existing
 in
 C++ either (as an extension or otherwise). You clearly program in a very
 different world than I do. I care about high performance in what I do but
 nothing on _that_ level. I suspect that this is another one of those
 things
 that certain folks would really like to have, and most of the rest of us
 don't
 have any real interest in and often know nothing about in the first
 place. I
 don't know that I really care whether it's added to the language though.
 I'll
 leave that sort of decision up to Walter.

 If anything, I just find it interesting how many low level things folks
 like
 you keep coming up with as must-haves or very strong wants that I've never
 even heard of and will almost certainly never care about aside perhaps
 from
 how having them in D might help D catch on.

 - Jonathan M Davis

Anyone interested in the low precision float types, and what they are good for, can start here http://www.opengl.org/wiki/**Small_Float_Formats<http://www.opengl.org/wiki/Small_Float_Formats> I did not read through all of this thread, but my guess is that the people making the request for half float are mostly into game development and image processing. When I first started investigating D as a potential C++ replacement, I noted that a lot of the "visible" development (what I could see being publicized) was game development, so it seemed that for some reason a lot of the D users were also game developers, so there's perhaps something about D that they find attractive.

I've said it before, but I think D has MASSIVE potential in gaming. We are an industry crying our for salvation from C++, but there's no possibility to compromise on the level of access it provides us to the hardware we work with. D is the only language I know of that seriously threatens to offer modern programming constructs, while still providing a syntax and compiler technology that I can easily understand in terms of code generation and can hit the metal when I need to. Additionally, most games programmers have very long-term relationships with C++ almost exclusively, so despite hating it, moving to something utterly different like rust or whatever cool thing comes along will just never fly. You'll never convince a team of 10-30 programmers to agree on such a change all at once, and re-training staff in something so foreign would never be economical. D is again particularly interesting here because it's enough like C++ and C# that programmers feel immediately comfortable and somewhat liberated, but not threatened. Also, in a lot of cases, the changes to D are relatively intuitive. The things you expect should work, often just do... but there are still lots of rough edges too. Gaming is a very demanding and progressive field of software, but also very backwards at the same time. It's a sort of unity between many disciplines, and it all comes together under a performance critical and usually embedded umbrella, in a highly competitive and fickle industry. You can't tell the customer to upgrade their hardware when it needs to run on a console with an ~8 year lifecycle. As a (tech/engine) programmer, if you don't scrutinise the code generation, calling conventions, memory access patterns, data layout and sizes, the competition will, and their product will appear superior. Towards the end of that 8 year cycle, programmers are REALLY squeezing these machines. If the language doesn't support that, then you can't compete anymore, hence we remain stuck on C++ (and there are many instances where the industry is reverting to C because C++ is a bloaty pig). Why game devs are interested so much in D is interesting considering the GC
 is noted to be a problem for game devs. The work of H. S. Teoh comes to
 mind with his work on a game engine, that pushed the limits of the GC and
 std lib.

I'll admit this is my biggest fear hands down! That said, D is the only GC based language I know if where the GC is relatively optional. This allows us to hedge our bets, and ease in to it slowly as we gain confidence and understanding of how it behaves. I don't yet have much confidence in the GC, and generally avoid using it. I only use it for short term allocations, or non-critical-loop work which often only survive for the scope of the function. I don't have enough experience to make any reasonable claims about its affect on performance, but I have seen a lot of benchmarks in this NG though that have shown it is significantly inferior to C# and Java. That doesn't fill me with confidence. I do hope work is done to make it at least competitive with java/C#'s GC, and then we'll see where we stand. C#'s GC is proven to be acceptable in at least smaller/independent games. It's probably still not acceptable on major AAA console titles though. We need thread-local collection... it can't stop the world to do a collect, and I wouldn't afford more than 1ms at any given time (and I think that's even being generous). Perhaps incremental collection where it would stop after it reaches its allocated time budget or something? So my working theory is, if the GC were limited to relatively few 'convenience allocations' and the bulk of memory was still managed manually, maybe that will lift the load to the point that the cost is insignificant, and it will be a useful tool...? But yes, for the moment, we use malloc and emplace. I think this will mature only with experience and it'll help if there are receptive ears to our needs. It's impossible for us to complain to the C# guys about the habits of their GC and expect anyone to care. This community offers options. We don't HATE garbage collection, we just can't generally afford it. In any case, the point is that I don't think the D community should
 overlook what the game devs are doing, they're pushing D to its limits and
 are making D more visible than perhaps anyone.

This is about the only thing of significance I think we can hope to offer back to the community. If we can use it successfully in a major commercial game, then tell the story afterwards, I think that could bring a lot of new interest. I hope we are able to do that. I think maturity is reaching the point where people can realistically start to consider taking a risk with it. I'd love to see more movement on the android/ios front, I reckon there's a lot more immediate potential in that space given that it's a lot less risky and the bar isn't as high.
Nov 19 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-20 01:45, Manu wrote:
 On 19 November 2012 22:28, Rob T <rob ucora.com <mailto:rob ucora.com>>
 wrote:

     On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis wrote:

         I'd never even _heard_ of half types before this discussion came
         up. But then
         again, the same goes for SIMD. And IIRC, there was some sort of
         function
         attribute relating to pointers and registers that you or some
         other gaming
         person was insisting on a while back, and I'd never heard of it
         existing in
         C++ either (as an extension or otherwise). You clearly program
         in a very
         different world than I do. I care about high performance in what
         I do but
         nothing on _that_ level. I suspect that this is another one of
         those things
         that certain folks would really like to have, and most of the
         rest of us don't
         have any real interest in and often know nothing about in the
         first place. I
         don't know that I really care whether it's added to the language
         though. I'll
         leave that sort of decision up to Walter.

         If anything, I just find it interesting how many low level
         things folks like
         you keep coming up with as must-haves or very strong wants that
         I've never
         even heard of and will almost certainly never care about aside
         perhaps from
         how having them in D might help D catch on.

         - Jonathan M Davis


     Anyone interested in the low precision float types, and what they
     are good for, can start here
     http://www.opengl.org/wiki/__Small_Float_Formats
     <http://www.opengl.org/wiki/Small_Float_Formats>

     I did not read through all of this thread, but my guess is that the
     people making the request for half float are mostly into game
     development and image processing.

     When I first started investigating D as a potential C++ replacement,
     I noted that a lot of the "visible" development (what I could see
     being publicized) was game development, so it seemed that for some
     reason a lot of the D users were also game developers, so there's
     perhaps something about D that they find attractive.


 I've said it before, but I think D has MASSIVE potential in gaming. We
 are an industry crying our for salvation from C++, but there's no
 possibility to compromise on the level of access it provides us to the
 hardware we work with.
 D is the only language I know of that seriously threatens to offer
 modern programming constructs, while still providing a syntax and
 compiler technology that I can easily understand in terms of code
 generation and can hit the metal when I need to.

 Additionally, most games programmers have very long-term relationships
 with C++ almost exclusively, so despite hating it, moving to something
 utterly different like rust or whatever cool thing comes along will just
 never fly. You'll never convince a team of 10-30 programmers to agree on
 such a change all at once, and re-training staff in something so foreign
 would never be economical.
 D is again particularly interesting here because it's enough like C++
 and C# that programmers feel immediately comfortable and somewhat
 liberated, but not threatened. Also, in a lot of cases, the changes to D
 are relatively intuitive. The things you expect should work, often just
 do... but there are still lots of rough edges too.

 Gaming is a very demanding and progressive field of software, but also
 very backwards at the same time. It's a sort of unity between many
 disciplines, and it all comes together under a performance critical and
 usually embedded umbrella, in a highly competitive and fickle industry.
 You can't tell the customer to upgrade their hardware when it needs to
 run on a console with an ~8 year lifecycle. As a (tech/engine)
 programmer, if you don't scrutinise the code generation, calling
 conventions, memory access patterns, data layout and sizes, the
 competition will, and their product will appear superior. Towards the
 end of that 8 year cycle, programmers are REALLY squeezing these
 machines. If the language doesn't support that, then you can't compete
 anymore, hence we remain stuck on C++ (and there are many instances
 where the industry is reverting to C because C++ is a bloaty pig).

     Why game devs are interested so much in D is interesting considering
     the GC is noted to be a problem for game devs. The work of H. S.
     Teoh comes to mind with his work on a game engine, that pushed the
     limits of the GC and std lib.


 I'll admit this is my biggest fear hands down!
 That said, D is the only GC based language I know if where the GC is
 relatively optional. This allows us to hedge our bets, and ease in to it
 slowly as we gain confidence and understanding of how it behaves.
 I don't yet have much confidence in the GC, and generally avoid using
 it. I only use it for short term allocations, or non-critical-loop work
 which often only survive for the scope of the function.

Someone has created GC free versions of Phobos and druntime: http://3d.benjamin-thaut.de/?p=20#more-20 Was posted here: http://forum.dlang.org/thread/k27bh7$t7f$1 digitalmars.com -- /Jacob Carlborg
Nov 19 2012
parent reply Manu <turkeyman gmail.com> writes:
On 20 November 2012 09:41, Jacob Carlborg <doob me.com> wrote:

 On 2012-11-20 01:45, Manu wrote:

 On 19 November 2012 22:28, Rob T <rob ucora.com <mailto:rob ucora.com>>

 wrote:

     On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis wrote:

         I'd never even _heard_ of half types before this discussion came
         up. But then
         again, the same goes for SIMD. And IIRC, there was some sort of
         function
         attribute relating to pointers and registers that you or some
         other gaming
         person was insisting on a while back, and I'd never heard of it
         existing in
         C++ either (as an extension or otherwise). You clearly program
         in a very
         different world than I do. I care about high performance in what
         I do but
         nothing on _that_ level. I suspect that this is another one of
         those things
         that certain folks would really like to have, and most of the
         rest of us don't
         have any real interest in and often know nothing about in the
         first place. I
         don't know that I really care whether it's added to the language
         though. I'll
         leave that sort of decision up to Walter.

         If anything, I just find it interesting how many low level
         things folks like
         you keep coming up with as must-haves or very strong wants that
         I've never
         even heard of and will almost certainly never care about aside
         perhaps from
         how having them in D might help D catch on.

         - Jonathan M Davis


     Anyone interested in the low precision float types, and what they
     are good for, can start here
     http://www.opengl.org/wiki/__**Small_Float_Formats<http://www.opengl.org/wiki/__Small_Float_Formats>

     <http://www.opengl.org/wiki/**Small_Float_Formats<http://www.opengl.org/wiki/Small_Float_Formats>

I did not read through all of this thread, but my guess is that the people making the request for half float are mostly into game development and image processing. When I first started investigating D as a potential C++ replacement, I noted that a lot of the "visible" development (what I could see being publicized) was game development, so it seemed that for some reason a lot of the D users were also game developers, so there's perhaps something about D that they find attractive. I've said it before, but I think D has MASSIVE potential in gaming. We are an industry crying our for salvation from C++, but there's no possibility to compromise on the level of access it provides us to the hardware we work with. D is the only language I know of that seriously threatens to offer modern programming constructs, while still providing a syntax and compiler technology that I can easily understand in terms of code generation and can hit the metal when I need to. Additionally, most games programmers have very long-term relationships with C++ almost exclusively, so despite hating it, moving to something utterly different like rust or whatever cool thing comes along will just never fly. You'll never convince a team of 10-30 programmers to agree on such a change all at once, and re-training staff in something so foreign would never be economical. D is again particularly interesting here because it's enough like C++ and C# that programmers feel immediately comfortable and somewhat liberated, but not threatened. Also, in a lot of cases, the changes to D are relatively intuitive. The things you expect should work, often just do... but there are still lots of rough edges too. Gaming is a very demanding and progressive field of software, but also very backwards at the same time. It's a sort of unity between many disciplines, and it all comes together under a performance critical and usually embedded umbrella, in a highly competitive and fickle industry. You can't tell the customer to upgrade their hardware when it needs to run on a console with an ~8 year lifecycle. As a (tech/engine) programmer, if you don't scrutinise the code generation, calling conventions, memory access patterns, data layout and sizes, the competition will, and their product will appear superior. Towards the end of that 8 year cycle, programmers are REALLY squeezing these machines. If the language doesn't support that, then you can't compete anymore, hence we remain stuck on C++ (and there are many instances where the industry is reverting to C because C++ is a bloaty pig). Why game devs are interested so much in D is interesting considering the GC is noted to be a problem for game devs. The work of H. S. Teoh comes to mind with his work on a game engine, that pushed the limits of the GC and std lib. I'll admit this is my biggest fear hands down! That said, D is the only GC based language I know if where the GC is relatively optional. This allows us to hedge our bets, and ease in to it slowly as we gain confidence and understanding of how it behaves. I don't yet have much confidence in the GC, and generally avoid using it. I only use it for short term allocations, or non-critical-loop work which often only survive for the scope of the function.

Someone has created GC free versions of Phobos and druntime: http://3d.benjamin-thaut.de/?**p=20#more-20<http://3d.benjamin-thaut.de/?p=20#more-20>

Nice case study! Thanks! Looks like a cool little game too :P
 Was posted here:

 http://forum.dlang.org/thread/**k27bh7$t7f$1 digitalmars.com<http://forum.dlang.org/thread/k27bh7$t7f$1 digitalmars.com>

 --
 /Jacob Carlborg

Nov 20 2012
next sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Tuesday, 20 November 2012 at 09:11:07 UTC, Manu wrote:
 Nice case study! Thanks!
 Looks like a cool little game too :P

Watched the video. Interesting looking game, but how long it was taking to move around the ships gives a sense of size, making me ask myself 'my god, how big IS that ship?'.
Nov 20 2012
parent "DypthroposTheImposter" <mcbracket gmail.com> writes:
  I've used half in C++, although mostly just to feed to the GPU 
since its pretty common that you don't want to waste the 
bandwidth on 32 bit floats.
Nov 20 2012
prev sibling parent "Kagamin" <spam here.lot> writes:
On Tuesday, 20 November 2012 at 09:11:07 UTC, Manu wrote:
 Nice case study! Thanks!
 Looks like a cool little game too :P

AFAIK, tart also has a prototype of realtime GC, but I don't know whether it can solve your problem. Such things are of little priority now for D and general purpose programming, I think.
Nov 20 2012
prev sibling parent "Rob T" <rob ucora.com> writes:
On Monday, 19 November 2012 at 20:28:22 UTC, Rob T wrote:
 The work of H. S. Teoh comes to mind with his work on a game 
 engine, that pushed the limits of the GC and std lib.

Not to undermine the work Teoh has done on D, but I meant Benjamin Thaut is the person who published his findings related to problems encountered with the GC and the std lib. --rt
Nov 19 2012
prev sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis 
wrote:
 On Monday, November 19, 2012 19:57:37 Manu wrote:
 I also wanted to gauge the interest/opposition.

I'd never even _heard_ of half types before this discussion came up. But then again, the same goes for SIMD. [SNIP] - Jonathan M Davis

What I find extremely interesting about D is how easy it is to do extremely low level stuff. ASM? Built-in. SIMD: You don't even realize you're doing it. In C++, you have to jump through flaming loops to get that stuff working. I know where I'd go for my low level needs: Not C or C++ ;) I think it could only benefit D to have the "full low level package in a comprehensive high level language". It's been on a winning run so far anyways (IMO).
Nov 19 2012
prev sibling parent Don Clugston <dac nospam.com> writes:
On 18/11/12 12:21, Manu wrote:
 I've often wondered about having an official 'half' type.
 It's very common in rendering/image processing, supported by most video
 cards (so compression routines interacting with this type are common),
 and it's also supported in hardware by some cpu's.

 ARM for instance supports 'half's in hardware, and GCC has an __fp16
 type which would map nicely if D supported the type in the front end.

 The alternative us to use ushort everywhere, which is awkward, because
 it is neither unsigned, nor is it an integer, and it's not typesafe
 (allows direct assignment to ints and stuff)...
 It would be nice if: cast(half)someFloat would yield the proper value,
 even if it is performed in software in most architectures, it could be
 mapped to hardware for those that do it.

 It could be done in a library, but then GCC couldn't map it properly to
 the hardware type, and since D has no way to describe implicit casts
 (that I know of?) it becomes awkward to use.
 someFloat = someHalf <- doesn't work, because a cast operator expects an
 explicit cast, even though this is a lossless conversion and should be
 exactly the same as someDouble = someFloat.

 Thoughts?

I suspect that what you want in nearly all cases is conversion from half[] <-> float[] ie, a pack/unpack operation. I think it would be quite rare to want to operate on a single half. Although it's supported natively on GPUs, for D's purposes it is more natural to view it as compressed data.
Nov 20 2012