www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - half datatype?

reply Manu <turkeyman gmail.com> writes:
--0016369c8e5ca4237104cec333ac
Content-Type: text/plain; charset=UTF-8

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?

--0016369c8e5ca4237104cec333ac
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I&#39;ve often wondered about having an official &#39;half&#39; type.<div>I=
t&#39;s very common in rendering/image processing, supported by most video =
cards (so compression routines interacting with this type are common), and =
it&#39;s also supported in hardware by some cpu&#39;s.</div>
<div><br></div><div>ARM for instance supports &#39;half&#39;s in hardware, =
and GCC has an __fp16 type which would map nicely if D supported the type i=
n the front end.</div><div><br></div><div>The alternative us to use ushort =
everywhere, which is awkward, because it is neither unsigned, nor is it an =
integer, and it&#39;s not typesafe (allows direct assignment to ints and st=
uff)...</div>
<div>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 map=
ped to hardware for those that do it.</div><div><br></div><div>It could be =
done in a library, but then GCC couldn&#39;t map it properly to the hardwar=
e type, and since D has no way to describe implicit casts (that I know of?)=
 it becomes awkward to use.</div>
<div>someFloat =3D someHalf &lt;- doesn&#39;t work, because a cast operator=
 expects an explicit cast, even though this is a lossless conversion and sh=
ould be exactly the same as someDouble =3D someFloat.</div><div><br></div><=
div>
Thoughts?</div>

--0016369c8e5ca4237104cec333ac--
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 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
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
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 next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b5dbd5c2593ca04cec42ce7
Content-Type: text/plain; charset=UTF-8

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. --047d7b5dbd5c2593ca04cec42ce7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 18 November 2012 14:01, David Nadlinger <span dir=3D"ltr">&lt;<a href=3D= "mailto:see klickverbot.at" target=3D"_blank">see klickverbot.at</a>&gt;</s= pan> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex"> <div class=3D"im">On Sunday, 18 November 2012 at 11:21:37 UTC, Manu wrote:<= br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> someFloat =3D someHalf &lt;- doesn&#39;t work, because a cast operator expe= cts an<br> explicit cast, even though this is a lossless conversion and should be<br> exactly the same as someDouble =3D someFloat.<br> <br></div> Thoughts?<br> </blockquote> <br> ---<br> struct Half {<br> =C2=A0 =C2=A0 float toFloat() { return 3.14f; }<br> =C2=A0 =C2=A0 alias toFloat this;<br> }<br> <br> void test() {<br> =C2=A0 =C2=A0 Half h;<br> =C2=A0 =C2=A0 float f =3D h;<br> =C2=A0 =C2=A0 double d =3D h;<br> }<br> ---<br> <br> Works for you?</blockquote><div><br></div><div>Interesting approach to the = implicit cast problem. Very handy trick.</div></div></div> --047d7b5dbd5c2593ca04cec42ce7--
Nov 18 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf3074b496f3912704cec450e0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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. --20cf3074b496f3912704cec450e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 18 November 2012 14:13, Dmitry Olshansky <span dir=3D"ltr">&lt;<a href= =3D"mailto:dmitry.olsh gmail.com" target=3D"_blank">dmitry.olsh gmail.com</= a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot= e"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"> 11/18/2012 3:21 PM, Manu =D0=BF=D0=B8=D1=88=D0=B5=D1=82:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im"> I&#39;ve often wondered about having an official &#39;half&#39; type.<br> It&#39;s very common in rendering/image processing, supported by most video= <br> cards (so compression routines interacting with this type are common),<br> and it&#39;s also supported in hardware by some cpu&#39;s.<br> <br> ARM for instance supports &#39;half&#39;s in hardware, and GCC has an __fp1= 6<br> type which would map nicely if D supported the type in the front end.<br> <br></div><div class=3D"im"> The alternative us to use ushort everywhere, which is awkward, because<br> it is neither unsigned, nor is it an integer, and it&#39;s not typesafe<br> (allows direct assignment to ints and stuff)...<br></div><div class=3D"im"> It would be nice if: cast(half)someFloat would yield the proper value,<br> even if it is performed in software in most architectures, it could be<br> mapped to hardware for those that do it.<br> </div></blockquote> <br> I guess half(someFloat) will do for conversion.</blockquote><div><br></div>= <div>How do you define &#39;will do&#39;? It still behaves differently than= proper types.</div><div>someFloat =3D someDouble without a cast is a compi= le error, likewise should be true in this case, but I don&#39;t know how to= do that.<br> </div><div>someHalf =3D someFloat should require an explicit cast too, or u= se a 1.0h literal ;)</div><div><br></div><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di= v class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> It could be done in a library, but then GCC couldn&#39;t map it properly to= <br> the hardware type, and since D has no way to describe implicit casts<br> (that I know of?) it becomes awkward to use.<br> </blockquote> <br></div> alias this should work.<br> Just tried it, works wonders:<br> <br> import std.math;<br> <br> struct half{<br> =C2=A0 =C2=A0 ushort data; //this one should be __fp16 where it works<br> //other overloaded ops, etc.<br> <br> =C2=A0 =C2=A0 alias getFloat this;<br> =C2=A0 =C2=A0 //***only for the purpose of showing implicit conversion ***<= br> =C2=A0 =C2=A0 float getFloat(){ return data * 0.1; }<br> }<br> <br> void main(){<br> =C2=A0 =C2=A0 float x =3D half(12);<br> =C2=A0 =C2=A0 assert(abs(x - 1.2) &lt; 1e-6);<div class=3D"im"><br> }<br></div></blockquote><div><br></div><div>Yup, that solves the up-cast pr= oblem perfectly! I didn&#39;t think of that trick.</div><div><br></div><blo= ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= cc solid;padding-left:1ex"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex">someFloat =3D someHalf &lt= ;- doesn&#39;t work, because a cast operator expects an<br> explicit cast, even though this is a lossless conversion and should be<br> exactly the same as someDouble =3D someFloat.<br> <br> Thoughts?<br> </blockquote> <br></div> Everything but hardware support is doable as is. I&#39;m not sure if it&#39= ;s possible and/or feasible to make _efficient_ wrapper type that uses hard= ware support.<br> <br> The easiest path seems to be:<br> - convince GDC to add __fp16 type as an extension that maps to GCC&#39;s on= e<br> - use it on GDC, and fallback to emulation on DMD<br> <br> That being said I personally have no objections to add half type to built-i= ns in DMD.</blockquote><div><br></div><div>I&#39;m sure it&#39;s already ac= cessible in GDC, but it&#39;s not portable unless it gets a proper name in = the front end.</div> <div>The point would be to name the type, add the conversion functions to d= runtime for fallback/portability, and a literal 1.0h would be handy to iden= tify the type to templates.</div></div></div> --20cf3074b496f3912704cec450e0--
Nov 18 2012
prev sibling next 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=

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

 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=



 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=


 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 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
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 "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 Manu <turkeyman gmail.com> writes:
--20cf303b3c111f2b2204cecdc822
Content-Type: text/plain; charset=UTF-8

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

--20cf303b3c111f2b2204cecdc822 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I&#39;m sure that&#39;s true, I&#39;ve just always used it to gain access t= o members of embedded types, kinda of like abstraction for &#39;struct&#39;= s. It hadn&#39;t occurred to me to support explicit casting in that way.<di= v class=3D"gmail_extra"> <br><br><div class=3D"gmail_quote">On 18 November 2012 18:31, Andrei Alexan= drescu <span dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsiteForEmail erdani.or= g" target=3D"_blank">SeeWebsiteForEmail erdani.org</a>&gt;</span> wrote:<br=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=

On 11/18/12 7:30 AM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 18 November 2012 14:01, David Nadlinger &lt;<a href=3D"mailto:see klickv= erbot.at" target=3D"_blank">see klickverbot.at</a><div><div class=3D"h5"><b= r> &lt;mailto:<a href=3D"mailto:see klickverbot.at" target=3D"_blank">see klic= kverbot.at</a>&gt;&gt; wrote:<br> <br> =C2=A0 =C2=A0 On Sunday, 18 November 2012 at 11:21:37 UTC, Manu wrote:<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 someFloat =3D someHalf &lt;- doesn&#39;t work, = because a cast operator<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 expects an<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 explicit cast, even though this is a lossless c= onversion and<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 should be<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 exactly the same as someDouble =3D someFloat.<b= r> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thoughts?<br> <br> <br> =C2=A0 =C2=A0 ---<br> =C2=A0 =C2=A0 struct Half {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0float toFloat() { return 3.14f; }<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alias toFloat this;<br> =C2=A0 =C2=A0 }<br> <br> =C2=A0 =C2=A0 void test() {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Half h;<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0float f =3D h;<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0double d =3D h;<br> =C2=A0 =C2=A0 }<br> =C2=A0 =C2=A0 ---<br> <br> =C2=A0 =C2=A0 Works for you?<br> <br> <br></div></div><div class=3D"im"> Interesting approach to the implicit cast problem. Very handy trick.<br> </div></blockquote> <br> Well that was quite explicitly part of the purpose of alias this.<span clas= s=3D"HOEnZb"><font color=3D"#888888"><br> <br> Andrei<br> </font></span></blockquote></div><br></div> --20cf303b3c111f2b2204cecdc822--
Nov 18 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7bdc0aba5bcb9804cece3ba5
Content-Type: text/plain; charset=UTF-8

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?

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'. --047d7bdc0aba5bcb9804cece3ba5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 19 November 2012 01:08, Robert Jacques <span dir=3D"ltr">&lt;<a href=3D"= mailto:sandford jhu.edu" target=3D"_blank">sandford jhu.edu</a>&gt;</span> = wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex"> <div class=3D"im">On Sun, 18 Nov 2012 05:21:27 -0600, Manu &lt;<a href=3D"m= ailto:turkeyman gmail.com" target=3D"_blank">turkeyman gmail.com</a>&gt; wr= ote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I&#39;ve often wondered about having an official &#39;half&#39; type.<br> It&#39;s very common in rendering/image processing, supported by most video= <br> cards (so compression routines interacting with this type are common), and<= br> it&#39;s also supported in hardware by some cpu&#39;s.<br> <br> ARM for instance supports &#39;half&#39;s in hardware, and GCC has an __fp1= 6 type<br> which would map nicely if D supported the type in the front end.<br> <br> The alternative us to use ushort everywhere, which is awkward, because it<b= r> is neither unsigned, nor is it an integer, and it&#39;s not typesafe (allow= s<br> direct assignment to ints and stuff)...<br> It would be nice if: cast(half)someFloat would yield the proper value, even= <br> if it is performed in software in most architectures, it could be mapped to= <br> hardware for those that do it.<br> <br> It could be done in a library, but then GCC couldn&#39;t map it properly to= the<br> hardware type, and since D has no way to describe implicit casts (that I<br=

someFloat =3D someHalf &lt;- doesn&#39;t work, because a cast operator expe= cts an<br> explicit cast, even though this is a lossless conversion and should be<br> exactly the same as someDouble =3D someFloat.<br> <br> Thoughts?<br> <br> </blockquote> <br></div> Vote--.<br> <br> The a half data type is already part of std.numeric. From the docs:<br> <br> // Define a 16-bit floating point values<br> =C2=A0 =C2=A0CustomFloat!16 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0x; =C2=A0= =C2=A0 // Using the number of bits<br> =C2=A0 =C2=A0CustomFloat!(10, 5) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 y; =C2=A0 =C2=A0 // Using = the precision and exponent width<br> =C2=A0 =C2=A0CustomFloat!(10, 5,CustomFloatFlags.ieee) =C2=A0 =C2=A0 z; =C2= =A0 =C2=A0 // Using the precision, exponent width and format flags<br> =C2=A0 =C2=A0CustomFloat!(10, 5,CustomFloatFlags.ieee, 15) w; =C2=A0 =C2=A0= // Using the precision, exponent width, format flags and exponent offset b= ias<br> <br> =C2=A0 =C2=A0// Use the 16-bit floats mostly like normal numbers<br> =C2=A0 =C2=A0w =3D x*y - 1;<br> =C2=A0 =C2=A0writeln(w);<br> <br> =C2=A0 =C2=A0// Functions calls require conversion<br> =C2=A0 =C2=A0z =3D sin(+x) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 + cos(+y); = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Us= e uniary plus to concisely convert to a real<br> =C2=A0 =C2=A0z =3D sin(<a href=3D"http://x.re" target=3D"_blank">x.re</a>) = =C2=A0 =C2=A0 =C2=A0 =C2=A0 + cos(<a href=3D"http://y.re" target=3D"_blank"=
y.re</a>); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =

=C2=A0 =C2=A0z =3D sin(x.get!float) =C2=A0+ cos(y.get!float); =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0// Or use get!T<br> =C2=A0 =C2=A0z =3D sin(cast(float)x) + cos(cast(float)y); =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 // Or use cast(T) to explicitly convert<br> <br> =C2=A0 =C2=A0// Define a 8-bit custom float for storing probabilities<br> =C2=A0 =C2=A0alias CustomFloat!(4, 4, CustomFloatFlags.ieee^<u></u>CustomFl= oatFlags.probability^<u></u>CustomFloatFlags.signed ) Probability;<br> =C2=A0 =C2=A0auto p =3D Probability(0.5);<br> </blockquote></div><br></div><div class=3D"gmail_extra">I still can&#39;t b= uy arguments like this. It completely changes the syntax.</div><div class= =3D"gmail_extra">If I told you this is how real should be implemented, woul= d you vote ++? What about double? Why?</div> <div class=3D"gmail_extra">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...</div><div class=3D"gmail_extra"><br></div><div = class=3D"gmail_extra"> &#39;half&#39; isn&#39;t some custom float for niche use, it&#39;s an estab= lished standard, implemented in vastly more hardware than implements &#39;r= eal&#39;.</div> --047d7bdc0aba5bcb9804cece3ba5--
Nov 18 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--0016369c8e5cf7672004cece3f35
Content-Type: text/plain; charset=UTF-8

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


--0016369c8e5cf7672004cece3f35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 19 November 2012 01:58, Manu <span dir=3D"ltr">&lt;<a href=3D"mailto:tur= keyman gmail.com" target=3D"_blank">turkeyman gmail.com</a>&gt;</span> wrot= e:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote cla= ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa= dding-left:1ex"> I&#39;m sure that&#39;s true, I&#39;ve just always used it to gain access t= o members of embedded types, kinda of like abstraction for &#39;struct&#39;= s. It hadn&#39;t occurred to me to support explicit casting in that way.</b= lockquote> <div><br></div><div>**cough** IMPLICIT casting.=C2=A0</div><div><br></div><= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5"><div = class=3D"gmail_extra"> On 18 November 2012 18:31, Andrei Alexandrescu <span dir=3D"ltr">&lt;<a hre= f=3D"mailto:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeWebsiteForE= mail erdani.org</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"> On 11/18/12 7:30 AM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 18 November 2012 14:01, David Nadlinger &lt;<a href=3D"mailto:see klickv= erbot.at" target=3D"_blank">see klickverbot.at</a><div><div><br> &lt;mailto:<a href=3D"mailto:see klickverbot.at" target=3D"_blank">see klic= kverbot.at</a>&gt;&gt; wrote:<br> <br> =C2=A0 =C2=A0 On Sunday, 18 November 2012 at 11:21:37 UTC, Manu wrote:<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 someFloat =3D someHalf &lt;- doesn&#39;t work, = because a cast operator<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 expects an<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 explicit cast, even though this is a lossless c= onversion and<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 should be<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 exactly the same as someDouble =3D someFloat.<b= r> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thoughts?<br> <br> <br> =C2=A0 =C2=A0 ---<br> =C2=A0 =C2=A0 struct Half {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0float toFloat() { return 3.14f; }<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alias toFloat this;<br> =C2=A0 =C2=A0 }<br> <br> =C2=A0 =C2=A0 void test() {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Half h;<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0float f =3D h;<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0double d =3D h;<br> =C2=A0 =C2=A0 }<br> =C2=A0 =C2=A0 ---<br> <br> =C2=A0 =C2=A0 Works for you?<br> <br> <br></div></div><div> Interesting approach to the implicit cast problem. Very handy trick.<br> </div></blockquote> <br> Well that was quite explicitly part of the purpose of alias this.<span><fon= t color=3D"#888888"><br> <br> Andrei</font></span></blockquote></div></div> </div></div></blockquote></div><br></div> --0016369c8e5cf7672004cece3f35--
Nov 18 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7bdc09ee54e1f804cedb47e9
Content-Type: text/plain; charset=UTF-8

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. --047d7bdc09ee54e1f804cedb47e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 19 November 2012 06:19, Walter Bright <span dir=3D"ltr">&lt;<a href=3D"m= ailto:newshound2 digitalmars.com" target=3D"_blank">newshound2 digitalmars.= com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail= _quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div class=3D"im">On 11/18/2012 4:31 PM, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> If I told you this is how real should be implemented, would you vote ++? Wh= at<br> about double? Why?<br> Why not float for that matter? There seems like no reason for the language = to<br> define any floating point type at all if you consider this acceptable...<br=

<br></div> Because they are implemented in hardware. It&#39;s pretty dang hard for a c= ompiler to look at a floating point emulator and figure out &quot;gee, I ha= ve a nice hardware instruction that does the same thing as this 2K of code!= &quot;</blockquote> <div><br></div><div>Right, and this is my point precisely. It&#39;s hard fo= r GDC for instance to hook some complex library because it happens to have = hardware to do it.</div><div><br></div><blockquote class=3D"gmail_quote" st= yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb= (204,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> &#39;half&#39; isn&#39;t some custom float for niche use, it&#39;s an estab= lished standard,<br> implemented in vastly more hardware than implements &#39;real&#39;.<br> </blockquote> <br></div> It&#39;s implemented in GPUs, sure, but it is it implemented in hardware th= at D runs on? (I do know about this: <a href=3D"http://gcc.gnu.org/onlinedo= cs/gcc/Half_002dPrecision.html" target=3D"_blank">http://gcc.gnu.org/online= docs/<u></u>gcc/Half_002dPrecision.html</a>)<br> <br> There is no major technical difficulty in implementing it as a basic type, = but I want to be sure we&#39;ve exhausted the library approach first.<br> </blockquote></div><br></div><div class=3D"gmail_extra">Well it&#39;s avail= able in hardware on basically all mobile devices (that&#39;s a LOT of devic= es (in the billions)), but even if it&#39;s just implemented in software (x= 86), 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 shoul= dn&#39;t it enjoy the same casting, assignment, literal, range checking rul= es as the rest of the floats? Additionally, convenience and compatibility w= ith generic code would be significantly improved.<br> </div><div class=3D"gmail_extra">I don&#39;t see how it can be made to feel= seamless with a lib... and that sounds like an awful lot more work.</div><= div class=3D"gmail_extra"><div class=3D"gmail_extra"><br></div></div><div c= lass=3D"gmail_extra"> <div class=3D"gmail_extra"><br></div></div><div class=3D"gmail_extra">Anywa= y, I&#39;m not desperate for this personally. I just wondered how people fe= lt about it in general, and if it was something that should/would be seriou= sly considered.</div> --047d7bdc09ee54e1f804cedb47e9--
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:
--047d7bdc0aba51b61a04cedcdadf
Content-Type: text/plain; charset=UTF-8

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>

 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



 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


 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


 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


 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

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

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

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

 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. --047d7bdc0aba51b61a04cedcdadf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 19 November 2012 19:28, Iain Buclaw <span dir=3D"ltr">&lt;<a href=3D"mai= lto:ibuclaw ubuntu.com" target=3D"_blank">ibuclaw ubuntu.com</a>&gt;</span>= wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On 19 November 2012 16:04, Manu &lt= ;<a href=3D"mailto:turkeyman gmail.com">turkeyman gmail.com</a>&gt; wrote:<= br> &gt; On 19 November 2012 06:19, Walter Bright &lt;<a href=3D"mailto:newshou= nd2 digitalmars.com">newshound2 digitalmars.com</a>&gt; wrote:<br> &gt;&gt;<br> &gt;&gt; On 11/18/2012 4:31 PM, Manu wrote:<br> &gt;&gt;&gt;<br> &gt;&gt;&gt; If I told you this is how real should be implemented, would yo= u vote ++?<br> &gt;&gt;&gt; What<br> &gt;&gt;&gt; about double? Why?<br> &gt;&gt;&gt; Why not float for that matter? There seems like no reason for = the<br> &gt;&gt;&gt; language to<br> &gt;&gt;&gt; define any floating point type at all if you consider this acc= eptable...<br> &gt;&gt;<br> &gt;&gt;<br> &gt;&gt; Because they are implemented in hardware. It&#39;s pretty dang har= d for a<br> &gt;&gt; compiler to look at a floating point emulator and figure out &quot= ;gee, I have a<br> &gt;&gt; nice hardware instruction that does the same thing as this 2K of c= ode!&quot;<br> &gt;<br> &gt;<br> &gt; Right, and this is my point precisely. It&#39;s hard for GDC for insta= nce to<br> &gt; hook some complex library because it happens to have hardware to do it= .<br> &gt;<br> &gt;&gt;&gt; &#39;half&#39; isn&#39;t some custom float for niche use, it&#= 39;s an established<br> &gt;&gt;&gt; standard,<br> &gt;&gt;&gt; implemented in vastly more hardware than implements &#39;real&= #39;.<br> &gt;&gt;<br> &gt;&gt;<br> &gt;&gt; It&#39;s implemented in GPUs, sure, but it is it implemented in ha= rdware that<br> &gt;&gt; D runs on? (I do know about this:<br> &gt;&gt; <a href=3D"http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.ht= ml" target=3D"_blank">http://gcc.gnu.org/onlinedocs/gcc/Half_002dPrecision.= html</a>)<br> &gt;&gt;<br> &gt;&gt; There is no major technical difficulty in implementing it as a bas= ic type,<br> &gt;&gt; but I want to be sure we&#39;ve exhausted the library approach fir= st.<br> &gt;<br> &gt;<br> &gt; Well it&#39;s available in hardware on basically all mobile devices (t= hat&#39;s a<br> &gt; LOT of devices (in the billions)), but even if it&#39;s just implement= ed in<br> &gt; software (x86), the values are consumed by the GPU, and the validity o= f the<br> &gt; values is no less important. It still seems like a valuable 1st class = type;<br> &gt; why shouldn&#39;t it enjoy the same casting, assignment, literal, rang= e checking<br> &gt; rules as the rest of the floats? Additionally, convenience and compati= bility<br> &gt; with generic code would be significantly improved.<br> &gt; I don&#39;t see how it can be made to feel seamless with a lib... and = that<br> &gt; sounds like an awful lot more work.<br> &gt;<br> &gt;<br> &gt; Anyway, I&#39;m not desperate for this personally. I just wondered how= people<br> &gt; felt about it in general, and if it was something that should/would be= <br> &gt; seriously considered.<br> <br> </div></div>I&#39;m neither here nor there. =C2=A0I&#39;m just pointing out= that you are<br> proposing a dedicated type to be introduced that is supported on only<br> one platform. :-)<br></blockquote><div><br></div><div>real is only supporte= d on one platform (x86, it&#39;s deprecated in x64 and x87 will likely be r= emoved/emulated in the future), but I think many here consider it valuable(= ?).</div> <div>And that&#39;s not strictly true either, virtually every machine has a= GPU, and host software still has to process data for it. I&#39;m mainly en= couraging this for the sake of correctness/type safety, though hardware sup= port on ARM would be a particularly nice bonus.</div> <div><br></div><div>I also wanted to gauge the interest/opposition.</div></= div></div> --047d7bdc0aba51b61a04cedcdadf--
Nov 19 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 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
prev sibling parent 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
prev sibling next sibling parent "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
prev sibling next 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 next 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 Manu <turkeyman gmail.com> writes:
--20cf3074b496253fa204cee28c50
Content-Type: text/plain; charset=UTF-8

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. --20cf3074b496253fa204cee28c50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 19 November 2012 22:28, Rob T <span dir=3D"ltr">&lt;<a href=3D"mailto:ro= b ucora.com" target=3D"_blank">rob ucora.com</a>&gt;</span> wrote:<br><div = class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail= _quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left= -color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D""><div class=3D"h5">On Monday, 19 November 2012 at 19:14:43 U= TC, Jonathan M Davis wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> I&#39;d never even _heard_ of half types before this discussion came up. Bu= t then<br> again, the same goes for SIMD. And IIRC, there was some sort of function<br=

br> person was insisting on a while back, and I&#39;d never heard of it existin= g in<br> C++ either (as an extension or otherwise). You clearly program in a very<br=

r> nothing on _that_ level. I suspect that this is another one of those things= <br> that certain folks would really like to have, and most of the rest of us do= n&#39;t<br> have any real interest in and often know nothing about in the first place. = I<br> don&#39;t know that I really care whether it&#39;s added to the language th= ough. I&#39;ll<br> leave that sort of decision up to Walter.<br> <br> If anything, I just find it interesting how many low level things folks lik= e<br> you keep coming up with as must-haves or very strong wants that I&#39;ve ne= ver<br> even heard of and will almost certainly never care about aside perhaps from= <br> how having them in D might help D catch on.<br> <br> - Jonathan M Davis<br> </blockquote> <br></div></div> Anyone interested in the low precision float types, and what they are good = for, can start here<br> <a href=3D"http://www.opengl.org/wiki/Small_Float_Formats" target=3D"_blank= ">http://www.opengl.org/wiki/<u></u>Small_Float_Formats</a><br> <br> 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 imag= e processing.<br> <br> When I first started investigating D as a potential C++ replacement, I note= d that a lot of the &quot;visible&quot; 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&#39;s perhaps something = about D that they find attractive.<br> </blockquote><div><br></div><div>I&#39;ve said it before, but I think D has= MASSIVE potential in gaming. We are an industry crying our for salvation f= rom C++, but there&#39;s no possibility to compromise on the level of acces= s it provides us to the hardware we work with.</div> <div>D is the only language I know of that seriously threatens to offer mod= ern programming constructs, while still providing a syntax and compiler tec= hnology that I can easily understand in terms of code generation and can hi= t the metal when I need to.</div> <div><br></div><div>Additionally, most games programmers have very long-ter= m relationships with C++ almost exclusively, so despite hating it, moving t= o something utterly different like rust or whatever cool thing comes along = will just never fly. You&#39;ll never convince a team of 10-30 programmers = to agree on such a change all at once, and re-training staff in something s= o foreign would never be economical.</div> <div>D is again particularly interesting here because it&#39;s enough like = C++ and C# that programmers feel immediately comfortable and somewhat liber= ated, but not threatened. Also, in a lot of cases, the changes to D are rel= atively intuitive. The things you expect should work, often just do... but = there are still lots of rough edges too.</div> <div><br></div><div>Gaming is a very demanding and progressive field of sof= tware, but also very backwards at the same time. It&#39;s a sort of unity b= etween many disciplines, and it all comes together under a performance crit= ical and usually embedded umbrella, in a highly competitive and=C2=A0fickle= =C2=A0industry.</div> <div>You can&#39;t tell the customer to upgrade their hardware when it need= s to run on a console with an ~8 year lifecycle. As a (tech/engine) program= mer, if you don&#39;t scrutinise the code generation, calling conventions, = memory access patterns, data layout and sizes, the competition will, and th= eir product will appear superior. Towards the end of that 8 year cycle, pro= grammers are REALLY squeezing these machines. If the language doesn&#39;t s= upport that, then you can&#39;t compete anymore, hence we remain stuck on C= ++ (and there are many instances where the industry is reverting to C becau= se C++ is a bloaty pig).</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef= t-style:solid;padding-left:1ex">Why game devs are interested so much in D i= s interesting considering the GC is noted to be a problem for game devs. Th= e work of H. S. Teoh comes to mind with his work on a game engine, that pus= hed the limits of the GC and std lib.<br> </blockquote><div><br></div><div>I&#39;ll admit this is my biggest fear han= ds down!</div><div>That said,=C2=A0D is the only GC based language I know i= f where the GC is relatively optional. This allows us to hedge our bets, an= d ease in to it slowly as we gain confidence and understanding of how it be= haves.</div> <div>I don&#39;t yet have=C2=A0much=C2=A0confidence in the GC, and generall= y 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.</div><di= v><br> </div><div>I don&#39;t have enough experience to make any reasonable claims= about its affect on performance, but=C2=A0I have seen a lot of benchmarks = in this NG though that have shown it is significantly inferior to C# and Ja= va. That doesn&#39;t fill me with confidence.</div> <div>I do hope work is done to make it at least competitive with java/C#&#3= 9;s GC, and then we&#39;ll see where we stand. C#&#39;s GC is proven to be = acceptable in at least smaller/independent games. It&#39;s probably still n= ot acceptable on major AAA console titles though. We need thread-local coll= ection... it can&#39;t stop the world to do a collect, and I wouldn&#39;t a= fford more than 1ms at any given time (and I think that&#39;s even being ge= nerous). Perhaps incremental collection where it would stop after it reache= s its allocated time budget or something?<br> </div><div><br></div><div>So my working theory is, if the GC were limited t= o relatively few &#39;convenience allocations&#39; and the bulk of memory w= as still managed manually, maybe that will lift the load to the point that = the cost is insignificant, and it will be a useful tool...?</div> <div>But yes, for the moment, we use malloc and emplace.<br></div><div><br>= </div><div>I think this will mature only with experience and it&#39;ll help= if there are receptive ears to our needs. It&#39;s impossible for us to co= mplain to the C# guys about the habits of their GC and expect anyone to car= e. This community offers options.</div> <div>We don&#39;t HATE garbage collection, we just can&#39;t generally affo= rd it.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204= );border-left-style:solid;padding-left:1ex"> =C2=A0In any case, the point is that I don&#39;t think the D community shou= ld overlook what the game devs are doing, they&#39;re pushing D to its limi= ts and are making D more visible than perhaps anyone.</blockquote><div><br>= </div> <div>This is about the only thing of significance I think we can hope to of= fer back to the community. If we can use it successfully in a major commerc= ial game, then tell the story afterwards, I think that could bring a lot of= new interest. I hope we are able to do that.</div> <div>I think maturity is reaching the point where people can realistically = start to consider taking a risk with it.</div><div><br></div><div>I&#39;d l= ove to see more movement on the android/ios front, I reckon there&#39;s a l= ot more immediate potential in that space given that it&#39;s a lot less ri= sky and the bar isn&#39;t as high.</div> </div></div> --20cf3074b496253fa204cee28c50--
Nov 19 2012
prev sibling 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 next 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 next sibling parent Manu <turkeyman gmail.com> writes:
--00032556269e9d239504cee2f0ae
Content-Type: text/plain; charset=UTF-8

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

 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. --00032556269e9d239504cee2f0ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 20 November 2012 02:51, Jonathan M Davis <span dir=3D"ltr">&lt;<a href= =3D"mailto:jmdavisProg gmx.com" target=3D"_blank">jmdavisProg gmx.com</a>&g= t;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex"> <div class=3D""><div class=3D"h5">On Monday, November 19, 2012 12:55:11 Wal= ter Bright wrote:<br> &gt; On 11/19/2012 12:28 PM, Rob T wrote:<br> &gt; &gt; In any case, the point is that I don&#39;t think the D community = should<br> &gt; &gt; overlook what the game devs are doing, they&#39;re pushing D to i= ts limits<br> &gt; &gt; and are making D more visible than perhaps anyone.<br> &gt;<br> &gt; I agree.<br> &gt;<br> &gt; I might also point out that adoption of a language (or any new technol= ogy)<br> &gt; often happens because it solves a problem for an otherwise overlooked<= br> &gt; niche, and their adoption of it drives it into the mainstream.<br> <br> </div></div>I don&#39;t disagree at all. I just find it interesting how man= y things that the<br> game devs keep coming up with that they consider critical that most of the<= br> rest of us haven&#39;t ever even considered and frequently know absolutely = nothing<br> about.<br></blockquote><div><br></div><div>Dunno what to tell you.</div><di= v>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 bet= ween them is an interesting problem in its self.</div> <div>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 dis= lodge C/C++, and it&#39;s not far off.<br></div></div></div> --00032556269e9d239504cee2f0ae--
Nov 19 2012
prev sibling next 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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf303b3c118db81e04cee99c61
Content-Type: text/plain; charset=UTF-8

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

--20cf303b3c118db81e04cee99c61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 20 November 2012 09:41, Jacob Carlborg <span dir=3D"ltr">&lt;<a href=3D"= mailto:doob me.com" target=3D"_blank">doob me.com</a>&gt;</span> wrote:<br>= <div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"> On 2012-11-20 01:45, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 19 November 2012 22:28, Rob T &lt;<a href=3D"mailto:rob ucora.com" targe= t=3D"_blank">rob ucora.com</a> &lt;mailto:<a href=3D"mailto:rob ucora.com" = target=3D"_blank">rob ucora.com</a>&gt;&gt;<div><div class=3D"h5"><br> wrote:<br> <br> =C2=A0 =C2=A0 On Monday, 19 November 2012 at 19:14:43 UTC, Jonathan M Davis= wrote:<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 I&#39;d never even _heard_ of half types before= this discussion came<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 up. But then<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 again, the same goes for SIMD. And IIRC, there = was some sort of<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 function<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 attribute relating to pointers and registers th= at you or some<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 other gaming<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 person was insisting on a while back, and I&#39= ;d never heard of it<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 existing in<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 C++ either (as an extension or otherwise). You = clearly program<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 in a very<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 different world than I do. I care about high pe= rformance in what<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 I do but<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 nothing on _that_ level. I suspect that this is= another one of<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 those things<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 that certain folks would really like to have, a= nd most of the<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 rest of us don&#39;t<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 have any real interest in and often know nothin= g about in the<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 first place. I<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 don&#39;t know that I really care whether it&#3= 9;s added to the language<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 though. I&#39;ll<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 leave that sort of decision up to Walter.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 If anything, I just find it interesting how man= y low level<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 things folks like<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 you keep coming up with as must-haves or very s= trong wants that<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 I&#39;ve never<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 even heard of and will almost certainly never c= are about aside<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 perhaps from<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 how having them in D might help D catch on.<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Jonathan M Davis<br> <br> <br> =C2=A0 =C2=A0 Anyone interested in the low precision float types, and what = they<br> =C2=A0 =C2=A0 are good for, can start here<br></div></div> =C2=A0 =C2=A0 <a href=3D"http://www.opengl.org/wiki/__Small_Float_Formats" = target=3D"_blank">http://www.opengl.org/wiki/__<u></u>Small_Float_Formats</= a><div class=3D"im"><br> =C2=A0 =C2=A0 &lt;<a href=3D"http://www.opengl.org/wiki/Small_Float_Formats= " target=3D"_blank">http://www.opengl.org/wiki/<u></u>Small_Float_Formats</= a>&gt;<br> <br> =C2=A0 =C2=A0 I did not read through all of this thread, but my guess is th= at the<br> =C2=A0 =C2=A0 people making the request for half float are mostly into game= <br> =C2=A0 =C2=A0 development and image processing.<br> <br> =C2=A0 =C2=A0 When I first started investigating D as a potential C++ repla= cement,<br> =C2=A0 =C2=A0 I noted that a lot of the &quot;visible&quot; development (wh= at I could see<br> =C2=A0 =C2=A0 being publicized) was game development, so it seemed that for= some<br> =C2=A0 =C2=A0 reason a lot of the D users were also game developers, so the= re&#39;s<br> =C2=A0 =C2=A0 perhaps something about D that they find attractive.<br> <br> <br></div><div><div class=3D"h5"> I&#39;ve said it before, but I think D has MASSIVE potential in gaming. We<= br> are an industry crying our for salvation from C++, but there&#39;s no<br> possibility to compromise on the level of access it provides us to the<br> hardware we work with.<br> D is the only language I know of that seriously threatens to offer<br> modern programming constructs, while still providing a syntax and<br> compiler technology that I can easily understand in terms of code<br> generation and can hit the metal when I need to.<br> <br> Additionally, most games programmers have very long-term relationships<br> with C++ almost exclusively, so despite hating it, moving to something<br> utterly different like rust or whatever cool thing comes along will just<br=

n<br> such a change all at once, and re-training staff in something so foreign<br=

D is again particularly interesting here because it&#39;s enough like C++<b= r> and C# that programmers feel immediately comfortable and somewhat<br> liberated, but not threatened. Also, in a lot of cases, the changes to D<br=

do... but there are still lots of rough edges too.<br> <br> Gaming is a very demanding and progressive field of software, but also<br> very backwards at the same time. It&#39;s a sort of unity between many<br> disciplines, and it all comes together under a performance critical and<br> usually embedded umbrella, in a highly competitive and fickle industry.<br> You can&#39;t tell the customer to upgrade their hardware when it needs to<= br> run on a console with an ~8 year lifecycle. As a (tech/engine)<br> programmer, if you don&#39;t scrutinise the code generation, calling<br> conventions, memory access patterns, data layout and sizes, the<br> competition will, and their product will appear superior. Towards the<br> end of that 8 year cycle, programmers are REALLY squeezing these<br> machines. If the language doesn&#39;t support that, then you can&#39;t comp= ete<br> anymore, hence we remain stuck on C++ (and there are many instances<br> where the industry is reverting to C because C++ is a bloaty pig).<br> <br></div></div><div class=3D"im"> =C2=A0 =C2=A0 Why game devs are interested so much in D is interesting cons= idering<br> =C2=A0 =C2=A0 the GC is noted to be a problem for game devs. The work of H.= S.<br> =C2=A0 =C2=A0 Teoh comes to mind with his work on a game engine, that pushe= d the<br> =C2=A0 =C2=A0 limits of the GC and std lib.<br> <br> <br></div><div class=3D"im"> I&#39;ll admit this is my biggest fear hands down!<br> That said, D is the only GC based language I know if where the GC is<br> relatively optional. This allows us to hedge our bets, and ease in to it<br=

I don&#39;t yet have much confidence in the GC, and generally avoid using<b= r> it. I only use it for short term allocations, or non-critical-loop work<br> which often only survive for the scope of the function.<br> </div></blockquote> <br> Someone has created GC free versions of Phobos and druntime:<br> <br> <a href=3D"http://3d.benjamin-thaut.de/?p=3D20#more-20" target=3D"_blank">h= ttp://3d.benjamin-thaut.de/?<u></u>p=3D20#more-20</a></blockquote><div><br>= </div><div>Nice case study! Thanks!</div><div>Looks like a cool little game= too :P</div> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex">Was posted here:<br> <br> <a href=3D"http://forum.dlang.org/thread/k27bh7$t7f$1 digitalmars.com" targ= et=3D"_blank">http://forum.dlang.org/thread/<u></u>k27bh7$t7f$1 digitalmars= .com</a><span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> /Jacob Carlborg<br> </font></span></blockquote></div><br></div> --20cf303b3c118db81e04cee99c61--
Nov 20 2012
prev sibling next sibling parent "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
prev sibling next sibling 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