On Fri, 20 Oct 2017, David Keaton wrote:
Hi, Damian. A member of the Chapel team happens to be the convener of
the C standards committee. That's me.
You certainly are a handy asset to put out of the hat!
In C, INFINITY and NAN are of float type (usually implemented via the
IEEE floating-point type). That was done so that they would be useful in
any larger type as well. No special politics were involved; it was just
easiest to define one symbol that worked in all floating-point types.
Certainly in the current GNU C, they are 32 bit quantities although they
are builtin features.
However in Chapel, they are both declared as real(64)/double so I was very
curious at how it worked in terms of the C back end. I assume in all cases
it relies on IEEE 754 propogation of InF/NAN rather than any implicit type
coercion. I hate coercions and even propogation because I have to think
too hard about the rules. Either way, you are relying on some underlying
'magic'. My ideas were to come up with a way of specifying INFINITY that
did not rely on any magic except IEEE 754 arithmetic.
Also, I think that my way (which explicitly types it) should work for IEEE
binary16 AKA 'short floats' AKA 'half floats' or IEEE binary128 AKA 'quad
float' AKA '(genuine) long double'. I might need better terminology in the
last as '(normal) long double' = IEEE's extended double.
proc fpINFINITY(type t) where t == real(64) return 0x1.0p1024:real(64);
proc fpINFINITY(type t) where t == real(32) return 0x1.0p128f;real(32);
proc fpINFINITY(type t) where t == real(16) return 0x1.0p16hf;real(16);
proc fpINFINITY(type t) where t == real(128) return 0x1.0p16384lf;real(128);
Then again, using the same magic that the C compiler uses, maybe I could
say
proc fpINFINITY(type t) where t == real(64) return 0x1.0p128f:real(64);
proc fpINFINITY(type t) where t == real(32) return 0x1.0p128f;real(32);
proc fpINFINITY(type t) where t == real(16) return 0x1.0p128f;real(16);
proc fpINFINITY(type t) where t == real(128) return 0x1.0p128f;real(128);
Nah. I do not like magic. Flick the last batch. Use the first batch.
I do not know enough about NAN to comment on it although I figure that NAN
propogates according to IEEE rules also. Comments David?
Note that in my case, I want any such definition to be a 'proc param' so
they get handled at compile time. I know the above does not do this (yet).
I need to sort out the syntax as Brad noted that I messed up on my first
attempt (which I was too lazy/slack to check would compile cleanly).
The C committee may need to revisit this when the proposal for "short
float" is deliberated.
I assume a floating point literal (in the above) will be something like
short float x = 0x1.0p10hf;
Thanks - Damian
Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
