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

[Laurent]

On Fri, Feb 8, 2013 at 7:53 PM, Tobias Hammer  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 
> 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 >> > wrote:
>>>
>>> On 02/07/2013 12:09 PM, Laurent wrote:
>>>
>>> On Thu, Feb 7, 2013 at 5:50 PM, Neil Toronto
>>> 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 ki

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

[Neil Toronto]

Excellent test! I can think of two things that could cause the difference:

 1. `flexpt' works around `pow' bugs on 64-bit Linux but not 32-bit
(Racket can fix this one)

 2. 64-bit compile uses SSE instructions, and the SSE unit is better
than the FPU

There are probably more possibilities.

Neil ⊥

On 02/08/2013 11:53 AM, Tobias Hammer 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

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 
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 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
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

[Tobias Hammer]

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

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 
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 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
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



--
-
Tobias Hammer
DLR / Institute of Robotics and Mechatronics
Muenchner Str. 20, D-82234 Wessling
Tel.: 08153/28-1487
Mail: tobias.ham...@dlr.de

___

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

[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 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
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

[Neil Toronto]

On 02/07/2013 12:09 PM, Laurent wrote:

On Thu, Feb 7, 2013 at 5:50 PM, Neil Toronto 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

[Pierpaolo Bernardi]

On Thu, Feb 7, 2013 at 5:50 PM, Neil Toronto  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

[Laurent]

On Thu, Feb 7, 2013 at 5:50 PM, Neil Toronto 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?

Laurent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

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

[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)