From: Leo <sdl.web@gm...>  20090801 08:16:47

On 20090801 02:01 +0100, Paul Khuong wrote: >> In sbcl 1.0.22 and 1.0.27: >> >> (cos 100000000000000000000000000000000) returns 0.0 > > Known bug on SBCL/x86. It should be fixed soonish. Thank you.  Leo's Emacs uptime: 9 hours, 15 minutes, 43 seconds 
From: Leo <sdl.web@gm...>  20090731 23:05:20

Hi there, In sbcl 1.0.22 and 1.0.27: (cos 100000000000000000000000000000000) returns 0.0 In R, it returns 0.4909367. Is this a bug?  Leo's Emacs uptime: 1 hour, 29 minutes, 6 seconds 
From: Paul Khuong <pkhuong@gm...>  20090801 01:02:02

On 31Jul09, at 6:57 PM, Leo wrote: > Hi there, > > In sbcl 1.0.22 and 1.0.27: > > (cos 100000000000000000000000000000000) returns 0.0 Known bug on SBCL/x86. It should be fixed soonish. Paul Khuong 
From: Harald HancheOlsen <hanche@ma...>  20090801 02:37:28

+ Paul Khuong <pkhuong@...>: > On 31Jul09, at 6:57 PM, Leo wrote: > > Hi there, > > > > In sbcl 1.0.22 and 1.0.27: > > > > (cos 100000000000000000000000000000000) returns 0.0 > > Known bug on SBCL/x86. It should be fixed soonish. If so then maybe it should be fixed on ppc too: There, sbcl 10.0.29.9 returns 0.85093546. This is wrong. It should be about .9207313841.  Harald 
From: Paul Khuong <pkhuong@gm...>  20090801 03:13:08

On 31Jul09, at 10:37 PM, Harald HancheOlsen wrote: > + Paul Khuong <pkhuong@...>: > >> On 31Jul09, at 6:57 PM, Leo wrote: >>> Hi there, >>> >>> In sbcl 1.0.22 and 1.0.27: >>> >>> (cos 100000000000000000000000000000000) returns 0.0 >> >> Known bug on SBCL/x86. It should be fixed soonish. > > If so then maybe it should be fixed on ppc too: > There, sbcl 10.0.29.9 returns 0.85093546. > This is wrong. It should be about .9207313841. Different bug. On x86 we don't do any range reduction even when the hardware tells us the argument is too large to handle directly. I'll let better informed people discuss the subtleties of accurate range reduction for transcendentals. FWIW, on x8664, we ask glibc and get 0.8108648261576408d0. Paul Khuong 
From: Leo <sdl.web@gm...>  20090801 08:16:47

On 20090801 02:01 +0100, Paul Khuong wrote: >> In sbcl 1.0.22 and 1.0.27: >> >> (cos 100000000000000000000000000000000) returns 0.0 > > Known bug on SBCL/x86. It should be fixed soonish. Thank you.  Leo's Emacs uptime: 9 hours, 15 minutes, 43 seconds 
From: Harald HancheOlsen <hanche@ma...>  20090801 16:56:27

+ Leo <sdl.web@...>: > In sbcl 1.0.22 and 1.0.27: > > (cos 100000000000000000000000000000000) returns 0.0 > > In R, it returns 0.4909367. > > Is this a bug? Yes, that is a bug (in R): The correct answer is more like .92073138. Jokes aside, I think it is clearly unreasonable to expect sbcl to be able to return a good approximation because doing so requires knowledge of pi to thirtysome decimal places. I can't seem to find anything in the hyperspec specifying what the trigonometric functions should do when given huge numbers.  Harald 
From: Harald HancheOlsen <hanche@ma...>  20090801 17:14:36

+ Harald HancheOlsen <hanche@...>: > Jokes aside, I think it is clearly unreasonable [...] Please note that the quoted message was stuck on sourceforge for almost 17 hours. It is not my intention to restart this discussion from scratch.  Harald 
From: Gabriel Dos Reis <gdr@in...>  20090801 17:26:19

On Fri, Jul 31, 2009 at 7:21 PM, Harald HancheOlsen<hanche@...> wrote: > + Leo <sdl.web@...>: > >> In sbcl 1.0.22 and 1.0.27: >> >> (cos 100000000000000000000000000000000) returns 0.0 >> >> In R, it returns 0.4909367. >> >> Is this a bug? > > Yes, that is a bug (in R): The correct answer is more like .92073138. > > Jokes aside, I think it is clearly unreasonable to expect sbcl to be > able to return a good approximation because doing so requires > knowledge of pi to thirtysome decimal places. I can't seem to find > anything in the hyperspec specifying what the trigonometric functions > should do when given huge numbers. Right, the hyperspec does not require a useful Lisp implementation.  Gaby 
From: Sidney Markowitz <sidney@si...>  20090801 22:24:33

Harald HancheOlsen wrote, On 1/8/09 12:21 PM: > + Leo <sdl.web@...>: > >> In sbcl 1.0.22 and 1.0.27: >> >> (cos 100000000000000000000000000000000) returns 0.0 >> >> In R, it returns 0.4909367. >> >> Is this a bug? > > Yes, that is a bug (in R): The correct answer is more like .92073138. > > [...] a good approximation because doing so requires > knowledge of pi to thirtysome decimal places. I get 0.920731383924191d0 by multiplying the number by a power of ten and finding that mod 2*pitosomeplaces times that same power of ten, then dividing that result by that power of ten as a doublefloat and getting cos of that. Doing it that way the number of decimal places I need for pi is thirtytwo (the number of digits in the number we're taking cos of) plus the number of digits precision in the result, e.g., at least 48 digits to get consistent 15 digit precision doublefloat results. Is there a way to do it with pi to only 32 places? Either way, without an algorithm that can reduce the range without having pi to at least the same number of places as in the argument, how can any computation of the function on arbitrary bignums be correct, whether in sbcl, R, or glibc? Is there a range reduction algorithm that does not require pi to arbitrary precision, I guess by computing pi on the fly as part of the range reduction? ;; code I tested with (defparameter *bigpi* (* 2 31415926535897932384626433832795028841971693993751058209749445923078164062862)) (defparameter *testnum* 100000000000000000000000000000000) (defun costest (testnum 2piexp77 precision) (let ((shrinkpi (expt 10 ( 77 precision))) (expandtest (expt 10 (1 precision)))) (cos (/ (mod (* testnum expandtest) (round 2piexp77 shrinkpi)) (coerce expandtest 'doublefloat))))) ;;;;;;;;;;; (costest *testnum* *bigpi* 48) 0.9207313839241906d0 Sidney Markowitz http://sidney.com 
From: Kevin Rosenberg <kevin@ro...>  20090802 11:10:49

That "arbitrary precision calculator" gives the same result as does your technique. My suspicion is that same as yours  that 'calc' is computing pi on the fly  but, I haven't looked at its source code. Cstyle arbitrary precision calculator (version 2.12.3.3) Calc is open software. For license details type: help copyright ; cos(100000000000000000000000000000000) 0.9207313839241906876 On Aug 1, 2009, at 3:43 PM, Sidney Markowitz wrote: > I get 0.920731383924191d0 by multiplying the number by a power of ten > and finding that mod 2*pitosomeplaces times that same power of ten, > then dividing that result by that power of ten as a doublefloat and > getting cos of that. > > Doing it that way the number of decimal places I need for pi is > thirtytwo (the number of digits in the number we're taking cos of) > plus > the number of digits precision in the result, e.g., at least 48 > digits > to get consistent 15 digit precision doublefloat results. > > Is there a way to do it with pi to only 32 places? > > Either way, without an algorithm that can reduce the range without > having pi to at least the same number of places as in the argument, > how > can any computation of the function on arbitrary bignums be correct, > whether in sbcl, R, or glibc? Is there a range reduction algorithm > that > does not require pi to arbitrary precision, I guess by computing pi on > the fly as part of the range reduction? > > > ;; code I tested with > > (defparameter *bigpi* (* 2 > 31415926535897932384626433832795028841971693993751058209749445923078164062862 > )) > > (defparameter *testnum* 100000000000000000000000000000000) > > (defun costest (testnum 2piexp77 precision) > (let ((shrinkpi (expt 10 ( 77 precision))) > (expandtest (expt 10 (1 precision)))) > (cos (/ (mod (* testnum expandtest) > (round 2piexp77 shrinkpi)) > (coerce expandtest 'doublefloat))))) > > ;;;;;;;;;;; > > (costest *testnum* *bigpi* 48) > 0.9207313839241906d0 > > > > Sidney Markowitz > http://sidney.com > > > >  > Let Crystal Reports handle the reporting  Free Crystal Reports 2008 > 30Day > trial. Simplify your report design, integration and deployment  and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobjjuly > _______________________________________________ > Sbcldevel mailing list > Sbcldevel@... > https://lists.sourceforge.net/lists/listinfo/sbcldevel > 