Re: half datatype?

[Zoadian]

+1

i'm using halffloat regularly, would be nice to have them builtin.

Re: half datatype?

[ponce]

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?

Re: half datatype?

[David Nadlinger]

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

Re: half datatype?

[Dmitry Olshansky]

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

Re: half datatype?

[Manu]

On 18 November 2012 14:01, David Nadlinger  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.

Re: half datatype?

[Manu]

On 18 November 2012 14:13, Dmitry Olshansky  wrote:

> 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.


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 ;)

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);
>
> }
>

Yup, that solves the up-cast problem perfectly! I didn't think of that
trick.

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.


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.

Re: half datatype?

[Artur Skawina]

On 11/18/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?

   version (GNU) alias half = @gcc[mode(HF)] float;

But of course this won't work right now, cause that kind of type attributes
aren't supported yet. 'pragma' can't be used on types either (otherwise
something like "alias half = pragma(attribute, mode("HF")) float;" could be
made to work).

And - yes - the /proper/ way would be eg
   
   alias half = @core[size=2] float; 
 // or '@core.size(2)' or any other syntax.

For now, a struct + alias-this-getter might be enough, for a s/w implementation.

artur

Re: half datatype?

[Manu]

On 18 November 2012 14:51, Artur Skawina  wrote:

> On 11/18/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?
>
>version (GNU) alias half = @gcc[mode(HF)] float;
>
> But of course this won't work right now, cause that kind of type attributes
> aren't supported yet. 'pragma' can't be used on types either (otherwise
> something like "alias half = pragma(attribute, mode("HF")) float;" could be
> made to work).
>
> And - yes - the /proper/ way would be eg
>
>alias half = @core[size=2] float;
>  // or '@core.size(2)' or any other syntax.
>
> For now, a struct + alias-this-getter might be enough, for a s/w
> implementation.
>

Yes, that's what I and everyone else does, but that's not the point of the
topic...
I think it's a fundamental datatype, and it deserves the same casting/type
conversion/type safety rules as ints and floats, and it would also be
useful to map it to hardware (which GDC can easily do).

Re: half datatype?

[Dmitry Olshansky]

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

Re: half datatype?

[Artur Skawina]

On 11/18/12 13:58, Manu wrote:
> On 18 November 2012 14:51, Artur Skawina  > wrote:
> 
> On 11/18/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?
> 
>version (GNU) alias half = @gcc[mode(HF)] float;
> 
> But of course this won't work right now, cause that kind of type 
> attributes
> aren't supported yet. 'pragma' can't be used on types either (otherwise
> something like "alias half = pragma(attribute, mode("HF")) float;" could 
> be
> made to work).
> 
> And - yes - the /proper/ way would be eg
> 
>alias half = @core[size=2] float;
>  // or '@core.size(2)' or any other syntax.
> 
> For now, a struct + alias-this-getter might be enough, for a s/w 
> implementation.
> 
> 
> Yes, that's what I and everyone else does, but that's not the point of the 
> topic...
> I think it's a fundamental datatype, and it deserves the same casting/type 
> conversion/type safety rules as ints and floats, and it would also be useful 
> to map it to hardware (which GDC can easily do).

All of the 'half' definitions above would give you a 'fundamental' datatype --
-- there is no reason to make it a /language/-defined type. The work required
to implement things like implicit conversions can be done more generically;
right now the problem is the lack of a way to define such types.

   alias fp24 = @core[exp=7, mant=16] float; // It's only a matter of time until
 // someone asks for it&co...   
   

Also, *every* user- (or in this case more likely lib-) defined data type 
deserves
the same control over casting and conversions as built-in types. No, D doesn't
have that and yes - it is a problem.

I actually think these types /should/ be done as structs, but
a) it isn't currently possible (also for reasons other than the above mentioned 
ones)
and
b) such aliases would /still/ be useful for mapping to "magic" 
compiler-supported
   h/w types. 

artur

Re: half datatype?

[Manu]

On 18 November 2012 16:33, Artur Skawina  wrote:

> On 11/18/12 13:58, Manu wrote:
> > On 18 November 2012 14:51, Artur Skawina  art.08...@gmail.com>> wrote:
> >
> > On 11/18/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?
> >
> >version (GNU) alias half = @gcc[mode(HF)] float;
> >
> > But of course this won't work right now, cause that kind of type
> attributes
> > aren't supported yet. 'pragma' can't be used on types either
> (otherwise
> > something like "alias half = pragma(attribute, mode("HF")) float;"
> could be
> > made to work).
> >
> > And - yes - the /proper/ way would be eg
> >
> >alias half = @core[size=2] float;
> >  // or '@core.size(2)' or any other syntax.
> >
> > For now, a struct + alias-this-getter might be enough, for a s/w
> implementation.
> >
> >
> > Yes, that's what I and everyone else does, but that's not the point of
> the topic...
> > I think it's a fundamental datatype, and it deserves the same
> casting/type conversion/type safety rules as ints and floats, and it would
> also be useful to map it to hardware (which GDC can easily do).
>
> All of the 'half' definitions above would give you a 'fundamental'
> datatype --
> -- there is no reason to make it a /language/-defined type. The work
> required
> to implement things like implicit conversions can be done more generically;
> right now the problem is the lack of a way to define such types.
>
>alias fp24 = @core[exp=7, mant=16] float; // It's only a matter of time
> until
>  // someone asks for it&co...
>
> Also, *every* user- (or in this case more likely lib-) defined data type
> deserves
> the same control over casting and conversions as built-in types. No, D
> doesn't
> have that and yes - it is a problem.
>
> I actually think these types /should/ be done as structs, but
> a) it isn't currently possible (also for reasons other than the above
> mentioned ones)
> and
> b) such aliases would /still/ be useful for mapping to "magic"
> compiler-supported
>h/w types.
>

I don't necessarily disagree, but you can take that logic and run with it
as far as you like.
long can easily be implemented as a struct with 2 ints, why bother with a
builtin type for that? Any answer or counter argument you can possibly give
me applies equally to half.

D needs quite a few tweaks to be able to create a user defined type that is
capable of performing like a builtin type. The main limiters are custom
implicit conversion, and literal syntax definition, but it also seems
really nasty to hook a library, suppress it, and alias it to a hardware
type in the case of GDC for instance. Who's to say the GDC type behaves in
exactly the same way as those defined by the D front end?

Point is, this type should behave in EXACTLY the same way as expected when
dealing with builtin float types, it's not just some user type, it's an
established, industry-recognised precision of float. In reality it's
probably significantly easier to define it wherever the others are defined
rather than in a new library all on its own.
I'd also argue that 'half' is far more valuable to modern computing than
'real'.

Anyway, the point is, we all already use libraries for half, offering
library solutions misses the point of the topic.
The question I raised is: SHOULD half be a builtin type?

Re: half datatype?

[Iain Buclaw]

On 18 November 2012 12:41, Manu  wrote:
> On 18 November 2012 14:13, Dmitry Olshansky  wrote:
>>
>> 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.
>
>
> 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 ;)
>
>>> 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);
>>
>> }
>
>
> Yup, that solves the up-cast problem perfectly! I didn't think of that
> trick.
>
>>> 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.
>
>
> 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.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: half datatype?

[Andrei Alexandrescu]

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

On 18 November 2012 14:01, David Nadlinger mailto:s...@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

Re: half datatype?

[Artur Skawina]

On 11/18/12 16:32, Manu wrote:
> On 18 November 2012 16:33, Artur Skawina  > wrote:
> 
> On 11/18/12 13:58, Manu wrote:
> > On 18 November 2012 14:51, Artur Skawina    >> wrote:
> >
> > On 11/18/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?
> >
> >version (GNU) alias half = @gcc[mode(HF)] float;
> >
> > But of course this won't work right now, cause that kind of type 
> attributes
> > aren't supported yet. 'pragma' can't be used on types either 
> (otherwise
> > something like "alias half = pragma(attribute, mode("HF")) float;" 
> could be
> > made to work).
> >
> > And - yes - the /proper/ way would be eg
> >
> >alias half = @core[size=2] float;
> >  // or '@core.size(2)' or any other syntax.
> >
> > For now, a struct + alias-this-getter might be enough, for a s/w 
> implementation.
> >
> >
> > Yes, that's what I and everyone else does, but that's not the point of 
> the topic...
> > I think it's a fundamental datatype, and it deserves the same 
> casting/type conversion/type safety rules as ints and floats, and it would 
> also be useful to map it to hardware (which GDC can easily do).
> 
> All of the 'half' definitions above would give you a 'fundamental' 
> datatype --
> -- there is no reason to make it a /language/-defined type. The work 
> required
> to implement things like implicit conversions can be done more 
> generically;
> right now the problem is the lack of a way to define such types.
> 
>alias fp24 = @core[exp=7, mant=16] float; // It's only a matter of 
> time until
>  // someone asks for it&co...
> 
> Also, *every* user- (or in this case more likely lib-) defined data type 
> deserves
> the same control over casting and conversions as built-in types. No, D 
> doesn't
> have that and yes - it is a problem.
> 
> I actually think these types /should/ be done as structs, but
> a) it isn't currently possible (also for reasons other than the above 
> mentioned ones)
> and
> b) such aliases would /still/ be useful for mapping to "magic" 
> compiler-supported
>h/w types.
> 
> 
> I don't necessarily disagree, but you can take that logic and run with it as 
> far as you like.
> long can easily be implemented as a struct with 2 ints, why bother with a 
> builtin type for that? Any answer or counter argument you can possibly give 
> me applies equally to half.

   alias long = @core[size(int.sizeof*2)] int;

I'm saying that there's no point in defining '__fp16' when '@core[size(2)] 
float' 
will also do the job. Just as "string" is not a built-in type in D.
Now, this can't be done today, so until it /is/ possible, the struct solution
is an option. No, it isn't perfect. But is it unusable? (honest question)
Would exposing the raw __fp16 type in GDC really be a better long-term solution?

[Of course that 'long' D definition is not a good one, but that's another 
topic] 

> D needs quite a few tweaks to be able to create a user defined type that is 
> capable of performing like a builtin type. The main limiters are custom 
> implicit conversion, and literal syntax definition,

I know, and I'm not sure I'd use the words 'a few tweaks". :)

> but it also seems really nasty to hook a library, suppress it, and alias it 
> to a hardware type in the case of GDC for instance. Who's to say the GDC type 
> behaves in exactly the same way as those defined by

Re: half datatype?

[Robert Jacques]

On Sun, 18 Nov 2012 05:21:27 -0600, 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?



Vote--.

The a half data type is already part of std.numeric. From the docs:

// Define a 16-bit floating point values
   CustomFloat!16x; // 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);

Re: half datatype?

[Robert Jacques]

On Sun, 18 Nov 2012 05:21:27 -0600, 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?



Vote--.

The a half data type is already part of std.numeric. From the docs:

// Define a 16-bit floating point values
   CustomFloat!16x; // 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);

Re: half datatype?

[Manu]

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 <
seewebsiteforem...@erdani.org> wrote:

> On 11/18/12 7:30 AM, Manu wrote:
>
>> On 18 November 2012 14:01, David Nadlinger >
>> > 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
>

Re: half datatype?

[Manu]

On 18 November 2012 20:57, Artur Skawina  wrote:

> On 11/18/12 16:32, Manu wrote:
> > On 18 November 2012 16:33, Artur Skawina  art.08...@gmail.com>> wrote:
> >
> > On 11/18/12 13:58, Manu wrote:
> > > On 18 November 2012 14:51, Artur Skawina  art.08...@gmail.com> >> wrote:
> > >
> > > On 11/18/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?
> > >
> > >version (GNU) alias half = @gcc[mode(HF)] float;
> > >
> > > But of course this won't work right now, cause that kind of
> type attributes
> > > aren't supported yet. 'pragma' can't be used on types either
> (otherwise
> > > something like "alias half = pragma(attribute, mode("HF"))
> float;" could be
> > > made to work).
> > >
> > > And - yes - the /proper/ way would be eg
> > >
> > >alias half = @core[size=2] float;
> > >  // or '@core.size(2)' or any other syntax.
> > >
> > > For now, a struct + alias-this-getter might be enough, for a
> s/w implementation.
> > >
> > >
> > > Yes, that's what I and everyone else does, but that's not the
> point of the topic...
> > > I think it's a fundamental datatype, and it deserves the same
> casting/type conversion/type safety rules as ints and floats, and it would
> also be useful to map it to hardware (which GDC can easily do).
> >
> > All of the 'half' definitions above would give you a 'fundamental'
> datatype --
> > -- there is no reason to make it a /language/-defined type. The work
> required
> > to implement things like implicit conversions can be done more
> generically;
> > right now the problem is the lack of a way to define such types.
> >
> >alias fp24 = @core[exp=7, mant=16] float; // It's only a matter
> of time until
> >  // someone asks for
> it&co...
> >
> > Also, *every* user- (or in this case more likely lib-) defined data
> type deserves
> > the same control over casting and conversions as built-in types. No,
> D doesn't
> > have that and yes - it is a problem.
> >
> > I actually think these types /should/ be done as structs, but
> > a) it isn't currently possible (also for reasons other than the
> above mentioned ones)
> > and
> > b) such aliases would /still/ be useful for mapping to "magic"
> compiler-supported
> >h/w types.
> >
> >
> > I don't necessarily disagree, but you can take that logic and run with
> it as far as you like.
> > long can easily be implemented as a struct with 2 ints, why bother with
> a builtin type for that? Any answer or counter argument you can possibly
> give me applies equally to half.
>
>alias long = @core[size(int.sizeof*2)] int;
>
> I'm saying that there's no point in defining '__fp16' when '@core[size(2)]
> float'
> will also do the job. Just as "string" is not a built-in type in D.
> Now, this can't be done today, so until it /is/ possible, the struct
> solution
> is an option. No, it isn't perfect. But is it unusable? (honest question)
>

I've already agreed that existing solutions (via structs) are usable, but
that's not the point.
They feel artificial. They're just not orthogonal with existing primitive
types, this causes template problems.

Would exposing the raw __fp16 type in GDC really be a better long-term
> solution?
>

No, exposing a GDC type is not acceptable. I'll only use it if it's defined
by the front end, for portability.
Mapping GDC types to a type defined by the front end is another question
though, since the front end will define the r

Re: half datatype?

[Manu]

On 19 November 2012 01:08, Robert Jacques  wrote:

> On Sun, 18 Nov 2012 05:21:27 -0600, 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?
>>
>>
> Vote--.
>
> The a half data type is already part of std.numeric. From the docs:
>
> // Define a 16-bit floating point values
>CustomFloat!16x; // 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'.

Re: half datatype?

[Manu]

On 19 November 2012 01:58, Manu  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 <
> seewebsiteforem...@erdani.org> wrote:
>
>> On 11/18/12 7:30 AM, Manu wrote:
>>
>>> On 18 November 2012 14:01, David Nadlinger >>
>>> > 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
>
>

Re: half datatype?

[Walter Bright]

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

Actually, they probably will. People using it will need to use it regardless of
how it's implemented. Hardware support it great when available, but
realistically, it's used when processing data for execution on another processor
that does support it in hardware (typically a GPU). Use of fp16 is probably not
optional; it doubles your bandwidth wherever the loss of precision is 
acceptable.


Doing implicit conversions on them implies doing them on the x86 CPU, which has 
no hardware support for the type. All operations would require software emulation.


If it is a storage-only format, then what role do implicit conversions play?

Re: half datatype?

[Walter Bright]

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.

Re: half datatype?

[Manu]

On 19 November 2012 06:06, Walter Bright  wrote:

> On 11/18/2012 4:23 PM, Manu wrote:
>
>> Actually, they probably will. People using it will need to use it
>> regardless of
>> how it's implemented. Hardware support it great when available, but
>> realistically, it's used when processing data for execution on another
>> processor
>> that does support it in hardware (typically a GPU). Use of fp16 is
>> probably not
>> optional; it doubles your bandwidth wherever the loss of precision is
>> acceptable.
>>
>
> Doing implicit conversions on them implies doing them on the x86 CPU,
> which has no hardware support for the type. All operations would require
> software emulation.
>

It would just make the experience seamless, and also implement the expected
casting/data-loss rules. It's the type safety/casting rules that I find
most valuable, and the ability to use them in templates without
specialising the half path.

I guess it would be nicer/simpler to perform actual work as floats and then
re-pack it on write back, rather than emulating all the operations in half
space. This wouldn't strictly retain half precision though, it would be
slightly higher precision since the intermediates were full precision
(which is surely preferable?).

If it is a storage-only format, then what role do implicit conversions play?
>

It saves pack/unpack calls whenever interacting with them in structs or
streams, which helps generic code. And also encourages use of the type in
structs, as it is not an 'inconvenience' as such. Where I'm from,
memory/bandwidth is often far more scarce than processing time.
x86 can do half conversion fairly efficiently (about 5 opcodes, possibly
one of the reasons it hasn't found it's way into SSE yet). But it's no
surprise that platforms like ARM implemented the conversion operations in
hardware, there's no time to waste on mobile devices.

I've also seen a few threads on this forum before about people targeting
GPU backends to do GPGPU processing with D. Has that ever actually been
used? Found useful in practise?

Re: half datatype?

[Manu]

On 19 November 2012 06:19, Walter Bright  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.

Re: half datatype?

[Iain Buclaw]

On 19 November 2012 16:04, Manu  wrote:
> On 19 November 2012 06:19, Walter Bright  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';

Re: half datatype?

[Manu]

On 19 November 2012 19:28, Iain Buclaw  wrote:

> On 19 November 2012 16:04, Manu  wrote:
> > On 19 November 2012 06:19, Walter Bright 
> 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.

Re: half datatype?

[Jonathan M Davis]

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

Re: half datatype?

[Rob T]

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

Re: half datatype?

[Walter Bright]

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.

Re: half datatype?

[Walter Bright]

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.

Re: half datatype?

[monarch_dodra]

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).

Re: half datatype?

[Iain Buclaw]

On 19 November 2012 17:57, Manu  wrote:
> On 19 November 2012 19:28, Iain Buclaw  wrote:
>>
>> On 19 November 2012 16:04, Manu  wrote:
>> > On 19 November 2012 06:19, Walter Bright 
>> > 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';

Re: half datatype?

[Manu]

On 19 November 2012 22:28, Rob T  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
>
> 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

Re: half datatype?

[Jonathan M Davis]

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

Re: half datatype?

[Manu]

On 20 November 2012 02:51, Jonathan M Davis  wrote:

> On Monday, November 19, 2012 12:55:11 Walter Bright wrote:
> > On 11/19/2012 12:28 PM, Rob T wrote:
> > > In any case, the point is that I don't think the D community should
> > > overlook what the game devs are doing, they're pushing D to its limits
> > > and are making D more visible than perhaps anyone.
> >
> > I agree.
> >
> > I might also point out that adoption of a language (or any new
> technology)
> > often happens because it solves a problem for an otherwise overlooked
> > niche, and their adoption of it drives it into the mainstream.
>
> I don't disagree at all. I just find it interesting how many things that
> the
> game devs keep coming up with that they consider critical that most of the
> rest of us haven't ever even considered and frequently know absolutely
> nothing
> about.
>

Dunno what to tell you.
Gamedev is a strange union of 3-4-5 very distinct fields of programming,
each with their own set of requirements, and often just the interaction
between them is an interesting problem in its self.
Engine programming is the most critical though, with virtually no room for
compromise. D needs to be competitive in that space if it hopes to dislodge
C/C++, and it's not far off.

Re: half datatype?

[Rob T]

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

Re: half datatype?

[Jacob Carlborg]

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

On 19 November 2012 22:28, Rob T mailto:r...@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


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 

Re: half datatype?

[Don Clugston]

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.

Re: half datatype?

[Era Scarecrow]

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?'.

Re: half datatype?

[DypthroposTheImposter]

 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.

Re: half datatype?

[Kagamin]

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.

Re: half datatype?

[Artur Skawina]

On 11/19/12 01:23, Manu wrote:
> On 18 November 2012 20:57, Artur Skawina  > wrote:
> 
> On 11/18/12 16:32, Manu wrote:
> > On 18 November 2012 16:33, Artur Skawina    >> wrote:
> >
> > On 11/18/12 13:58, Manu wrote:
> > > On 18 November 2012 14:51, Artur Skawina    >     > >
> > > On 11/18/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?
> > >
> > >version (GNU) alias half = @gcc[mode(HF)] float;
> > >
> > > But of course this won't work right now, cause that kind of 
> type attributes
> > > aren't supported yet. 'pragma' can't be used on types either 
> (otherwise
> > > something like "alias half = pragma(attribute, mode("HF")) 
> float;" could be
> > > made to work).
> > >
> > > And - yes - the /proper/ way would be eg
> > >
> > >alias half = @core[size=2] float;
> > >  // or '@core.size(2)' or any other syntax.
> > >
> > > For now, a struct + alias-this-getter might be enough, for a 
> s/w implementation.
> > >
> > >
> > > Yes, that's what I and everyone else does, but that's not the 
> point of the topic...
> > > I think it's a fundamental datatype, and it deserves the same 
> casting/type conversion/type safety rules as ints and floats, and it would 
> also be useful to map it to hardware (which GDC can easily do).
> >
> > All of the 'half' definitions above would give you a 'fundamental' 
> datatype --
> > -- there is no reason to make it a /language/-defined type. The 
> work required
> > to implement things like implicit conversions can be done more 
> generically;
> > right now the problem is the lack of a way to define such types.
> >
> >alias fp24 = @core[exp=7, mant=16] float; // It's only a matter 
> of time until
> >  // someone asks for 
> it&co...
> >
> > Also, *every* user- (or in this case more likely lib-) defined data 
> type deserves
> > the same control over casting and conversions as built-in types. 
> No, D doesn't
> > have that and yes - it is a problem.
> >
> > I actually think these types /should/ be done as structs, but
> > a) it isn't currently possible (also for reasons other than the 
> above mentioned ones)
> > and
> > b) such aliases would /still/ be useful for mapping to "magic" 
> compiler-supported
> >h/w types.
> >
> >
> > I don't necessarily disagree, but you can take that logic and run with 
> it as far as you like.
> > long can easily be implemented as a struct with 2 ints, why bother with 
> a builtin type for that? Any answer or counter argument you can possibly give 
> me applies equally to half.
> 
>alias long = @core[size(int.sizeof*2)] int;
> 
> I'm saying that there's no point in defining '__fp16' when 
> '@core[size(2)] float'
> will also do the job. Just as "string" is not a built-in type in D.
> Now, this can't be done today, so until it /is/ possible, the struct 
> solution
> is an option. No, it isn't perfect. 

Re: half datatype?

[xenon325]

On Monday, 19 November 2012 at 15:48:23 UTC, Manu wrote:

This wouldn't strictly retain half precision though, it would be
slightly higher precision since the intermediates were full 
precision

(which is surely preferable?).


I would think it's actually not preferable.
Imagine you developed and tuned all the code on x86 and 
everything is fine. Then run it on ARM and suddenly all 
computations are inaccurate.

Re: half datatype?

[Walter Bright]

On 11/22/2012 7:03 PM, xenon325 wrote:

I would think it's actually not preferable.
Imagine you developed and tuned all the code on x86 and everything is fine. Then
run it on ARM and suddenly all computations are inaccurate.


Floating point algorithms don't get less precise when precision is increased. I 
can't think of any.

Re: half datatype?

[Manu]

On 23 November 2012 05:03, xenon325 <1...@a.net> wrote:

> On Monday, 19 November 2012 at 15:48:23 UTC, Manu wrote:
>
>> This wouldn't strictly retain half precision though, it would be
>> slightly higher precision since the intermediates were full precision
>> (which is surely preferable?).
>>
>
> I would think it's actually not preferable.
> Imagine you developed and tuned all the code on x86 and everything is
> fine. Then run it on ARM and suddenly all computations are inaccurate.
>

I think it would always be the case that work is done in float space,
hardware support for half applies to fast load/store into full float
registers. You would lose precision too fast if work were done directly in
half space.
Most CPU's also apply this principle to integer work. It's typical to load
a byte/short into a 32/64bit register and sign extend or zero extend, then
all integer work is done in the maximum integer precision, and store then
truncates the top bits again. Many older FPU's work this way too.

Re: half datatype?

[xenon325]

On Friday, 23 November 2012 at 09:08:53 UTC, Manu wrote:

On 23 November 2012 05:03, xenon325 <1...@a.net> wrote:


On Monday, 19 November 2012 at 15:48:23 UTC, Manu wrote:

This wouldn't strictly retain half precision though, it would 
be
slightly higher precision since the intermediates were full 
precision

(which is surely preferable?).



I would think it's actually not preferable.
Imagine you developed and tuned all the code on x86 and 
everything is
fine. Then run it on ARM and suddenly all computations are 
inaccurate.




I think it would always be the case that work is done in float 
space,
hardware support for half applies to fast load/store into full 
float
registers. You would lose precision too fast if work were done 
directly in

half space.
Most CPU's also apply this principle to integer work. It's 
typical to load
a byte/short into a 32/64bit register and sign extend or zero 
extend, then
all integer work is done in the maximum integer precision, and 
store then
truncates the top bits again. Many older FPU's work this way 
too.


Then it's ok, of course. Thanks for explaining!

Re: half datatype?

[xenon325]

On Friday, 23 November 2012 at 06:10:38 UTC, Walter Bright wrote:

On 11/22/2012 7:03 PM, xenon325 wrote:

I would think it's actually not preferable.
Imagine you developed and tuned all the code on x86 and 
everything is fine. Then

run it on ARM and suddenly all computations are inaccurate.


Floating point algorithms don't get less precise when precision 
is increased. I can't think of any.


Actually I meant opposite: on x86 you would work with (kind of) 
32-bit `half` and on ARM with 16-bit.


Then, suppose I did math analysis, and picked up algorithms which 
*should* work correctly, but I have missed something and for 
0.01% of input rounding error is too big on 16-bits, but 
invisible on 32-bits.


If I develop on x86 (with 32-bit precision) and run my app on ARM 
(16-bit precision), than I'm messed up.


Anyway all this beside the point, as Manu have explained me in 
other reply.