Re: [racket-dev] Floating-Point Compliance Testing

2013-02-09 Thread Laurent 
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

2013-02-08 Thread Neil Toronto 

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

2013-02-07 Thread Neil Toronto 
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

2013-02-07 Thread Pierpaolo Bernardi 
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

2013-02-07 Thread Neil Toronto 

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