Paul, Michael, ....
On Thu, 7 Mar 2019, Michael Ferguson wrote:
I think this is a GCC-ism.
Definitely related.
My hypothesis here is that certain versions of GCC, when optimizations
are enabled, will evaluate `cbrt` at compile-time. I suspect that this
compile-time evaluation computes the operation more precisely than the
runtime math library does.
Here is a C program that shows the same behavior with GCC 8.2 (where the
result depends on whether or not optimization is enabled):
Thanks. I could not trigger it but I was using a different version and I
was being lazy and burying it in with my own testing of the routine over a
wide numeric range. But I have seen that behaviour with 'nextafter'. The
problem is that it gets it wrong in these cases, lthough admittedly by
only the rounding error which technically is still correct as per the
standard.
int main() {
double y = 0x1.0p-1044;
double cbrtX = cbrt(0x1.0p-1044);
double cbrtY = cbrt(y);
printf("cbrtX=%a\n", cbrtX);
printf("cbrtY=%a\n", cbrtY);
return 0;
}
Compiling it with the GCC flag --save-temps, I can see in the generated
.s file that with -O there are no calls to cbrt in the program, and
without, there is one.
Still learning how to read that monster!
So, I think GCC has the capability of evaluating cbrt exactly at
compile-time.
That is a silly thing for GCC to do if you see what logic is needed but,
yes, it does happen.
But only when optimizations are enabled does it figure out
that `y` in the above program is known at compile-time.
GCC does get confused sometimes.
With clang instead of GCC, or with the --llvm backend with the original
Chapel programs, we see the version with 0.5 relative error in either
case. This is because clang/--llvm does not attempt to evaluate cbrt at
compile-time, and the system math library has 0.5 relative error.
0.5*EPSILON relative error. (I hope)
The answer you saw that GCC returns for either compile-time evaluation or
run-time is accurate to 0.5*EPSILONr which affects only the last bit.
However, in my uses of GCC, it got it exact all the time for something so
small and with only a single bit in the significand.
Damian, I have had trouble finding resources indicating the relative
error of system math library functions.
There are no formal ones that I can find. I look in the code and something
they are there documented. Sometimes not.
Note that CBRT is accurate to 2/3*EPSILON at worst which affects only the
last bit so it is still good.
Is that a problem in your work?
No. I go and figure them out.
It sounds like you use a strategy of re-implementing them to achieve the
precision you require.
My work is mainly in Linear Algebra and vectors norms and square roots. I
need to reimplement hypot. Also, there are issues with the precision used
to build LIBM because of whatever is chosen FLT_EVAL_METHOD. Which is
different to what I use, i.e. real(w) means real(w) operations, which is
what Fortran does.
But I have been using low level functions to test my Chapel work because
the data set is small and easily reproducible and (I hope) it is easier to
understand my ramblings if I talk about the elementary functions.
Also, when I found that I could use Chapel's generic features to redo log
routines as just 2 (instead of 24, log, log1p, base 2, base e, base 10,
and 4 precisions), I could screen Chapel's massive selling point.
I personally think it would be nice to be able to list the maximum
errors possible in the Math documentation, but as long as we use the
system math library, that information would be platform-dependent
(besides the problem that I wouldn't know what errors to put in the
documentation even for one platform).
I will send you what I have - later. It is very imcomplete.
Of course it would be possible for our Math library to reimplement these
functions, but that seems like a pretty big undertaking
Yes. Huge. But something that could be done by students doing an MS thesis
and might lead to reduced performance when comparing against C
programs...
Ultimately, Chapel is a superior language in which to write these low
level routines. But it ios a big job and we need to wait until your hot
mods to the compiler appears over the next few years.
Later - 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
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
