Re: [racket-dev] Floating-Point Compliance Testing
On Fri, Feb 8, 2013 at 7:53 PM, Tobias Hammer tobias.ham...@dlr.de wrote: Tested it too and got an interesting result. On a 32bit linux its: +nan.0 +nan.0 +nan.0 +nan.0 +nan.0 +nan.0 +nan.0 +nan.0 That's what I get too. And indeed my other machine was a 64bits Ubuntu and Racket. Laurent so, completely wrong. But on a 64bit Linux its correct if i use the 64bit racket version. When i try the 32bit build i get the wrong results again. I think you can blame it on 32 implementation of racket/libc/compiler or whatever. Not on the actual cpu in use because the hardware was always the same (2 identical computers, identical OS + version, only 32bit in one, 64 in the other). Tobias On Fri, 08 Feb 2013 19:07:53 +0100, Neil Toronto neil.toro...@gmail.com wrote: Back on list. A lot of things point to general sloppiness in either the FPU or C libraries, but I'd like more information just in case. Can you reply with the values of the following expressions on the Athlon? (flexpt -1001.0 -1.3407807929942596e+154) (flexpt -1001.0 1.3407807929942596e+154) (flexpt -0.1 -1.3407807929942596e+154) (flexpt -0.1 1.3407807929942596e+154) (flexpt -744.4400719213812 -1.3407807929942596e+154) (flexpt -744.4400719213812 1.3407807929942596e+154) (flexpt -1.0 -1.3407807929942596e+154) (flexpt -1.0 1.3407807929942596e+154) You should get these values: 0.0 +inf.0 +inf.0 0.0 0.0 +inf.0 1.0 1.0 I think these are cases Racket handles specially instead of handing off to C's `pow' on platforms where we know `pow' handles them wrongly. We might need to ask Matthew to expand that set of platforms. Small rounding errors like this: ((fl*/error -6.87181640380727e-156 2.3341566035927725e-153) 0.7079979032237692) which are only 1 bit off, are probably the cause of these errors: ((fl2log 1.5124390004859715e-308 0.0) 4294967296.220986) ((fl2log1p 3.799205740343036e+246 1.4492752004468653e+230) 549755813887.9473)) `fl2log' and `fl2log1p' are 103-ish-bit logarithm implementations used in certain tricky subdomains of a few special functions. They assume arithmetic is always correct and are very sensitive to rounding errors. You're getting about 65-bit output precision for certain inputs. We can almost certainly blame the FPU because IEEE 754 requires arithmetic to be implemented and correctly rounded. IEEE 754 only *recommends* typical irrational functions. When they're not implemented in hardware, C libraries compute them in software. So I don't know whether these and others are the FPU's or C library's fault: ((flsin 2.5489254492488616e+52) 22637349860729424.0) ((flcos 3.91520018229574e+49) 6369061509154398.0) ((fltan 1.6614020610450763e+21) 9158003261155244.0) ((flexp 16.938769136983012) 7.0) ((flexp 282.52374429474406) 102.0) ((flexp -10.0) 4.0) ((flexp -708.3964185322641) 124.0) These errors come from not doing argument reductions carefully enough. The trigonometric functions probably don't compute x % 2*pi using a high-precision 2*pi when x is large. They seem to be correct enough when x is small, though. The exponential function wasn't tested well at the boundaries of its domain: ((flexp 709.782712893384) +inf.0) 709.782712893384 is (fllog +max.0), and (flexp (fllog +max.0)) should be near +max.0, not (as I suspect) +inf.0. I don't know whether Racket should do anything about these errors. I don't think it would be too hard to do something like Java's StrictMath, but it would take time. In the meantime, don't use the Athlon for serious numerical computation. Neil ⊥ On 02/08/2013 12:13 AM, Laurent wrote: Hi Neil, Interaction in a terminal is attached, using Racket 5.3.2.3. Some details about my machine: Linux 3.2.0-37-generic-pae #58-Ubuntu SMP Thu Jan 24 15:51:02 UTC 2013 i686 athlon i386 GNU/Linux In particular, I use a 32bits Ubuntu 12.04.2 on a 686 processor, if that's of any interest. Cheers, Laurent On Fri, Feb 8, 2013 at 1:15 AM, Neil Toronto neil.toro...@gmail.com mailto:neil.toro...@gmail.com** wrote: On 02/07/2013 12:09 PM, Laurent wrote: On Thu, Feb 7, 2013 at 5:50 PM, Neil Toronto neil.toro...@gmail.com mailto:neil.toro...@gmail.com** mailto:neil.toro...@gmail.com mailto:neil.toro...@gmail.com**__ wrote: Today is not that day, but thanks for asking about this anyway. :) On one machine with Ubuntu 12.10, I get no error, but on another machine with Ubuntu 12.04, I get more than 14000 errors, many of them being +inf.0 and other numbers with big exponents (is my machine really that bad?). Is this exactly the kind of reply you want to avoid for now or are you interested in a report? Alrighty, you've piqued my interest. Better send it off-list, though. :) Neil ⊥ _
Re: [racket-dev] Floating-Point Compliance Testing
Back on list. A lot of things point to general sloppiness in either the FPU or C libraries, but I'd like more information just in case. Can you reply with the values of the following expressions on the Athlon? (flexpt -1001.0 -1.3407807929942596e+154) (flexpt -1001.0 1.3407807929942596e+154) (flexpt -0.1 -1.3407807929942596e+154) (flexpt -0.1 1.3407807929942596e+154) (flexpt -744.4400719213812 -1.3407807929942596e+154) (flexpt -744.4400719213812 1.3407807929942596e+154) (flexpt -1.0 -1.3407807929942596e+154) (flexpt -1.0 1.3407807929942596e+154) You should get these values: 0.0 +inf.0 +inf.0 0.0 0.0 +inf.0 1.0 1.0 I think these are cases Racket handles specially instead of handing off to C's `pow' on platforms where we know `pow' handles them wrongly. We might need to ask Matthew to expand that set of platforms. Small rounding errors like this: ((fl*/error -6.87181640380727e-156 2.3341566035927725e-153) 0.7079979032237692) which are only 1 bit off, are probably the cause of these errors: ((fl2log 1.5124390004859715e-308 0.0) 4294967296.220986) ((fl2log1p 3.799205740343036e+246 1.4492752004468653e+230) 549755813887.9473)) `fl2log' and `fl2log1p' are 103-ish-bit logarithm implementations used in certain tricky subdomains of a few special functions. They assume arithmetic is always correct and are very sensitive to rounding errors. You're getting about 65-bit output precision for certain inputs. We can almost certainly blame the FPU because IEEE 754 requires arithmetic to be implemented and correctly rounded. IEEE 754 only *recommends* typical irrational functions. When they're not implemented in hardware, C libraries compute them in software. So I don't know whether these and others are the FPU's or C library's fault: ((flsin 2.5489254492488616e+52) 22637349860729424.0) ((flcos 3.91520018229574e+49) 6369061509154398.0) ((fltan 1.6614020610450763e+21) 9158003261155244.0) ((flexp 16.938769136983012) 7.0) ((flexp 282.52374429474406) 102.0) ((flexp -10.0) 4.0) ((flexp -708.3964185322641) 124.0) These errors come from not doing argument reductions carefully enough. The trigonometric functions probably don't compute x % 2*pi using a high-precision 2*pi when x is large. They seem to be correct enough when x is small, though. The exponential function wasn't tested well at the boundaries of its domain: ((flexp 709.782712893384) +inf.0) 709.782712893384 is (fllog +max.0), and (flexp (fllog +max.0)) should be near +max.0, not (as I suspect) +inf.0. I don't know whether Racket should do anything about these errors. I don't think it would be too hard to do something like Java's StrictMath, but it would take time. In the meantime, don't use the Athlon for serious numerical computation. Neil ⊥ On 02/08/2013 12:13 AM, Laurent wrote: Hi Neil, Interaction in a terminal is attached, using Racket 5.3.2.3. Some details about my machine: Linux 3.2.0-37-generic-pae #58-Ubuntu SMP Thu Jan 24 15:51:02 UTC 2013 i686 athlon i386 GNU/Linux In particular, I use a 32bits Ubuntu 12.04.2 on a 686 processor, if that's of any interest. Cheers, Laurent On Fri, Feb 8, 2013 at 1:15 AM, Neil Toronto neil.toro...@gmail.com mailto:neil.toro...@gmail.com wrote: On 02/07/2013 12:09 PM, Laurent wrote: On Thu, Feb 7, 2013 at 5:50 PM, Neil Toronto neil.toro...@gmail.com mailto:neil.toro...@gmail.com mailto:neil.toro...@gmail.com mailto:neil.toro...@gmail.com__ wrote: Today is not that day, but thanks for asking about this anyway. :) On one machine with Ubuntu 12.10, I get no error, but on another machine with Ubuntu 12.04, I get more than 14000 errors, many of them being +inf.0 and other numbers with big exponents (is my machine really that bad?). Is this exactly the kind of reply you want to avoid for now or are you interested in a report? Alrighty, you've piqued my interest. Better send it off-list, though. :) Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Floating-Point Compliance Testing
DrDr runs (test-floating-point 1000) every push, which has returned only '() for weeks. In your output, I don't see anything that would indicate a problem with Racket. We can almost certainly pin the blame on your processor or the standard libraries on your platform. Even though you got errors, they're small enough to not worry about. Maximum 1 ulp error is great, as is the fact that exp, log, sqrt and arithmetic are apparently correct. I'd confidently do numerical stuff on that machine. One of these days, I'd like to collect test output for all the platforms we support from multiple users, to see if there are any platform-specific errors we should address. (I know, for example, that `flexpt' is IEEE754/C99 compliant on Linux with a good FPU, because Matthew has worked around the corner-case bugs in C's `pow' on that platform. I don't know about its compliance on other platforms, though.) Today is not that day, but thanks for asking about this anyway. :) Neil ⊥ On 02/07/2013 07:13 AM, Pierpaolo Bernardi wrote: Hello, is it nomal for (test-floating-point n) to report errors? I'm getting the ones attached below. Should I file a bug report? Cheers Welcome to DrRacket, version 5.3.2.3--2013-02-05(fb91582/a) [3m]. Language: racket. (test-floating-point 1) '(((flexpt -1.4916681462400412e-154 -1.0) 1.0) ((flexpt 1.4916681462400412e-154 -1.0) 1.0) ((flexpt -1.3407807929942596e+154 -1.0) 1.0) ((flexpt 1.3407807929942596e+154 -1.0) 1.0) ((flexpt 1.921080487981769e-308 8.774598382932543e-020) 1.0) ((flsin -32.1387292674823) 1.0) ((flsin 3.3511818651824413e+140) 1.0) ((flsin 5.847428587385298e+109) 1.0) ((flsin -4.2636167073107216e+220) 1.0) ((flsin 2.2376618304533545e+147) 1.0) ((flsin -10355.675178842243) 1.0) ((flsin 1.4223624681529512e+250) 1.0) ((flsin 1.2221672019771145e+226) 1.0) ((flsin 5.190670595822648e+196) 1.0) ((flsin -2.8606457219797484e+049) 1.0) ((flsin 5.947898074762479e+089) 1.0) ((flsin 7.658744764846541e+118) 1.0) ((flsin -3.049875275737775e+299) 1.0) ((flsin -6.95577409457e+071) 1.0) ((flsin -2.5894425646523045e+306) 1.0) ((flsin -4.332533560607931e+098) 1.0) ((flsin -1.3377658758561444e+058) 1.0) ((flsin 9.76045095515798e+255) 1.0) ((flsin 184081474351119.28) 1.0) ((flsin -3.247948271806115e+021) 1.0) ((flsin -4.837455059537947e+057) 1.0) ((flsin -4.2959580275398866e+247) 1.0) ((flsin 8.914054063806207e+160) 1.0) ((flsin 1.9913808387114566e+166) 1.0) ((flsin 5.538511967956732e+111) 1.0) ((flsin 1.6654341159171633e+216) 1.0) ((flsin 3.7661506545237663e+132) 1.0) ((flsin -1.0950688983732088e+086) 1.0) ((flsin -1.0712916520317726e+261) 1.0) ((flsin 1.0863483848070641e+216) 1.0) ((flsin 3.3156882308423572e+196) 1.0) ((flsin 2.0426248707211622e+093) 1.0) ((flsin -1.4615982247548854e+139) 1.0) ((flsin 9.85415343986109e+098) 1.0) ((flsin 2.711917549872105e+086) 1.0) ((flsin 3.026884301885179e+214) 1.0) ((flsin 1.2794885467128095e+298) 1.0) ((flsin -4.43583369095173e+283) 1.0) ((flsin 3.743304757133868e+074) 1.0) ((flsin 29.054804079760853) 1.0) ((flsin -2.0814881083707804e+290) 1.0) ((flsin 3.356428142388993e+288) 1.0) ((flsin -2.3346926013508203e+239) 1.0) ((flsin 1.976265450158466e+063) 1.0) ((flsin -104253690.1423) 1.0) ((flsin -1.345718920635393e+281) 1.0) ((flsin 6.338054355501187e+253) 1.0) ((flsin -2.9102651358401293e+125) 1.0) ((flsin -2.3491889885217407e+271) 1.0) ((flsin -2.294047470737622e+066) 1.0) ((flsin -6.648400760473659e+026) 1.0) ((flsin -2928034.5439151367) 1.0) ((flsin 2.3796100455731755e+247) 1.0) ((flsin -2.390286067260539e+266) 1.0) ((flsin 11412429430.8821) 1.0) ((flsin 1.5841451151018928e+124) 1.0) ((flsin -1.1766732889070135e+191) 1.0) ((flsin -5.993884549434707e+108) 1.0) ((flsin 4.321170988106885e+303) 1.0) ((flsin -2.696801353348753e+067) 1.0) ((flsin 1.4446705071169635e+163) 1.0) ((flsin -1.1327054652195439e+286) 1.0) ((flsin 1883391.6802365936) 1.0) ((flsin 3.370845703107914e+293) 1.0) ((flsin 8.131216231284196e+104) 1.0) ((flsin -7.60305238778847e+153) 1.0) ((flsin -3.011219941683773e+162) 1.0) ((flsin 2.3775373163836616e+182) 1.0) ((flsin -2.522040486823584e+187) 1.0) ((flsin 1.4504840176107196e+137) 1.0) ((flsin 5.862268285651628e+261) 1.0) ((flsin 1.9144879312398312e+173) 1.0) ((flsin -1.1307565797645817e+111) 1.0) ((flsin 9.218023924930619e+224) 1.0) ((flsin 1.9793526394294298e+205) 1.0) ((flsin 2.7926212498148574e+195) 1.0) ((flsin 7.243120033823765e+061) 1.0) ((flsin -7.258846382334985e+223) 1.0) ((flsin 3.593028456996262e+160) 1.0) ((flsin 6.819779947539389e+283) 1.0) ((flsin -2.938761368515067e+136) 1.0) ((flsin 1.7763839442258374e+304) 1.0) ((flsin 2.153391155260819e+141) 1.0) ((flsin -9.417630020410581e+122) 1.0) ((flsin 4.9277659645392215e+255) 1.0)
Re: [racket-dev] Floating-Point Compliance Testing
On Thu, Feb 7, 2013 at 5:50 PM, Neil Toronto neil.toro...@gmail.com wrote: DrDr runs (test-floating-point 1000) every push, which has returned only '() for weeks. In your output, I don't see anything that would indicate a problem with Racket. We can almost certainly pin the blame on your processor or the standard libraries on your platform. OK. Thanks. FWIW, the processor is a recent low-end intel i7 (i7-3630QM). A recent nightly build on windows 8. Cheers _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Floating-Point Compliance Testing
On 02/07/2013 12:09 PM, Laurent wrote: On Thu, Feb 7, 2013 at 5:50 PM, Neil Toronto neil.toro...@gmail.com mailto:neil.toro...@gmail.com wrote: Today is not that day, but thanks for asking about this anyway. :) On one machine with Ubuntu 12.10, I get no error, but on another machine with Ubuntu 12.04, I get more than 14000 errors, many of them being +inf.0 and other numbers with big exponents (is my machine really that bad?). Is this exactly the kind of reply you want to avoid for now or are you interested in a report? Alrighty, you've piqued my interest. Better send it off-list, though. :) Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev