Come for the quick hacks, stay for the epiphanies. | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Regarding how to look at the failing systems = sometimes, you can email the owner of the machine that gave you the failing test, and they are willing to manually run a debug version of your test suite and give you the results. When I haven't wanted to pester the owner, I've occasionally just burned a revision (or used an alpha revision) and submitted a debug revision to CPAN. (I've had problems with going to the next real rev after an alpha, which is why I've sometimes burned a normal revision). When I do that, I make sure everything will still pass, it will just give you extra debug information. For debugging, I would use some Test::More::diag() calls, especially looking at intermediate values, such as diag($num); diag(log($num)), diag(log($num)/log(1000)). You also might want to look at the hex representations, using the modern sprintf format %a1, which gives the hexadecimal-floating-point representation, or my Data::IEEE754::Tools's convertToHexString(), which will give a similar representation on systems that don't have that format.2 My guess for the culprit was to look at the NVSIZE (use config; diag(nvsize => $Config{nvsize}); diag(nvtype => $Config{nvtype})) and some of the other types and sizes on the failing system(s)... I was wondering whether on that specific system, it was using a binary32 instead of binary64 for the NVTYPE (NVSIZE=4 instead of NVSIZE=8); or maybe it's gone the other way, and the failing systems are using binary128 (NVSIZE=16); either way, the change in precision can sometimes change which side of "exact" the binary floating-point representation lands on, which might change whether log(1e-33) would be slightly less or slightly greater than and the extra precision is causing the roundoff to be different. 1: For binary32, %a would want %.6a, binary64 would want %.14a, and binary128 would want %.29a 2: Currently, Data::IEEE754::Tools will coerce NVSIZE=16 (binary128) into NVSIZSE=8 (binary64), so it won't give the exact representation on a binary128 system. Given you're failing on 5.24 and 5.26, which are new enough to have %a, I'd probably recommend %a. In reply to Re: Portability of floor(log(N))
by pryrt
|
|