half datatype?

[Iain Buclaw]

On 19 November 2012 17:57, Manu <turkeyman at gmail.com> wrote:
> On 19 November 2012 19:28, Iain Buclaw <ibuclaw at ubuntu.com> wrote:
>>
>> On 19 November 2012 16:04, Manu <turkeyman at gmail.com> wrote:
>> > On 19 November 2012 06:19, Walter Bright <newshound2 at 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';