On 10/20/2017 07:23 PM, Damian McGuckin wrote:
However in Chapel, [INFINITY and NAN] 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.
This is my first time digging into that part of Chapel, but if you
look at modules/standard/Math.chpl, you see that proc INFINITY just
returns the result of a runtime function called chpl_macro_INFINITY().
In runtime/include/chplmath.h, chpl_macro_INFINITY() is
implemented by type punning so that it can return a specific bit
pattern. An alternate implementation would be welcome.
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);
As Brad mentioned, we do not want to rely on C-compiler-specific
tricks like gcc's failure to trap on these overflowing constants. Other
than that, the general idea sounds fine to me.
Also note that constants in general are problematic. We may be
running on a system that mimics the IEEE format but not the details,
like some GPUs, or is not an IEEE binary format, such as some IBM
systems that offer IEEE decimal floating point.
Perhaps instead of hard coding constants, these procs could return
chpl_macro_INFINITY32(), chpl_macro_INFINITY64(), etc. which would just
return INFINITY in the appropriate type. That would make Chapel
completely independent of bit patterns for these values.
I do not know enough about NAN to comment on it although I figure that
NAN propogates according to IEEE rules also. Comments David?
NAN is trickier but the technique I just mentioned would work for
that. Note that NAN is optional in C, so Chapel currently depends on
running on a system that supports NANs. That has not been a problem.
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).
I am not sure it is possible to be portable while making them proc
params. It is worth some thought.
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;
Something like that. It hasn't been nailed down yet.
You've obviously been thinking about this topic a lot. Thanks for
being so involved!
David
------------------------------------------------------------------------------
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
