Anton van Straaten wrote:
>> Is this from a real application?
>
>
> The original example posted by Oleg looked like a test case - he'd have to
> answer that for sure.
>
The number 12345678901234567890123 was the first one that came out of a
pseudo-random number generator, but that's a whole different story ...
Seriously, I first saw this artifact in CMUCL. Since Lisp uses "real"
numbers, I was curious as to how sin handled big numbers: no matter how
smart an implementation, I expected errors to accumulate unless it
dynamically calculated Pi with necessary precision (Sine is periodic, so if
you knew its period with arbitrary precision, you could calculate sine of
arbitrarily large numbers).
To my surprise, CMUCL returned 0.0 for all large inputs. When I was playing
around with MIT-Scheme a while later, I noticed this even more bizarre
behavior and thought people would be amused.
Cheers
Oleg
P.S. X-posted to CLL. Check (sin 12345678901234567890123) in your favorite
Lisp-machine.
The accuracy of sin of big numbers can be treated correctly
in lisp programs written for macsyma, which reveals that
a= sin(123...) is about 4.20582.. b-1 where the "b"
is a bigfloat marker.
if you compute c= sin( 123.... +pi/2) which is better
known as cos( 123....) = 9.07254..b-1,
then you can compute a^2+c^2 and find the result is 1.0.
The ordinary precision (double) sine of large numbers
which are nevertheless within the double-float range
should presumably be treated in a language independent
manner, and not in the costly way done above. The answer
0.0 for all large inputs may be what the host OS math
library provides.
RJF
(The bigfloat library is in the free "maxima" version as
well as in a "mockMMA" mathematica-like evaluator available
free from my home page. And yes, you must compute pi dynamically
to sufficiently high precision to move large arguments into
a range where other approximations can be used.)
Oleg wrote:
> Anton van Straaten wrote:
>
>
>>>Is this from a real application?
>>
>>
>>The original example posted by Oleg looked like a test case - he'd have to
>>answer that for sure.
>>
>
>
> The number 12345678901234567890123 was the first one that came out of a
> pseudo-random number generator, but that's a whole different story ...
>
> Seriously, I first saw this artifact in CMUCL. Since Lisp uses "real"
> numbers, I was curious as to how sin handled big numbers: no matter how
> smart an implementation, I expected errors to accumulate unless it
> dynamically calculated Pi with necessary precision (Sine is periodic, so if
> you knew its period with arbitrary precision, you could calculate sine of
> arbitrarily large numbers).
>
> To my surprise, CMUCL returned 0.0 for all large inputs. When I was playing
> around with MIT-Scheme a while later, I noticed this even more bizarre
> behavior and thought people would be amused.
>
> Cheers
>
> Oleg
>
> P.S. X-posted to CLL. Check (sin 12345678901234567890123) in your favorite
> Lisp-machine.
Richard Fateman wrote:
> The accuracy of sin of big numbers can be treated correctly
> in lisp programs written for macsyma, which reveals that
> a= sin(123...) is about 4.20582.. b-1 where the "b"
> is a bigfloat marker.
> if you compute c= sin( 123.... +pi/2) which is better
> known as cos( 123....) = 9.07254..b-1,
> then you can compute a^2+c^2 and find the result is 1.0.
>
> The ordinary precision (double) sine of large numbers
> which are nevertheless within the double-float range
> should presumably be treated in a language independent
> manner, and not in the costly way done above. The answer
> 0.0 for all large inputs may be what the host OS math
> library provides.
> RJF
>
> (The bigfloat library is in the free "maxima" version as
> well as in a "mockMMA" mathematica-like evaluator available
> free from my home page. And yes, you must compute pi dynamically
> to sufficiently high precision to move large arguments into
> a range where other approximations can be used.)
Hello Richard,
I'm guessing you forgot the sign. I actually verified the answer "by hand"
[1]. It appears that no native C library call of sin returns the correct
answer; and people posted plenty of Lisp, Scheme and C results on Windows,
Solaris and Linux/x86. On my P4M/Debian, the most amazing answer of 1.23e22
is given by MIT Scheme and "gcc -ffast-math -O".
Cheers,
Oleg
[1] http://www.columbia.edu/~ot14/better_sin.lisp
>>>>> "Oleg" == Oleg <············@myrealbox.com> writes:
Oleg> Anton van Straaten wrote:
>>> Is this from a real application?
>>
>>
>> The original example posted by Oleg looked like a test case - he'd have to
>> answer that for sure.
>>
Oleg> The number 12345678901234567890123 was the first one that came out of a
Oleg> pseudo-random number generator, but that's a whole different story ...
Oleg> Seriously, I first saw this artifact in CMUCL. Since Lisp uses "real"
Oleg> numbers, I was curious as to how sin handled big numbers: no matter how
Oleg> smart an implementation, I expected errors to accumulate unless it
Oleg> dynamically calculated Pi with necessary precision (Sine is periodic, so if
Oleg> you knew its period with arbitrary precision, you could calculate sine of
Oleg> arbitrarily large numbers).
Oleg> To my surprise, CMUCL returned 0.0 for all large inputs. When I was playing
I can tell by this answer that you are very probably using CMUCL on an
x86 platform. On Solaris, CMUCL returns 0.95760524.
CMUCL is at the mercy of the C library. If your C library sucks,
CMUCL will too.
Ray