You can subscribe to this list here.
2000 
_{Jan}
(81) 
_{Feb}
(55) 
_{Mar}
(459) 
_{Apr}
(159) 
_{May}
(126) 
_{Jun}
(69) 
_{Jul}
(48) 
_{Aug}
(29) 
_{Sep}
(106) 
_{Oct}
(76) 
_{Nov}
(155) 
_{Dec}
(161) 

2001 
_{Jan}
(122) 
_{Feb}
(150) 
_{Mar}
(294) 
_{Apr}
(124) 
_{May}
(197) 
_{Jun}
(266) 
_{Jul}
(111) 
_{Aug}
(259) 
_{Sep}
(163) 
_{Oct}
(142) 
_{Nov}
(101) 
_{Dec}
(86) 
2002 
_{Jan}
(187) 
_{Feb}
(108) 
_{Mar}
(274) 
_{Apr}
(157) 
_{May}
(346) 
_{Jun}
(242) 
_{Jul}
(345) 
_{Aug}
(187) 
_{Sep}
(263) 
_{Oct}
(69) 
_{Nov}
(30) 
_{Dec}
(76) 
2003 
_{Jan}
(125) 
_{Feb}
(191) 
_{Mar}
(87) 
_{Apr}
(69) 
_{May}
(107) 
_{Jun}
(66) 
_{Jul}
(112) 
_{Aug}
(161) 
_{Sep}
(184) 
_{Oct}
(137) 
_{Nov}
(28) 
_{Dec}
(61) 
2004 
_{Jan}
(148) 
_{Feb}
(99) 
_{Mar}
(365) 
_{Apr}
(225) 
_{May}
(311) 
_{Jun}
(204) 
_{Jul}
(95) 
_{Aug}
(214) 
_{Sep}
(256) 
_{Oct}
(290) 
_{Nov}
(239) 
_{Dec}
(152) 
2005 
_{Jan}
(253) 
_{Feb}
(183) 
_{Mar}
(178) 
_{Apr}
(88) 
_{May}
(175) 
_{Jun}
(195) 
_{Jul}
(122) 
_{Aug}
(81) 
_{Sep}
(119) 
_{Oct}
(200) 
_{Nov}
(110) 
_{Dec}
(179) 
2006 
_{Jan}
(154) 
_{Feb}
(64) 
_{Mar}
(55) 
_{Apr}
(69) 
_{May}
(66) 
_{Jun}
(64) 
_{Jul}
(80) 
_{Aug}
(59) 
_{Sep}
(62) 
_{Oct}
(90) 
_{Nov}
(132) 
_{Dec}
(106) 
2007 
_{Jan}
(58) 
_{Feb}
(51) 
_{Mar}
(59) 
_{Apr}
(19) 
_{May}
(33) 
_{Jun}
(52) 
_{Jul}
(15) 
_{Aug}
(50) 
_{Sep}
(41) 
_{Oct}
(259) 
_{Nov}
(323) 
_{Dec}
(136) 
2008 
_{Jan}
(205) 
_{Feb}
(128) 
_{Mar}
(203) 
_{Apr}
(126) 
_{May}
(307) 
_{Jun}
(166) 
_{Jul}
(259) 
_{Aug}
(181) 
_{Sep}
(217) 
_{Oct}
(265) 
_{Nov}
(256) 
_{Dec}
(132) 
2009 
_{Jan}
(104) 
_{Feb}
(81) 
_{Mar}
(27) 
_{Apr}
(21) 
_{May}
(85) 
_{Jun}
(237) 
_{Jul}
(243) 
_{Aug}
(199) 
_{Sep}
(178) 
_{Oct}
(151) 
_{Nov}
(64) 
_{Dec}
(39) 
2010 
_{Jan}
(33) 
_{Feb}
(146) 
_{Mar}
(125) 
_{Apr}
(109) 
_{May}
(52) 
_{Jun}
(135) 
_{Jul}
(103) 
_{Aug}
(68) 
_{Sep}
(99) 
_{Oct}
(88) 
_{Nov}
(45) 
_{Dec}
(56) 
2011 
_{Jan}
(19) 
_{Feb}
(32) 
_{Mar}
(50) 
_{Apr}
(105) 
_{May}
(46) 
_{Jun}
(22) 
_{Jul}
(101) 
_{Aug}
(80) 
_{Sep}
(52) 
_{Oct}
(16) 
_{Nov}
(10) 
_{Dec}
(29) 
2012 
_{Jan}
(8) 
_{Feb}
(22) 
_{Mar}
(17) 
_{Apr}
(68) 
_{May}
(19) 
_{Jun}
(19) 
_{Jul}
(12) 
_{Aug}
(6) 
_{Sep}
(13) 
_{Oct}
(5) 
_{Nov}
(5) 
_{Dec}
(5) 
2013 
_{Jan}
(6) 
_{Feb}
(4) 
_{Mar}
(3) 
_{Apr}
(5) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(6) 
_{Dec}

2014 
_{Jan}

_{Feb}

_{Mar}
(16) 
_{Apr}
(1) 
_{May}
(8) 
_{Jun}

_{Jul}
(1) 
_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}

2015 
_{Jan}

_{Feb}
(8) 
_{Mar}
(23) 
_{Apr}
(5) 
_{May}

_{Jun}

_{Jul}

_{Aug}
(7) 
_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(31) 
2
(9) 
3
(5) 
4
(1) 
5
(10) 
6

7
(15) 
8
(3) 
9
(22) 
10
(6) 
11
(7) 
12
(5) 
13
(1) 
14
(10) 
15

16

17
(1) 
18

19
(1) 
20

21
(3) 
22
(3) 
23
(4) 
24
(4) 
25

26
(1) 
27
(4) 
28
(28) 
29
(9) 
30
(1) 
31
(3) 
From: Sam Steingold <sds@us...>  20020828 20:42:49

Update of /cvsroot/clisp/clisp/src In directory uswprcvs1:/tmp/cvsserv19619/src Modified Files: FILES Log Message: regenerated 
From: Sam Steingold <sds@us...>  20020828 20:42:38

Update of /cvsroot/clisp/clisp/src In directory uswprcvs1:/tmp/cvsserv19549 Modified Files: FILES.1 Log Message: updated 
From: Sam Steingold <sds@gn...>  20020828 17:52:50

> * In message <15725.2501.307234.693664@...> > * On the subject of "Re: expt bug" > * Sent on Wed, 28 Aug 2002 19:35:01 +0200 (CEST) > * Honorable Bruno Haible <haible@...> writes: > > Sam writes: > > > sure, computing (sin(x)/x)^2 at y=pi/2x is the right decision here. > > are you going to do this? > > If you don't beat me at it: yes. I do not want a race. When are you going to do it? (today? tomorrow? next week? next year?)  Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux <http://www.camera.org>; <http://www.iris.org.il>; <http://www.memri.org/>; <http://www.mideasttruth.com/>; <http://www.palestinecentral.com/links.html>; I may be getting older, but I refuse to grow up! 
From: Raymond Toy <toy@rt...>  20020828 17:48:50

>>>>> "Bruno" == Bruno Haible <haible@...> writes: [snipped parts that I agree with] >> I think computer should compute things as accurately as possible, >> without trying to guess what the numbers might have meant. Bruno> I think computers should keep track about the accuracy. Yes. But we don't really have that yet, unless we do interval arithmetic by hand. (I understand interval arithmetic has it's own problems, sometimes producing bounds much wider than necessary, but I don't follow that field at all.) Ray 
From: Sam Steingold <sds@gn...>  20020828 17:47:30

> * In message <15725.2367.707619.426819@...> > * On the subject of "Re: expt bug" > * Sent on Wed, 28 Aug 2002 19:32:47 +0200 (CEST) > * Honorable Bruno Haible <haible@...> writes: > > > I think computer should compute things as accurately as possible, > > without trying to guess what the numbers might have meant. > > I think computers should keep track about the accuracy. how can they without explicit interval arithmetic? > > produce the even less biased result of #c(25.0 0.0). :) > Why not :) right now: (/ (imagpart (expt 5.0 2.0)) singlefloatepsilon) ==> 73.33554 this means that the computations are __VERY__ impresize. (7400% error!!!)  Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux <http://www.camera.org>; <http://www.iris.org.il>; <http://www.memri.org/>; <http://www.mideasttruth.com/>; <http://www.palestinecentral.com/links.html>; Life is a sexually transmitted disease with 100% mortality. 
From: Raymond Toy <toy@rt...>  20020828 17:44:55

>>>>> "Sam" == Sam Steingold <sds@...> writes: >> * In message <4nlm6q29c6.fsf@...> >> * On the subject of "Re: expt bug" >> * Sent on 28 Aug 2002 13:15:37 0400 >> * Honorable Raymond Toy <toy@...> writes: >> >> >>>>> "Sam" == Sam Steingold <sds@...> writes: >> Sam> this is wrong, even thought it might look good. if floats Sam> were exact rationals, then the product of two single floats Sam> would have been a double float. >> >> Yes, I was being sloppy with wordsfloats are not exact rationals. >> I just want things computed as accurately as possible given the float > precisely, not accurately! :) Sam> CLISP has no idea about accuracy! Yes, precisely! >> that was given, without trying to pretend to know what the actual >> accuracy of the float is. Sam> exactly! Sam> (sorry for nitpicking! :) No problem. We should strive to be as precise and accurate as possible. :) Ray 
From: Bruno Haible <haible@il...>  20020828 17:33:05

Sam writes: > sure, computing (sin(x)/x)^2 at y=pi/2x is the right decision here. > are you going to do this? If you don't beat me at it: yes. Bruno 
From: Bruno Haible <haible@il...>  20020828 17:31:48

Raymond Toy writes: > You actually have many series for (sin(x)/x)^2 expanded at all those > different integer multiples of pi? Of course not. I use (mod x pi) and develop around 0. Bruno 
From: Bruno Haible <haible@il...>  20020828 17:30:51

Raymond Toy writes: > You want to treat all FP numbers as intervals. Yes. > I want to treat them as exact rationals. This point of view is justified in C or Fortran  which lack builtin RATIONAL number type, but in Lisp and Scheme, where we have the distinction between exact rationals and inexact floatingpoint numbers. > Pretending that every FP number is an interval seems somewhat wrong, > because when I write 2.0, maybe it's really from the interval [1.5, > 2.5). You can't know thatonly I know that. The ideal floating point data type contains the midpoint of the interval and an estimation of the length of the interval. Some computer algebra systems get this right. In Lisp, we only have 4 possible values for the interval length: short/single/double/long float precision. Still the precision of a rational is *way* different, because it is an infinitely short interval. > I think computer should compute things as accurately as possible, > without trying to guess what the numbers might have meant. I think computers should keep track about the accuracy. We have a rule that rationals may be replaced by floats during computations (CLHS 12.1.3.3. Rule of Float Substitutability), but never the converse. > produce the even less biased result of #c(25.0 0.0). :) Why not :) Bruno 
From: Sam Steingold <sds@gn...>  20020828 17:24:21

> * In message <951560684.20020828084334@...> > * On the subject of "Re[2]: assuredirexists [UNIX] question" > * Sent on Wed, 28 Aug 2002 08:43:34 +1000 > * Honorable Arseny Slobodjuck <ampy@...> writes: > > Wednesday, August 28, 2002, 1:00:11 AM, you wrote: > > >> At pathname.d, assuredirexists beginning at line 6744: > >> > >> why lstat call is out of if_HAVE_LSTAT ? > > > as opposed to #ifdef HAVE_LSTAT? > > because the call is inside a macro (with_sstring_0) and macros cannot > > contain CPP instructions. > > No, I mean what's the purpose of HAVE_LSTAT if lstat call appears in > preprocessed code independently of it (seems to me so). It looks like: > > with_sstring_0 () { > ... > lstat() > ... > if_HAVE_LSTAT ( > ... > no any lstat call > ... > ) > } sorry about the misunderstanding. please look at unix.d: #ifdef HAVE_LSTAT ... #else #define lstat stat #define S_ISLNK(m) false #endif  Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux <http://www.camera.org>; <http://www.iris.org.il>; <http://www.memri.org/>; <http://www.mideasttruth.com/>; <http://www.palestinecentral.com/links.html>; Only adults have difficulty with childproof caps. 
From: Sam Steingold <sds@gn...>  20020828 17:22:21

> * In message <4nlm6q29c6.fsf@...> > * On the subject of "Re: expt bug" > * Sent on 28 Aug 2002 13:15:37 0400 > * Honorable Raymond Toy <toy@...> writes: > > >>>>> "Sam" == Sam Steingold <sds@...> writes: > > Sam> this is wrong, even thought it might look good. if floats > Sam> were exact rationals, then the product of two single floats > Sam> would have been a double float. > > Yes, I was being sloppy with wordsfloats are not exact rationals. > I just want things computed as accurately as possible given the float > precisely, not accurately! :) CLISP has no idea about accuracy! > that was given, without trying to pretend to know what the actual > accuracy of the float is. exactly! (sorry for nitpicking! :)  Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux <http://www.camera.org>; <http://www.iris.org.il>; <http://www.memri.org/>; <http://www.mideasttruth.com/>; <http://www.palestinecentral.com/links.html>; Your mouse has moved  WinNT has to be restarted for this to take effect. 
From: Bruno Haible <haible@il...>  20020828 17:17:38

Sam writes: > > But I could agree if you change the result from > > #C(25.000002 4.3711393E6) > > to a less biased > > #C(25.000002 0.0) > > > > Sam writes: > > > please try the appended patch. > > > > The patch is wrong for above reasons. > > the patch optimizes the (expt 5.0 2.0) computation by computing > (expt 5.0 2) instead (since they are mathematically identical). No they are not identical. For the same reason that (expt 5.0 2) must return 25.0 and not the exact number 25, for the same reason the imaginary part of (expt 5.0 2.0) must be the inexact 0.0 and not the exact 0. Note that the complex canonicalization rule in clisp reads #c(x 0) = x but #c(x 0.0) /= x Bruno 
From: Raymond Toy <toy@rt...>  20020828 17:15:48

>>>>> "Sam" == Sam Steingold <sds@...> writes: Sam> this is wrong, even thought it might look good. Sam> if floats were exact rationals, then the product of two single floats Sam> would have been a double float. Yes, I was being sloppy with wordsfloats are not exact rationals. I just want things computed as accurately as possible given the float that was given, without trying to pretend to know what the actual accuracy of the float is. Ray 
From: Sam Steingold <sds@gn...>  20020828 16:30:56

> * In message <4nu1lf0xhf.fsf@...> > * On the subject of "Re: expt bug" > * Sent on 28 Aug 2002 12:17:00 0400 > * Honorable Raymond Toy <toy@...> writes: > > >>>>> "Bruno" == Bruno Haible <haible@...> writes: > > Bruno> Raymond Toy writes: > >> > In 2.28 and 2.29 on Solaris I get: > >> > > >> > [1]> (expt 5.0 2.0) > >> > #C(25.000002 4.3711393E6) > >> > [2]> (expt 5.0d0 2.0d0) > >> > #C(24.999999999999996d0 6.122503540205582d15) > >> > > >> > Somewhat surprising results since the correct answers are real > >> > numbers. > > Bruno> Raymond, you know what a floatingpoint number stands for: an interval > Bruno> of real numbers. 2.0 stands for the interval [2  eps, 2 + 2*eps], > Bruno> where eps is singlefloatnegativeepsilon. > > We've had these discussions before and I think this is were we've > always disagreed. You want to treat all FP numbers as intervals. I > want to treat them as exact rationals. this is wrong, even thought it might look good. if floats were exact rationals, then the product of two single floats would have been a double float. the issue here is accuracy vs precision, see <http://clisp.cons.org/impnotes.html#flocont>;  Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux <http://www.camera.org>; <http://www.iris.org.il>; <http://www.memri.org/>; <http://www.mideasttruth.com/>; <http://www.palestinecentral.com/links.html>; Of course, I haven't tried it. But it will work.  Isaak Asimov 
From: Sam Steingold <sds@gn...>  20020828 16:22:30

> * In message <15724.62832.742961.452125@...> > * On the subject of "Re: expt bug" > * Sent on Wed, 28 Aug 2002 18:08:16 +0200 (CEST) > * Honorable Bruno Haible <haible@...> writes: > > Sam writes: > > > The problem there is that all trigonometric functions are computed from > > the MacLaurent series for (sin(x)/x)^2. This means taking SQRT for SIN > > and TAN (and many others), which creates the problem you reported. > > There is nothing wrong with (sin(x)/x)^2. The real problem is that > the series is computed around 0, pi, 2*pi, etc.  not expecting > rounding problems around pi/2. The real fix would compute a different > series around pi/2, 3*pi/2, 5*pi/2 etc. sure, computing (sin(x)/x)^2 at y=pi/2x is the right decision here. are you going to do this?  Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux <http://www.camera.org>; <http://www.iris.org.il>; <http://www.memri.org/>; <http://www.mideasttruth.com/>; <http://www.palestinecentral.com/links.html>; Lisp is a way of life. C is a way of death. 
From: Raymond Toy <toy@rt...>  20020828 16:21:59

>>>>> "Bruno" == Bruno Haible <haible@...> writes: Bruno> Sam writes: >> The problem there is that all trigonometric functions are computed from >> the MacLaurent series for (sin(x)/x)^2. This means taking SQRT for SIN >> and TAN (and many others), which creates the problem you reported. Bruno> There is nothing wrong with (sin(x)/x)^2. The real problem is that Bruno> the series is computed around 0, pi, 2*pi, etc.  not expecting Bruno> rounding problems around pi/2. The real fix would compute a different Bruno> series around pi/2, 3*pi/2, 5*pi/2 etc. You actually have many series for (sin(x)/x)^2 expanded at all those different integer multiples of pi? In any case, I don't really care about the rounding problems, I was just surprised that tan(x) was not closer to cos(x) for x near pi/2. Ray 
From: Raymond Toy <toy@rt...>  20020828 16:17:13

>>>>> "Bruno" == Bruno Haible <haible@...> writes: Bruno> Raymond Toy writes: >> > In 2.28 and 2.29 on Solaris I get: >> > >> > [1]> (expt 5.0 2.0) >> > #C(25.000002 4.3711393E6) >> > [2]> (expt 5.0d0 2.0d0) >> > #C(24.999999999999996d0 6.122503540205582d15) >> > >> > Somewhat surprising results since the correct answers are real >> > numbers. Bruno> Raymond, you know what a floatingpoint number stands for: an interval Bruno> of real numbers. 2.0 stands for the interval [2  eps, 2 + 2*eps], Bruno> where eps is singlefloatnegativeepsilon. We've had these discussions before and I think this is were we've always disagreed. You want to treat all FP numbers as intervals. I want to treat them as exact rationals. Pretending that every FP number is an interval seems somewhat wrong, because when I write 2.0, maybe it's really from the interval [1.5, 2.5). You can't know thatonly I know that. I think computer should compute things as accurately as possible, without trying to guess what the numbers might have meant. Bruno> Now, (expt 5.0 1.999999) is a complex number, Bruno> (expt 5.0 2.000001) is a complex number. You can therefore not expect Bruno> (expt 5.0 2.0) to be a real number. Well, of course I can, because my 2.0 is the exact rational 2.0, represented as a floatingpoint number. :) Bruno> But I could agree if you change the result from Bruno> #C(25.000002 4.3711393E6) Bruno> to a less biased Bruno> #C(25.000002 0.0) I do not disagree with your reasoning, here, however. By why, not go for broke and produce the even less biased result of #c(25.0 0.0). :) Yes, I'll see what I can do with maxima about this. Ray 
From: Sam Steingold <sds@gn...>  20020828 16:12:27

> * In message <15724.62520.469499.305994@...> > * On the subject of "Re: expt bug" > * Sent on Wed, 28 Aug 2002 18:03:04 +0200 (CEST) > * Honorable Bruno Haible <haible@...> writes: > > But I could agree if you change the result from > #C(25.000002 4.3711393E6) > to a less biased > #C(25.000002 0.0) > > Sam writes: > > please try the appended patch. > > The patch is wrong for above reasons. the patch optimizes the (expt 5.0 2.0) computation by computing (expt 5.0 2) instead (since they are mathematically identical).  Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux <http://www.camera.org>; <http://www.iris.org.il>; <http://www.memri.org/>; <http://www.mideasttruth.com/>; <http://www.palestinecentral.com/links.html>; To a Lisp hacker, XML is Sexpressions with extra cruft. 
From: Bruno Haible <haible@il...>  20020828 16:06:27

Sam writes: > The problem there is that all trigonometric functions are computed from > the MacLaurent series for (sin(x)/x)^2. This means taking SQRT for SIN > and TAN (and many others), which creates the problem you reported. There is nothing wrong with (sin(x)/x)^2. The real problem is that the series is computed around 0, pi, 2*pi, etc.  not expecting rounding problems around pi/2. The real fix would compute a different series around pi/2, 3*pi/2, 5*pi/2 etc. Bruno 
From: Raymond Toy <toy@rt...>  20020828 16:01:42

>>>>> "Sam" == Sam Steingold <sds@...> writes: >> * In message <4n8z2r2i6h.fsf@...> >> P.S. Did you ever get around to fixing the problem where >> (tan (/ pi 2)) was quite a bit different from (/ (cos (/ pi 2)))? >> Just curious. You said you knew where the problem was but I don't >> remember any resolution. Not a big deal. Sam> The problem there is that all trigonometric functions are computed from Sam> the MacLaurent series for (sin(x)/x)^2. This means taking SQRT for SIN Sam> and TAN (and many others), which creates the problem you reported. Sam> I think that this decision (to use (sin(x)/x)^2) was made in the early Sam> 1990ies when the project started, and it persisted into the CLN. Too bad. I wonder how this decision was made. Bruno? Sam> Fixing the problem you reported requires replacing (sin(x)/x)^2 with Sam> something more palatable (it is not clear what exactly). Sam> Switching to CORDIC is a very serious project. I think I used to have some CORDIC code in Lisp, but I doubt I can find it anymore. Anyway CORDIC is pretty simple to do, but getting all the tables recomputed when the precision changes can be a pain. Ray 
From: Bruno Haible <haible@il...>  20020828 16:01:06

Raymond Toy writes: > > In 2.28 and 2.29 on Solaris I get: > > > > [1]> (expt 5.0 2.0) > > #C(25.000002 4.3711393E6) > > [2]> (expt 5.0d0 2.0d0) > > #C(24.999999999999996d0 6.122503540205582d15) > > > > Somewhat surprising results since the correct answers are real > > numbers. Raymond, you know what a floatingpoint number stands for: an interval of real numbers. 2.0 stands for the interval [2  eps, 2 + 2*eps], where eps is singlefloatnegativeepsilon. Now, (expt 5.0 1.999999) is a complex number, (expt 5.0 2.000001) is a complex number. You can therefore not expect (expt 5.0 2.0) to be a real number. But I could agree if you change the result from #C(25.000002 4.3711393E6) to a less biased #C(25.000002 0.0) > > FWIW, this breaks some things with maxima. Then fix Maxima to use an exact integer as exponent. Sam writes: > please try the appended patch. The patch is wrong for above reasons. Bruno 
From: Sam Steingold <sds@gn...>  20020828 15:33:03

> * In message <4n8z2r2i6h.fsf@...> > * On the subject of "Re: expt bug" > * Sent on 28 Aug 2002 10:04:38 0400 > * Honorable Raymond Toy <toy@...> writes: > > >>>>> "Sam" == Sam Steingold <sds@...> writes: > Sam> please try the appended patch. > This works beautifully! Thanks! you are welcome. > P.S. Did you ever get around to fixing the problem where > (tan (/ pi 2)) was quite a bit different from (/ (cos (/ pi 2)))? > Just curious. You said you knew where the problem was but I don't > remember any resolution. Not a big deal. The problem there is that all trigonometric functions are computed from the MacLaurent series for (sin(x)/x)^2. This means taking SQRT for SIN and TAN (and many others), which creates the problem you reported. I think that this decision (to use (sin(x)/x)^2) was made in the early 1990ies when the project started, and it persisted into the CLN. Fixing the problem you reported requires replacing (sin(x)/x)^2 with something more palatable (it is not clear what exactly). Switching to CORDIC is a very serious project. Any volunteers?  Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux <http://www.camera.org>; <http://www.iris.org.il>; <http://www.memri.org/>; <http://www.mideasttruth.com/>; <http://www.palestinecentral.com/links.html>; A year spent in artificial intelligence is enough to make one believe in God. 
From: Sam Steingold <sds@us...>  20020828 15:02:14

Update of /cvsroot/clisp/clisp/unix In directory uswprcvs1:/tmp/cvsserv13315 Modified Files: INSTALL Log Message: readline is not made by CLISP 
From: Sam Steingold <sds@us...>  20020828 14:33:34

Update of /cvsroot/clisp/clisp/src In directory uswprcvs1:/tmp/cvsserv30769 Modified Files: NEWS Removed Files: CHANGES.LOG Log Message: renamed CHANGES.LOG to NEWS 
From: Sam Steingold <sds@us...>  20020828 14:29:03

Update of /cvsroot/clisp/clisp/src In directory uswprcvs1:/tmp/cvsserv28473 Modified Files: HISTORY Log Message: added 2.29 