half datatype?

[Manu]

On 19 November 2012 01:08, Robert Jacques <sandford at jhu.edu> wrote:

> On Sun, 18 Nov 2012 05:21:27 -0600, Manu <turkeyman at gmail.com> wrote:
>
>  I've often wondered about having an official 'half' type.
>> It's very common in rendering/image processing, supported by most video
>> cards (so compression routines interacting with this type are common), and
>> it's also supported in hardware by some cpu's.
>>
>> ARM for instance supports 'half's in hardware, and GCC has an __fp16 type
>> which would map nicely if D supported the type in the front end.
>>
>> The alternative us to use ushort everywhere, which is awkward, because it
>> is neither unsigned, nor is it an integer, and it's not typesafe (allows
>> direct assignment to ints and stuff)...
>> It would be nice if: cast(half)someFloat would yield the proper value,
>> even
>> if it is performed in software in most architectures, it could be mapped
>> to
>> hardware for those that do it.
>>
>> It could be done in a library, but then GCC couldn't map it properly to
>> the
>> hardware type, and since D has no way to describe implicit casts (that I
>> know of?) it becomes awkward to use.
>> someFloat = someHalf <- doesn't work, because a cast operator expects an
>> explicit cast, even though this is a lossless conversion and should be
>> exactly the same as someDouble = someFloat.
>>
>> Thoughts?
>>
>>
> Vote--.
>
> The a half data type is already part of std.numeric. From the docs:
>
> // Define a 16-bit floating point values
>    CustomFloat!16                                x;     // Using the
> number of bits
>    CustomFloat!(10, 5)                           y;     // Using the
> precision and exponent width
>    CustomFloat!(10, 5,CustomFloatFlags.ieee)     z;     // Using the
> precision, exponent width and format flags
>    CustomFloat!(10, 5,CustomFloatFlags.ieee, 15) w;     // Using the
> precision, exponent width, format flags and exponent offset bias
>
>    // Use the 16-bit floats mostly like normal numbers
>    w = x*y - 1;
>    writeln(w);
>
>    // Functions calls require conversion
>    z = sin(+x)           + cos(+y);                     // Use uniary plus
> to concisely convert to a real
>    z = sin(x.re)         + cos(y.re);                   // Or use the .re
> property to convert to a real
>    z = sin(x.get!float)  + cos(y.get!float);            // Or use get!T
>    z = sin(cast(float)x) + cos(cast(float)y);           // Or use cast(T)
> to explicitly convert
>
>    // Define a 8-bit custom float for storing probabilities
>    alias CustomFloat!(4, 4, CustomFloatFlags.ieee^**
> CustomFloatFlags.probability^**CustomFloatFlags.signed ) Probability;
>    auto p = Probability(0.5);
>

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

'half' isn't some custom float for niche use, it's an established standard,
implemented in vastly more hardware than implements 'real'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121119/f7641c8c/attachment-0001.html>