Brad,
I need to start reading 'github'. Looks like that is where the action is.
Certainly it answers many questions. But I am a mailing-list sort of guy:)
On Mon, 23 Oct 2017, Brad Chamberlain wrote:
I'm not going to be the best correspondent this week,
Ditto me. On a plane tomorrow and again next week.
but some of the things you're running into relate to the "Chapel does
not currently do much compile-time optimization of floating point
'param' values" comment I made earlier which, in retrospect, should've
really read "much compile-time computation on floating point param
values."
I figured.
Specifically, we historically haven't supported compile-time computation
on floating point values because we were nervous (maybe wisely, maybe
out of paranoia, though most recent conversations have suggested the
latter) that the compiler's floating point semantics might differ from
the execution-time node's semantics and lead to confusion. This comes
up in the following GitHub issues and is something I think we're very
open to reconsidering this as the language continues to evolve:
https://github.com/chapel-lang/chapel/issues/5922
Interesting discussion.
The weak support for 32-bit param reals is, I believe, more of an
implementation issue than an intention by any means. This issue relates
to that:
https://github.com/chapel-lang/chapel/issues/5122
This is what you mentioned earlier.
For example, to scale a number by a power of 2, you can write
inline proc fpScale(x : ?T, n : int(32)) : T
{
param emin = fpEmin(T);
param Vmin = fpVmin(T);
param emax = fpEmax(T);
param Vmax = fpVmax(T);
var i : int(32);
i = 0;
while n > emax do
{
if i == 4 then
{
return x;
}
x *= Vmax; n -= emax; i += 1;
}
i = 0;
while n < emin do
{
if i == 4 then
{
return x;
}
x *= Vmin; n -= emin; i += 1;
}
return x * fpUnSafePowerOf2(T, n);
}
This works for real(16), real(32), real(64) and real(128). It is clean,
clear and should be fast. Note that a trivial translation to C for double
or float produces code which is better than competitive with the Math/-lm
library routine scalbnf and scalbn. And unlike the internals of those two
C routines in most of the productive BSD/*nix libraries I have seen, there
are no visible floating literals and no magic bit patterns. Writing the
above in C or C++ is nothing like as clean and I cannot deduce how to
avoid messy #defines. Acknowledgement: The code above is based on MUSL's
implementation of scalbn/scalbnf with my own tweaks for readability that
do not sacrifice performance.
Note (in pseudo Chapel)
fpUnSafePowerOf2(real(?w), int n) return (2**n):real(w)
where
min IEEE 754 exponent of binary?w <= n <= max IEEE 754 exponent of same
The one other note I'll throw in here is that we've tried very hard to
avoid the need for suffixes on literal values because it seems somewhat
funny and somewhat difficult to extend;
Exactly.
but I think there are questions about whether the current approach (cast
real literal to the type you want) is sufficient and/or whether
suffix-based support would be more convenient/less typing.
I think that you need to stick with your current approach
cast real literal to the type you want
because that is totally parameterizable. Otherwise, given this
short float w = 1.2345hf; // of something like it maybe
float x = 1.2345F;
double y = 1.2345;
long double z = 1.2345L;
it is a pain to totally parameterize even 'almost portably'.
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
