On 19 November 2012 01:08, Robert Jacques <span dir="ltr"><<a href="mailto:sandford@jhu.edu" target="_blank">sandford@jhu.edu</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sun, 18 Nov 2012 05:21:27 -0600, Manu <<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've often wondered about having an official 'half' type.<br>
It'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's also supported in hardware by some cpu's.<br>
<br>
ARM for instance supports 'half's in hardware, and GCC has an __fp16 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<br>
is neither unsigned, nor is it an integer, and it's not typesafe (allows<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't map it properly to the<br>
hardware type, and since D has no way to describe implicit casts (that I<br>
know of?) it becomes awkward to use.<br>
someFloat = someHalf <- doesn'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 = 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>
   CustomFloat!16                                x;     // Using the number of bits<br>
   CustomFloat!(10, 5)                           y;     // Using the precision and exponent width<br>
   CustomFloat!(10, 5,CustomFloatFlags.ieee)     z;     // Using the precision, exponent width and format flags<br>
   CustomFloat!(10, 5,CustomFloatFlags.ieee, 15) w;     // Using the precision, exponent width, format flags and exponent offset bias<br>
<br>
   // Use the 16-bit floats mostly like normal numbers<br>
   w = x*y - 1;<br>
   writeln(w);<br>
<br>
   // Functions calls require conversion<br>
   z = sin(+x)           + cos(+y);                     // Use uniary plus to concisely convert to a real<br>
   z = sin(<a href="http://x.re" target="_blank">x.re</a>)         + cos(<a href="http://y.re" target="_blank">y.re</a>);                   // Or use the .re property to convert to a real<br>
   z = sin(x.get!float)  + cos(y.get!float);            // Or use get!T<br>
   z = sin(cast(float)x) + cos(cast(float)y);           // Or use cast(T) to explicitly convert<br>
<br>
   // Define a 8-bit custom float for storing probabilities<br>
   alias CustomFloat!(4, 4, CustomFloatFlags.ieee^<u></u>CustomFloatFlags.probability^<u></u>CustomFloatFlags.signed ) Probability;<br>
   auto p = Probability(0.5);<br>
</blockquote></div><br></div><div class="gmail_extra">I still can't buy arguments like this. It completely changes the syntax.</div><div class="gmail_extra">If I told you this is how real should be implemented, would you vote ++? What about double? Why?</div>
<div class="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="gmail_extra"><br></div><div class="gmail_extra">
'half' isn't some custom float for niche use, it's an established standard, implemented in vastly more hardware than implements 'real'.</div>