half datatype?

[Manu]

On 18 November 2012 16:33, Artur Skawina <art.08.09 at gmail.com> wrote:

> On 11/18/12 13:58, Manu wrote:
> > On 18 November 2012 14:51, Artur Skawina <art.08.09 at gmail.com <mailto:
> art.08.09 at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121118/1b9aa511/attachment-0001.html>