Hi all,
Currently there is
param INFINITY : real(64)
and
proc NAN : real(64)
While also a flaw with C/C++, i note that there are no 32 bit equivalents
but that will not not the last time a double feature is not available for
floats in C. Orthogonality amongst floating point types is one of the
strengths of the IEEE 754 standard. I digress.
My main question is why is one a param and the other a proc? Why is it
not a 'proc param'?
To write truly templated code, something the C standard did not have to
consider, do we need something like
proc fpINFINITY(fudge : real(64)) param real(64) ......
proc fpINFINITY(fudge : real(32)) param real(32) ......
proc fpNAN(fudge : real(64)) param real(64) ......
proc fpNAN(fudge : real(32)) param real(32) ......
or are such constants an attribute of a real, e.g.
var x : real(64)
assert(isinf(x.INFINITY()) == true)
or
assert(isnan(x.NAN()) == true)
What about when Chapel rules the HPC/GPU space and Chapel has to support
the IEEE types
real(128)
or
real(16)
Also how viable/smart is my use of 'fudge' because it is just a dummy
variable except for its number of bits? Assume that if I want a set of
templated functions to return say the limits of the exponents of a given
IEEE754 floating point number
proc fpEmax(x : real(32)) : param return 127:int(32);
proc fpEmax(x : real(64)) : param return 1023:int(64);
proc fpEmin(x : real(32)) : param return -126:int(32);
proc fpEmin(x : real(64)) : param return -1022:int(64);
Is there a better way to guarantee the correct templated instantiation?
Regards - 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
