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}
(5) 
2016 
_{Jan}

_{Feb}

_{Mar}
(16) 
_{Apr}
(6) 
_{May}
(53) 
_{Jun}
(19) 
_{Jul}
(3) 
_{Aug}
(39) 
_{Sep}
(24) 
_{Oct}
(2) 
_{Nov}
(19) 
_{Dec}

2017 
_{Jan}
(13) 
_{Feb}
(44) 
_{Mar}
(208) 
_{Apr}
(12) 
_{May}
(94) 
_{Jun}
(43) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1

2
(1) 
3
(1) 
4
(1) 
5
(2) 
6
(2) 
7
(2) 
8
(1) 
9
(4) 
10
(8) 
11
(12) 
12
(13) 
13
(24) 
14
(2) 
15
(2) 
16
(6) 
17
(15) 
18
(9) 
19
(8) 
20
(7) 
21
(5) 
22
(2) 
23
(3) 
24
(24) 
25
(7) 
26
(2) 
27
(11) 
28
(9) 
29
(4) 
30
(5) 
31
(11) 





From: SourceForge.net <noreply@so...>  20080327 22:26:13

Bugs item #1684969, was opened at 20070321 04:08 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1684969&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: lisp error Status: Open Resolution: None Priority: 5 Private: No Submitted By: Aleksander Nabaglo (anab) Assigned to: Bruno Haible (haible) Summary: numerical inaccuracy in cos or sin Initial Comment: Slow 256 point Hartley Transfom exhibits numerical 10^2 relative inaccuracy at points 4, 8, 16, 29, 32, 58, 116. Slow 255 point HT does not exhibit numerical inaccuracies. Probably problem with sin/cos evaluated near integer * PI /2. Attached test code, results from clisp2.41 and sbcl1.0.3.  Comment By: Raymond Toy (rtoy) Date: 20080327 18:26 Message: Logged In: YES user_id=28849 Originator: NO Here is at least one of the problems: (cis 22.776546738526d0) > #c(1.0 0.0) But I think the right answer is #C(0.7071067811865476 0.7071067811865476), as returned by CMUCL and maxima. FWIW, I figured this out by adding a test in fcast1dslow. It computes sin(x) + cos(x). But this should be the same as sqrt(2)*cos(xpi/4). I compared the 2 values and printed out messages when they were not close enough. 22.7765... is approx 7.25*pi.  Comment By: Sam Steingold (sds) Date: 20080327 13:19 Message: Logged In: YES user_id=5735 Originator: NO it would be nice to see a smaller test case.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1684969&group_id=1355 
From: SourceForge.net <noreply@so...>  20080327 22:04:40

Bugs item #1683394, was opened at 20070319 01:01 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1683394&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: lisp error Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Sam Steingold (sds) Summary: TANH floating point overflow for large short or single float Initial Comment: (TANH 1.0s3) => floating point overflow (TANH 1.0f3) => floating point overflow (TANH 1.0d3) => 1.0d0 (OK) (TANH 1.0l3) => 1.0L0 (OK) Clisp 2.38 / Linux. I looked at the Changelog and didn't see anything about TANH. Hope this helps.  Comment By: Raymond Toy (rtoy) Date: 20080327 18:04 Message: Logged In: YES user_id=28849 Originator: NO I did look a little at 1684969. I can't reproduce the issue with clisp 2.42 on sparc. More commentss there.  Comment By: Sam Steingold (sds) Date: 20080327 15:15 Message: Logged In: YES user_id=5735 Originator: NO you are right, I now use the old method for small x. would you like to take a look at https://sourceforge.net/tracker/index.php?func=detail&aid=1684969&group_id=1355&atid=101355 ??  Comment By: Raymond Toy (rtoy) Date: 20080327 14:14 Message: Logged In: YES user_id=28849 Originator: NO >From the logs, I see you implemented this as (1exp(2*x))/(1+exp(2*x)). This fixes the overflow problem, but now you have an accuracy problem for x near 0 since exp(2*x) is approximately 1. I think you need to implement some variant of D(x) = exp(x)1 by modifying the exp function with the initial sum of 0 instead of 1. Then use D(2*x)/(2+D(2*x)) to compute tanh(x). Or for x small, say <= 1/2, use the original sinh/cosh, since clisp has an accurate sinh for small x.  Comment By: Sam Steingold (sds) Date: 20080327 12:42 Message: Logged In: YES user_id=5735 Originator: NO thank you for your bug report. the bug has been fixed in the CVS tree. you can either wait for the next release (recommended) or check out the current CVS tree (see http://clisp.cons.org) and build CLISP from the sources (be advised that between releases the CVS tree is very unstable and may not even build on your platform).  Comment By: Raymond Toy (rtoy) Date: 20080327 07:50 Message: Logged In: YES user_id=28849 Originator: NO Oops. That was for solving issues near 0, which clisp doesn't have. I think a better scheme would be (1exp(2*x))/(1+exp(2*x)) = 1  2*exp(2*x)/(1+exp(2*x)) for x >> 0. Just need to either turn off the underflow warning or check that x is so large that exp(2*x) would underflow to zero. I guess D(2*x)/(2+D(2*x)) would also work for all x >= 0.  Comment By: Robert Dodier (robert_dodier) Date: 20080326 23:39 Message: Logged In: YES user_id=501686 Originator: YES About D(2*x)/(2+D(2*x)), it seems like that is susceptible to overflow just like the current implementation. Rewriting with negative exponents might help, although Clisp seems to cough up an underflow error for the exponential of a large negative exponent. There are probably asymptotic series or rational function approximations or some other formulas in A&S; I haven't looked.  Comment By: Raymond Toy (rtoy) Date: 20080326 22:17 Message: Logged In: YES user_id=28849 Originator: NO A reasonable way for computing tanh(x): if x < 0 then tanh(x) if x >= 0 then D(2*x)/(2+D(2*x)) where D(x) = exp(x)  1. It looks like F_expx_F computes exp(x). I think a minor tweak will produce exp(x)1. I can help implement this if someone helps me understand how the internals work.  Comment By: Sam Steingold (sds) Date: 20070319 15:47 Message: Logged In: YES user_id=5735 Originator: NO OK, so this is not a bug but a feature request  http://www.cygwin.com/acronyms/#PTC while you are at it, please also take a look at https://sourceforge.net/tracker/index.php?func=detail&aid=1007358&group_id=1355&atid=101355  Comment By: Robert Dodier (robert_dodier) Date: 20070319 15:40 Message: Logged In: YES user_id=501686 Originator: YES "(exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than mostpositivedoublefloat (1.7976931348623157E308) thus you cannot expect tanh to work on this number for D, F, S." Um, this only shows that computing tanh from (exp(x)  exp(x))/(exp(x) + exp(x)) isn't always a good idea. There are other formulas. If nothing else, Clisp could check the argument to see if abs(x) > (some precisiondependent limit) and return 1 in that case. Probably if x is complex the test would be on abs(Re(x)) although I don't know off the top of my head what the appropriate result is.  Comment By: Sam Steingold (sds) Date: 20070319 10:19 Message: Logged In: YES user_id=5735 Originator: NO (exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than mostpositivedoublefloat (1.7976931348623157E308) thus you cannot expect tanh to work on this number for D, F, S. the reason (TANH 1.0d3) works is that cosh and sinh are computed (and divided) in long precision and then the result is converted to doubles, so it works "through the back door".  Comment By: Sam Steingold (sds) Date: 20070319 10:19 Message: Logged In: YES user_id=5735 Originator: NO This bug report is now marked as "pending"/"invalid". This means that we think that the problem you report is not a problem with CLISP. Unless you  the reporter  act within 2 weeks, the bug will be permanently closed. Sorry about the inconvenience  we hope your silence means that you agree that this is not a bug in CLISP.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1683394&group_id=1355 
From: SourceForge.net <noreply@so...>  20080327 19:15:57

Bugs item #1683394, was opened at 20070319 01:01 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1683394&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: lisp error Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Sam Steingold (sds) Summary: TANH floating point overflow for large short or single float Initial Comment: (TANH 1.0s3) => floating point overflow (TANH 1.0f3) => floating point overflow (TANH 1.0d3) => 1.0d0 (OK) (TANH 1.0l3) => 1.0L0 (OK) Clisp 2.38 / Linux. I looked at the Changelog and didn't see anything about TANH. Hope this helps.  >Comment By: Sam Steingold (sds) Date: 20080327 15:15 Message: Logged In: YES user_id=5735 Originator: NO you are right, I now use the old method for small x. would you like to take a look at https://sourceforge.net/tracker/index.php?func=detail&aid=1684969&group_id=1355&atid=101355 ??  Comment By: Raymond Toy (rtoy) Date: 20080327 14:14 Message: Logged In: YES user_id=28849 Originator: NO >From the logs, I see you implemented this as (1exp(2*x))/(1+exp(2*x)). This fixes the overflow problem, but now you have an accuracy problem for x near 0 since exp(2*x) is approximately 1. I think you need to implement some variant of D(x) = exp(x)1 by modifying the exp function with the initial sum of 0 instead of 1. Then use D(2*x)/(2+D(2*x)) to compute tanh(x). Or for x small, say <= 1/2, use the original sinh/cosh, since clisp has an accurate sinh for small x.  Comment By: Sam Steingold (sds) Date: 20080327 12:42 Message: Logged In: YES user_id=5735 Originator: NO thank you for your bug report. the bug has been fixed in the CVS tree. you can either wait for the next release (recommended) or check out the current CVS tree (see http://clisp.cons.org) and build CLISP from the sources (be advised that between releases the CVS tree is very unstable and may not even build on your platform).  Comment By: Raymond Toy (rtoy) Date: 20080327 07:50 Message: Logged In: YES user_id=28849 Originator: NO Oops. That was for solving issues near 0, which clisp doesn't have. I think a better scheme would be (1exp(2*x))/(1+exp(2*x)) = 1  2*exp(2*x)/(1+exp(2*x)) for x >> 0. Just need to either turn off the underflow warning or check that x is so large that exp(2*x) would underflow to zero. I guess D(2*x)/(2+D(2*x)) would also work for all x >= 0.  Comment By: Robert Dodier (robert_dodier) Date: 20080326 23:39 Message: Logged In: YES user_id=501686 Originator: YES About D(2*x)/(2+D(2*x)), it seems like that is susceptible to overflow just like the current implementation. Rewriting with negative exponents might help, although Clisp seems to cough up an underflow error for the exponential of a large negative exponent. There are probably asymptotic series or rational function approximations or some other formulas in A&S; I haven't looked.  Comment By: Raymond Toy (rtoy) Date: 20080326 22:17 Message: Logged In: YES user_id=28849 Originator: NO A reasonable way for computing tanh(x): if x < 0 then tanh(x) if x >= 0 then D(2*x)/(2+D(2*x)) where D(x) = exp(x)  1. It looks like F_expx_F computes exp(x). I think a minor tweak will produce exp(x)1. I can help implement this if someone helps me understand how the internals work.  Comment By: Sam Steingold (sds) Date: 20070319 15:47 Message: Logged In: YES user_id=5735 Originator: NO OK, so this is not a bug but a feature request  http://www.cygwin.com/acronyms/#PTC while you are at it, please also take a look at https://sourceforge.net/tracker/index.php?func=detail&aid=1007358&group_id=1355&atid=101355  Comment By: Robert Dodier (robert_dodier) Date: 20070319 15:40 Message: Logged In: YES user_id=501686 Originator: YES "(exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than mostpositivedoublefloat (1.7976931348623157E308) thus you cannot expect tanh to work on this number for D, F, S." Um, this only shows that computing tanh from (exp(x)  exp(x))/(exp(x) + exp(x)) isn't always a good idea. There are other formulas. If nothing else, Clisp could check the argument to see if abs(x) > (some precisiondependent limit) and return 1 in that case. Probably if x is complex the test would be on abs(Re(x)) although I don't know off the top of my head what the appropriate result is.  Comment By: Sam Steingold (sds) Date: 20070319 10:19 Message: Logged In: YES user_id=5735 Originator: NO (exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than mostpositivedoublefloat (1.7976931348623157E308) thus you cannot expect tanh to work on this number for D, F, S. the reason (TANH 1.0d3) works is that cosh and sinh are computed (and divided) in long precision and then the result is converted to doubles, so it works "through the back door".  Comment By: Sam Steingold (sds) Date: 20070319 10:19 Message: Logged In: YES user_id=5735 Originator: NO This bug report is now marked as "pending"/"invalid". This means that we think that the problem you report is not a problem with CLISP. Unless you  the reporter  act within 2 weeks, the bug will be permanently closed. Sorry about the inconvenience  we hope your silence means that you agree that this is not a bug in CLISP.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1683394&group_id=1355 
From: <clispcvsrequest@li...>  20080327 19:08:35

Send clispcvs mailing list submissions to clispcvs@... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/clispcvs or, via email, send a message with subject or body 'help' to clispcvsrequest@... You can reach the person managing the list at clispcvsowner@... When replying, please edit your Subject line so it is more specific than "Re: Contents of clispcvs digest..." CLISP CVS commits for today Today's Topics: 1. clisp/src realtran.d, 1.27, 1.28 NEWS, 1.432, 1.433 ChangeLog, 1.6097, 1.6098 (Sam Steingold) 2. clisp/tests number2.tst,1.41,1.42 ChangeLog,1.535,1.536 (Sam Steingold)  Message: 1 Date: Thu, 27 Mar 2008 16:43:02 +0000 From: Sam Steingold <sds@...> Subject: clisp/src realtran.d, 1.27, 1.28 NEWS, 1.432, 1.433 ChangeLog, 1.6097, 1.6098 To: clispcvs@... MessageID: <E1JevBw0000KbJe@...> Update of /cvsroot/clisp/clisp/src In directory sc8prcvs4.sourceforge.net:/tmp/cvsserv20628/src Modified Files: realtran.d NEWS ChangeLog Log Message: fix bug #[ 1683394 ]: TANH floating point overflow for large floats (posF_tanh_posF): new function: 1exp(2x)/1+exp(2x) (R_tanh_R): use it instead of R_cosh_sinh_R_R Index: NEWS =================================================================== RCS file: /cvsroot/clisp/clisp/src/NEWS,v retrieving revision 1.432 retrieving revision 1.433 diff u d r1.432 r1.433  NEWS 24 Mar 2008 18:03:40 0000 1.432 +++ NEWS 27 Mar 2008 16:42:59 0000 1.433 @@ 41,7 +41,7 @@ + Fix handling of quoted objects by READPRESERVINGWHITESPACE. [ 1890854 ] + Fix rectangle count in NEWCLX XLIB:SETGCONTEXTCLIPMASK. [ 1918017 ] + Fix compilation on systems not supporting returning void. [ 1924506 ]  + + Fix TANH floating point overflow for large floats. [ 1683394 ] 2.44.1 (20080223) =================== Index: realtran.d =================================================================== RCS file: /cvsroot/clisp/clisp/src/realtran.d,v retrieving revision 1.27 retrieving revision 1.28 diff u d r1.27 r1.28  realtran.d 27 Jan 2008 20:02:53 0000 1.27 +++ realtran.d 27 Mar 2008 16:42:59 0000 1.28 @@ 1122,8 +1122,7 @@ if e>0: y:=exp(x) calculate, (scalefloat ( y (/ y)) 1) bilden. */ local maygc object R_sinh_R (object x) {  if (R_rationalp(x)) {  /* x rational */ + if (R_rationalp(x)) { /* x rational */ if (eq(x,Fixnum_0)) /* x=0 > 0 as result */ return x; x = RA_float_F(x); /* otherwise convert to Float */ @@ 1139,8 +1138,7 @@ temp = F_F_float_F(temp,STACK_1); /* and round again */ skipSTACK(2); return temp;  } else {  /* e > 0 > use exp(x) */ + } else { /* e > 0 > use exp(x) */ var object temp; pushSTACK(x); pushSTACK(temp = R_exp_R(x,true,NULL)); /* y:=exp(x) */ @@ 1167,16 +1165,14 @@ if e>0: calculate y:=exp(x), (scalefloat (+ y (/ y)) 1) bilden. */ local maygc object R_cosh_R (object x) {  if (R_rationalp(x)) {  /* x rational */ + if (R_rationalp(x)) { /* x rational */ if (eq(x,Fixnum_0)) /* x=0 > 1 as result */ return Fixnum_1; x = RA_float_F(x); /* otherwise convert to float */ } /* x float */ var sintL e = F_exponent_L(x);  if (e > 0) {  /* e>0 > use exp(x) */ + if (e > 0) { /* e>0 > use exp(x) */ var object temp; pushSTACK(x); pushSTACK(temp = R_exp_R(x,true,NULL)); /* y:=exp(x) */ @@ 1184,8 +1180,7 @@ temp = F_F_plus_F(popSTACK(),temp); /* add to y */ temp = F_I_scale_float_F(temp,Fixnum_minus1); /* (scalefloat 1) */ return F_F_float_F(temp,popSTACK());  } else {  /* e<=0 */ + } else { /* e<=0 */ if (R_zerop(x)) return I_F_float_F(Fixnum_1,x); { @@ 1215,7 +1210,7 @@ x rational > with x=0 (1,0) as result, otherwise convert x to float. x float > increase precision, e := exponent from (decodefloat x), d := (floatdigits x)  if x=0.0 oder e<=(1d)/2 liefere (1.0,x) + if x=0.0 or e<=(1d)/2 return (1.0,x) (because with e<=(1d)/2 follows 1 <= sinh(x)/x < cosh(x) = 1+x^2/2+... < 1+2^(d), so cosh(x), rounded to d bits, equals 1.0 @@ 1281,15 +1276,33 @@ /* R_tanh_R(x) compute the hyperbolic tangens (tanh x) of a real number x. can trigger GC  Method:  (/ (sinh x) (cosh x)) */ + Method: x = 0 => 0 + x < 0 =>  tanh(x) + x > 0 => 1  exp(2x) / 1 + exp(2x) + [[ (/ (sinh x) (cosh x))  leads to FP overflow [ 1683394 ] ]] */ +local maygc object posF_tanh_posF (object x) { + pushSTACK(x); /* save to be able to restore precision */ + dynamic_bind(S(inhibit_floating_point_underflow),T); + x = R_exp_R(F_I_scale_float_F(F_minus_F(x),Fixnum_1),true,NULL); + dynamic_unbind(S(inhibit_floating_point_underflow)); + if (R_zerop(x)) return I_F_float_F(Fixnum_1,popSTACK()); + pushSTACK(x); pushSTACK(NIL); pushSTACK(NIL); pushSTACK(NIL); + STACK_2 = I_F_float_F(Fixnum_1,STACK_3); + STACK_1 = F_F_minus_F(STACK_2,STACK_3); + STACK_0 = F_F_plus_F(STACK_2,STACK_3); + /* STACK: x, e^2x, 1.0, 1e^2x, 1+e^2x */ + x = F_F_div_F(STACK_1,STACK_0); + skipSTACK(4); + return F_F_float_F(x,popSTACK()); +} local maygc object R_tanh_R (object x) {  pushSTACK(x);  R_cosh_sinh_R_R(x,NULL);  /* stack layout: x, cosh(x), sinh(x). */  var object result = R_R_div_R(STACK_0,STACK_1);  if (floatp(STACK_0)  floatp(STACK_1))  result = F_R_float_F(result,STACK_2); /* reduce precision */  skipSTACK(3); return result; + if (R_rationalp(x)) { /* x rational */ + if (eq(x,Fixnum_0)) /* x=0 > 0 */ + return Fixnum_0; + x = RA_float_F(x); /* ==> Float */ + } + /* x  float */ + return positivep(x) ? posF_tanh_posF(x) + : F_minus_F(posF_tanh_posF(F_minus_F(x))); } Index: ChangeLog =================================================================== RCS file: /cvsroot/clisp/clisp/src/ChangeLog,v retrieving revision 1.6097 retrieving revision 1.6098 diff u d r1.6097 r1.6098  ChangeLog 26 Mar 2008 21:02:47 0000 1.6097 +++ ChangeLog 27 Mar 2008 16:42:59 0000 1.6098 @@ 1,3 +1,9 @@ +20080327 Sam Steingold <sds@...> + + fix bug #[ 1683394 ]: TANH floating point overflow for large floats + * realtran.d (posF_tanh_posF): new function: 1exp(2x)/1+exp(2x) + (R_tanh_R): use it instead of R_cosh_sinh_R_R + 20080325 Sam Steingold <sds@...> * array.d, control.d, debug.d, eval.d, execname.c, hashtabl.d: @@ 17,19 +23,19 @@ 20080325 Sam Steingold <sds@...>  fix bug [ 1924501 ]: cannot find gllib include + fix bug #[ 1924501 ]: cannot find gllib include * makemake.in (CPPFLAGS): pass Igllib here, not CFLAGS 20080324 Vladimir Volovich <vvv2@...> Sam Steingold <sds@...>  fix bug [ 1924508 ]: undefined symbol getSP when linking lisp.run + fix bug #[ 1924508 ]: undefined symbol getSP when linking lisp.run on Sparc Solaris 2.8 using Sun Studio 11 * spsparc.d, spsparc64.d: add global getSP 20080324 Sam Steingold <sds@...>  fix bug [ 1924506 ]: void function cannot return value + fix bug #[ 1924506 ]: void function cannot return value * foreign.d (convert_to_foreign): "return void" does not work on Solaris 2.8 @@ 90,7 +96,7 @@ 20080318 Drutsa Pavel <rawlik@...>  fix bug [ 1918017 ]: newclx:gcontextclipmask does not set rectangles + fix bug #[ 1918017 ]: newclx:gcontextclipmask does not set rectangles * modules/clx/newclx/clx.f (XLIB:SETGCONTEXTCLIPMASK): do not divide n by 4 when passing to XSetClipRectangles  it has already been done by get_seq_len()  Message: 2 Date: Thu, 27 Mar 2008 16:43:01 +0000 From: Sam Steingold <sds@...> Subject: clisp/tests number2.tst,1.41,1.42 ChangeLog,1.535,1.536 To: clispcvs@... MessageID: <E1JevBw0000KSJD@...> Update of /cvsroot/clisp/clisp/tests In directory sc8prcvs4.sourceforge.net:/tmp/cvsserv20628/tests Modified Files: number2.tst ChangeLog Log Message: fix bug #[ 1683394 ]: TANH floating point overflow for large floats (posF_tanh_posF): new function: 1exp(2x)/1+exp(2x) (R_tanh_R): use it instead of R_cosh_sinh_R_R Index: number2.tst =================================================================== RCS file: /cvsroot/clisp/clisp/tests/number2.tst,v retrieving revision 1.41 retrieving revision 1.42 diff u d r1.41 r1.42  number2.tst 7 Oct 2007 01:00:15 0000 1.41 +++ number2.tst 27 Mar 2008 16:42:59 0000 1.42 @@ 501,3 +501,21 @@ :for b1 = (logxor b (ash 1 (floor (integerlength b) 2))) :for s1 = (sxhash b1) :when (= s s1) :collect (list b s b1 s1)) NIL + +;; https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1683394&group_id=1355 +(tanh 1s13) 1s0 +(tanh 1s3) 1s0 +(tanh 1s2) 1s0 +(tanh 1s1) 1s0 +(tanh 1s0) 0.7616s0 +(tanh 1f0) 0.7615942 +(tanh 1d0) 0.7615941559557649d0 +(tanh 1l0) 0.7615941559557648881L0 +(tanh 1f1) 1f0 +(tanh 1d1) 0.9999999958776927d0 +(tanh 1l1) 0.9999999958776927636L0 +(tanh 1l100) 1L0 +(tanh 1d100) 1d0 +(tanh 1f10) 1f0 +(tanh 1s10) 1s0 + Index: ChangeLog =================================================================== RCS file: /cvsroot/clisp/clisp/tests/ChangeLog,v retrieving revision 1.535 retrieving revision 1.536 diff u d r1.535 r1.536  ChangeLog 18 Mar 2008 20:37:42 0000 1.535 +++ ChangeLog 27 Mar 2008 16:42:59 0000 1.536 @@ 1,3 +1,8 @@ +20080327 Sam Steingold <sds@...> + + * number2.tst: add tests for bug #[ 1683394 ]: + TANH floating point overflow for large floats + 20080318 Sam Steingold <sds@...> * ffi.tst: update tests for versioned symbols   Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace  _______________________________________________ clispcvs mailing list clispcvs@... https://lists.sourceforge.net/lists/listinfo/clispcvs End of clispcvs Digest, Vol 23, Issue 27 ***************************************** 
From: SourceForge.net <noreply@so...>  20080327 18:14:54

Bugs item #1683394, was opened at 20070319 01:01 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1683394&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: lisp error Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Sam Steingold (sds) Summary: TANH floating point overflow for large short or single float Initial Comment: (TANH 1.0s3) => floating point overflow (TANH 1.0f3) => floating point overflow (TANH 1.0d3) => 1.0d0 (OK) (TANH 1.0l3) => 1.0L0 (OK) Clisp 2.38 / Linux. I looked at the Changelog and didn't see anything about TANH. Hope this helps.  Comment By: Raymond Toy (rtoy) Date: 20080327 14:14 Message: Logged In: YES user_id=28849 Originator: NO >From the logs, I see you implemented this as (1exp(2*x))/(1+exp(2*x)). This fixes the overflow problem, but now you have an accuracy problem for x near 0 since exp(2*x) is approximately 1. I think you need to implement some variant of D(x) = exp(x)1 by modifying the exp function with the initial sum of 0 instead of 1. Then use D(2*x)/(2+D(2*x)) to compute tanh(x). Or for x small, say <= 1/2, use the original sinh/cosh, since clisp has an accurate sinh for small x.  Comment By: Sam Steingold (sds) Date: 20080327 12:42 Message: Logged In: YES user_id=5735 Originator: NO thank you for your bug report. the bug has been fixed in the CVS tree. you can either wait for the next release (recommended) or check out the current CVS tree (see http://clisp.cons.org) and build CLISP from the sources (be advised that between releases the CVS tree is very unstable and may not even build on your platform).  Comment By: Raymond Toy (rtoy) Date: 20080327 07:50 Message: Logged In: YES user_id=28849 Originator: NO Oops. That was for solving issues near 0, which clisp doesn't have. I think a better scheme would be (1exp(2*x))/(1+exp(2*x)) = 1  2*exp(2*x)/(1+exp(2*x)) for x >> 0. Just need to either turn off the underflow warning or check that x is so large that exp(2*x) would underflow to zero. I guess D(2*x)/(2+D(2*x)) would also work for all x >= 0.  Comment By: Robert Dodier (robert_dodier) Date: 20080326 23:39 Message: Logged In: YES user_id=501686 Originator: YES About D(2*x)/(2+D(2*x)), it seems like that is susceptible to overflow just like the current implementation. Rewriting with negative exponents might help, although Clisp seems to cough up an underflow error for the exponential of a large negative exponent. There are probably asymptotic series or rational function approximations or some other formulas in A&S; I haven't looked.  Comment By: Raymond Toy (rtoy) Date: 20080326 22:17 Message: Logged In: YES user_id=28849 Originator: NO A reasonable way for computing tanh(x): if x < 0 then tanh(x) if x >= 0 then D(2*x)/(2+D(2*x)) where D(x) = exp(x)  1. It looks like F_expx_F computes exp(x). I think a minor tweak will produce exp(x)1. I can help implement this if someone helps me understand how the internals work.  Comment By: Sam Steingold (sds) Date: 20070319 15:47 Message: Logged In: YES user_id=5735 Originator: NO OK, so this is not a bug but a feature request  http://www.cygwin.com/acronyms/#PTC while you are at it, please also take a look at https://sourceforge.net/tracker/index.php?func=detail&aid=1007358&group_id=1355&atid=101355  Comment By: Robert Dodier (robert_dodier) Date: 20070319 15:40 Message: Logged In: YES user_id=501686 Originator: YES "(exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than mostpositivedoublefloat (1.7976931348623157E308) thus you cannot expect tanh to work on this number for D, F, S." Um, this only shows that computing tanh from (exp(x)  exp(x))/(exp(x) + exp(x)) isn't always a good idea. There are other formulas. If nothing else, Clisp could check the argument to see if abs(x) > (some precisiondependent limit) and return 1 in that case. Probably if x is complex the test would be on abs(Re(x)) although I don't know off the top of my head what the appropriate result is.  Comment By: Sam Steingold (sds) Date: 20070319 10:19 Message: Logged In: YES user_id=5735 Originator: NO (exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than mostpositivedoublefloat (1.7976931348623157E308) thus you cannot expect tanh to work on this number for D, F, S. the reason (TANH 1.0d3) works is that cosh and sinh are computed (and divided) in long precision and then the result is converted to doubles, so it works "through the back door".  Comment By: Sam Steingold (sds) Date: 20070319 10:19 Message: Logged In: YES user_id=5735 Originator: NO This bug report is now marked as "pending"/"invalid". This means that we think that the problem you report is not a problem with CLISP. Unless you  the reporter  act within 2 weeks, the bug will be permanently closed. Sorry about the inconvenience  we hope your silence means that you agree that this is not a bug in CLISP.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1683394&group_id=1355 
From: SourceForge.net <noreply@so...>  20080327 17:19:40

Bugs item #1684969, was opened at 20070321 04:08 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1684969&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: lisp error Status: Open Resolution: None Priority: 5 Private: No Submitted By: Aleksander Nabaglo (anab) Assigned to: Bruno Haible (haible) Summary: numerical inaccuracy in cos or sin Initial Comment: Slow 256 point Hartley Transfom exhibits numerical 10^2 relative inaccuracy at points 4, 8, 16, 29, 32, 58, 116. Slow 255 point HT does not exhibit numerical inaccuracies. Probably problem with sin/cos evaluated near integer * PI /2. Attached test code, results from clisp2.41 and sbcl1.0.3.  >Comment By: Sam Steingold (sds) Date: 20080327 13:19 Message: Logged In: YES user_id=5735 Originator: NO it would be nice to see a smaller test case.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1684969&group_id=1355 
From: SourceForge.net <noreply@so...>  20080327 16:43:08

Bugs item #1683394, was opened at 20070319 01:01 Message generated for change (Comment added) made by sds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1683394&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: lisp error >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Sam Steingold (sds) Summary: TANH floating point overflow for large short or single float Initial Comment: (TANH 1.0s3) => floating point overflow (TANH 1.0f3) => floating point overflow (TANH 1.0d3) => 1.0d0 (OK) (TANH 1.0l3) => 1.0L0 (OK) Clisp 2.38 / Linux. I looked at the Changelog and didn't see anything about TANH. Hope this helps.  Comment By: Sam Steingold (sds) Date: 20080327 12:42 Message: Logged In: YES user_id=5735 Originator: NO thank you for your bug report. the bug has been fixed in the CVS tree. you can either wait for the next release (recommended) or check out the current CVS tree (see http://clisp.cons.org) and build CLISP from the sources (be advised that between releases the CVS tree is very unstable and may not even build on your platform).  Comment By: Raymond Toy (rtoy) Date: 20080327 07:50 Message: Logged In: YES user_id=28849 Originator: NO Oops. That was for solving issues near 0, which clisp doesn't have. I think a better scheme would be (1exp(2*x))/(1+exp(2*x)) = 1  2*exp(2*x)/(1+exp(2*x)) for x >> 0. Just need to either turn off the underflow warning or check that x is so large that exp(2*x) would underflow to zero. I guess D(2*x)/(2+D(2*x)) would also work for all x >= 0.  Comment By: Robert Dodier (robert_dodier) Date: 20080326 23:39 Message: Logged In: YES user_id=501686 Originator: YES About D(2*x)/(2+D(2*x)), it seems like that is susceptible to overflow just like the current implementation. Rewriting with negative exponents might help, although Clisp seems to cough up an underflow error for the exponential of a large negative exponent. There are probably asymptotic series or rational function approximations or some other formulas in A&S; I haven't looked.  Comment By: Raymond Toy (rtoy) Date: 20080326 22:17 Message: Logged In: YES user_id=28849 Originator: NO A reasonable way for computing tanh(x): if x < 0 then tanh(x) if x >= 0 then D(2*x)/(2+D(2*x)) where D(x) = exp(x)  1. It looks like F_expx_F computes exp(x). I think a minor tweak will produce exp(x)1. I can help implement this if someone helps me understand how the internals work.  Comment By: Sam Steingold (sds) Date: 20070319 15:47 Message: Logged In: YES user_id=5735 Originator: NO OK, so this is not a bug but a feature request  http://www.cygwin.com/acronyms/#PTC while you are at it, please also take a look at https://sourceforge.net/tracker/index.php?func=detail&aid=1007358&group_id=1355&atid=101355  Comment By: Robert Dodier (robert_dodier) Date: 20070319 15:40 Message: Logged In: YES user_id=501686 Originator: YES "(exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than mostpositivedoublefloat (1.7976931348623157E308) thus you cannot expect tanh to work on this number for D, F, S." Um, this only shows that computing tanh from (exp(x)  exp(x))/(exp(x) + exp(x)) isn't always a good idea. There are other formulas. If nothing else, Clisp could check the argument to see if abs(x) > (some precisiondependent limit) and return 1 in that case. Probably if x is complex the test would be on abs(Re(x)) although I don't know off the top of my head what the appropriate result is.  Comment By: Sam Steingold (sds) Date: 20070319 10:19 Message: Logged In: YES user_id=5735 Originator: NO (exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than mostpositivedoublefloat (1.7976931348623157E308) thus you cannot expect tanh to work on this number for D, F, S. the reason (TANH 1.0d3) works is that cosh and sinh are computed (and divided) in long precision and then the result is converted to doubles, so it works "through the back door".  Comment By: Sam Steingold (sds) Date: 20070319 10:19 Message: Logged In: YES user_id=5735 Originator: NO This bug report is now marked as "pending"/"invalid". This means that we think that the problem you report is not a problem with CLISP. Unless you  the reporter  act within 2 weeks, the bug will be permanently closed. Sorry about the inconvenience  we hope your silence means that you agree that this is not a bug in CLISP.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1683394&group_id=1355 
From: SourceForge.net <noreply@so...>  20080327 11:50:06

Bugs item #1683394, was opened at 20070319 01:01 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1683394&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: lisp error Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Sam Steingold (sds) Summary: TANH floating point overflow for large short or single float Initial Comment: (TANH 1.0s3) => floating point overflow (TANH 1.0f3) => floating point overflow (TANH 1.0d3) => 1.0d0 (OK) (TANH 1.0l3) => 1.0L0 (OK) Clisp 2.38 / Linux. I looked at the Changelog and didn't see anything about TANH. Hope this helps.  Comment By: Raymond Toy (rtoy) Date: 20080327 07:50 Message: Logged In: YES user_id=28849 Originator: NO Oops. That was for solving issues near 0, which clisp doesn't have. I think a better scheme would be (1exp(2*x))/(1+exp(2*x)) = 1  2*exp(2*x)/(1+exp(2*x)) for x >> 0. Just need to either turn off the underflow warning or check that x is so large that exp(2*x) would underflow to zero. I guess D(2*x)/(2+D(2*x)) would also work for all x >= 0.  Comment By: Robert Dodier (robert_dodier) Date: 20080326 23:39 Message: Logged In: YES user_id=501686 Originator: YES About D(2*x)/(2+D(2*x)), it seems like that is susceptible to overflow just like the current implementation. Rewriting with negative exponents might help, although Clisp seems to cough up an underflow error for the exponential of a large negative exponent. There are probably asymptotic series or rational function approximations or some other formulas in A&S; I haven't looked.  Comment By: Raymond Toy (rtoy) Date: 20080326 22:17 Message: Logged In: YES user_id=28849 Originator: NO A reasonable way for computing tanh(x): if x < 0 then tanh(x) if x >= 0 then D(2*x)/(2+D(2*x)) where D(x) = exp(x)  1. It looks like F_expx_F computes exp(x). I think a minor tweak will produce exp(x)1. I can help implement this if someone helps me understand how the internals work.  Comment By: Sam Steingold (sds) Date: 20070319 15:47 Message: Logged In: YES user_id=5735 Originator: NO OK, so this is not a bug but a feature request  http://www.cygwin.com/acronyms/#PTC while you are at it, please also take a look at https://sourceforge.net/tracker/index.php?func=detail&aid=1007358&group_id=1355&atid=101355  Comment By: Robert Dodier (robert_dodier) Date: 20070319 15:40 Message: Logged In: YES user_id=501686 Originator: YES "(exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than mostpositivedoublefloat (1.7976931348623157E308) thus you cannot expect tanh to work on this number for D, F, S." Um, this only shows that computing tanh from (exp(x)  exp(x))/(exp(x) + exp(x)) isn't always a good idea. There are other formulas. If nothing else, Clisp could check the argument to see if abs(x) > (some precisiondependent limit) and return 1 in that case. Probably if x is complex the test would be on abs(Re(x)) although I don't know off the top of my head what the appropriate result is.  Comment By: Sam Steingold (sds) Date: 20070319 10:19 Message: Logged In: YES user_id=5735 Originator: NO (exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than mostpositivedoublefloat (1.7976931348623157E308) thus you cannot expect tanh to work on this number for D, F, S. the reason (TANH 1.0d3) works is that cosh and sinh are computed (and divided) in long precision and then the result is converted to doubles, so it works "through the back door".  Comment By: Sam Steingold (sds) Date: 20070319 10:19 Message: Logged In: YES user_id=5735 Originator: NO This bug report is now marked as "pending"/"invalid". This means that we think that the problem you report is not a problem with CLISP. Unless you  the reporter  act within 2 weeks, the bug will be permanently closed. Sorry about the inconvenience  we hope your silence means that you agree that this is not a bug in CLISP.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1683394&group_id=1355 
From: SourceForge.net <noreply@so...>  20080327 03:39:25

Bugs item #1683394, was opened at 20070318 23:01 Message generated for change (Comment added) made by robert_dodier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1683394&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: lisp error Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Sam Steingold (sds) Summary: TANH floating point overflow for large short or single float Initial Comment: (TANH 1.0s3) => floating point overflow (TANH 1.0f3) => floating point overflow (TANH 1.0d3) => 1.0d0 (OK) (TANH 1.0l3) => 1.0L0 (OK) Clisp 2.38 / Linux. I looked at the Changelog and didn't see anything about TANH. Hope this helps.  >Comment By: Robert Dodier (robert_dodier) Date: 20080326 21:39 Message: Logged In: YES user_id=501686 Originator: YES About D(2*x)/(2+D(2*x)), it seems like that is susceptible to overflow just like the current implementation. Rewriting with negative exponents might help, although Clisp seems to cough up an underflow error for the exponential of a large negative exponent. There are probably asymptotic series or rational function approximations or some other formulas in A&S; I haven't looked.  Comment By: Raymond Toy (rtoy) Date: 20080326 20:17 Message: Logged In: YES user_id=28849 Originator: NO A reasonable way for computing tanh(x): if x < 0 then tanh(x) if x >= 0 then D(2*x)/(2+D(2*x)) where D(x) = exp(x)  1. It looks like F_expx_F computes exp(x). I think a minor tweak will produce exp(x)1. I can help implement this if someone helps me understand how the internals work.  Comment By: Sam Steingold (sds) Date: 20070319 13:47 Message: Logged In: YES user_id=5735 Originator: NO OK, so this is not a bug but a feature request  http://www.cygwin.com/acronyms/#PTC while you are at it, please also take a look at https://sourceforge.net/tracker/index.php?func=detail&aid=1007358&group_id=1355&atid=101355  Comment By: Robert Dodier (robert_dodier) Date: 20070319 13:40 Message: Logged In: YES user_id=501686 Originator: YES "(exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than mostpositivedoublefloat (1.7976931348623157E308) thus you cannot expect tanh to work on this number for D, F, S." Um, this only shows that computing tanh from (exp(x)  exp(x))/(exp(x) + exp(x)) isn't always a good idea. There are other formulas. If nothing else, Clisp could check the argument to see if abs(x) > (some precisiondependent limit) and return 1 in that case. Probably if x is complex the test would be on abs(Re(x)) although I don't know off the top of my head what the appropriate result is.  Comment By: Sam Steingold (sds) Date: 20070319 08:19 Message: Logged In: YES user_id=5735 Originator: NO (exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than mostpositivedoublefloat (1.7976931348623157E308) thus you cannot expect tanh to work on this number for D, F, S. the reason (TANH 1.0d3) works is that cosh and sinh are computed (and divided) in long precision and then the result is converted to doubles, so it works "through the back door".  Comment By: Sam Steingold (sds) Date: 20070319 08:19 Message: Logged In: YES user_id=5735 Originator: NO This bug report is now marked as "pending"/"invalid". This means that we think that the problem you report is not a problem with CLISP. Unless you  the reporter  act within 2 weeks, the bug will be permanently closed. Sorry about the inconvenience  we hope your silence means that you agree that this is not a bug in CLISP.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1683394&group_id=1355 
From: SourceForge.net <noreply@so...>  20080327 02:17:52

Bugs item #1683394, was opened at 20070319 01:01 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1683394&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: lisp error Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Dodier (robert_dodier) Assigned to: Sam Steingold (sds) Summary: TANH floating point overflow for large short or single float Initial Comment: (TANH 1.0s3) => floating point overflow (TANH 1.0f3) => floating point overflow (TANH 1.0d3) => 1.0d0 (OK) (TANH 1.0l3) => 1.0L0 (OK) Clisp 2.38 / Linux. I looked at the Changelog and didn't see anything about TANH. Hope this helps.  Comment By: Raymond Toy (rtoy) Date: 20080326 22:17 Message: Logged In: YES user_id=28849 Originator: NO A reasonable way for computing tanh(x): if x < 0 then tanh(x) if x >= 0 then D(2*x)/(2+D(2*x)) where D(x) = exp(x)  1. It looks like F_expx_F computes exp(x). I think a minor tweak will produce exp(x)1. I can help implement this if someone helps me understand how the internals work.  Comment By: Sam Steingold (sds) Date: 20070319 15:47 Message: Logged In: YES user_id=5735 Originator: NO OK, so this is not a bug but a feature request  http://www.cygwin.com/acronyms/#PTC while you are at it, please also take a look at https://sourceforge.net/tracker/index.php?func=detail&aid=1007358&group_id=1355&atid=101355  Comment By: Robert Dodier (robert_dodier) Date: 20070319 15:40 Message: Logged In: YES user_id=501686 Originator: YES "(exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than mostpositivedoublefloat (1.7976931348623157E308) thus you cannot expect tanh to work on this number for D, F, S." Um, this only shows that computing tanh from (exp(x)  exp(x))/(exp(x) + exp(x)) isn't always a good idea. There are other formulas. If nothing else, Clisp could check the argument to see if abs(x) > (some precisiondependent limit) and return 1 in that case. Probably if x is complex the test would be on abs(Re(x)) although I don't know off the top of my head what the appropriate result is.  Comment By: Sam Steingold (sds) Date: 20070319 10:19 Message: Logged In: YES user_id=5735 Originator: NO (exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than mostpositivedoublefloat (1.7976931348623157E308) thus you cannot expect tanh to work on this number for D, F, S. the reason (TANH 1.0d3) works is that cosh and sinh are computed (and divided) in long precision and then the result is converted to doubles, so it works "through the back door".  Comment By: Sam Steingold (sds) Date: 20070319 10:19 Message: Logged In: YES user_id=5735 Originator: NO This bug report is now marked as "pending"/"invalid". This means that we think that the problem you report is not a problem with CLISP. Unless you  the reporter  act within 2 weeks, the bug will be permanently closed. Sorry about the inconvenience  we hope your silence means that you agree that this is not a bug in CLISP.  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1683394&group_id=1355 
From: SourceForge.net <noreply@so...>  20080327 01:12:51

Bugs item #1924508, was opened at 20080324 13:46 Message generated for change (Comment added) made by rtoy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1924508&group_id=1355 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: clisp Group: build problems Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Vladimir Volovich (vvv2) Assigned to: Sam Steingold (sds) Summary: undefined symbol getSP when linking lisp.run Initial Comment: when building clisp2.44.1 on Sparc Solaris 2.8 using Sun Studio 11 compiler, i get an error: cc dalign fsingle DUNIX_BINARY_DISTRIB DUNICODE DDYNAMIC_FFI DNO_GETTEXT I. Igllib spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o funarg.o array.o hashtabl.o list.o package.o record.o weak.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o foreign.o unixaux.o built.o arisparc.o spsparc.o gllib/uniwidth/width.o gllib/uniname/uniname.o gllib/localcharset.o modules.o ltermcap ldl lnsl lsocket /opt/home/vvv/src/inst/lib/libavcall.a /opt/home/vvv/src/inst/lib/libcallback.a L/opt/home/vvv/src/inst/lib lsigsegv lc o lisp.run Undefined first referenced symbol in file getSP spvw.o ld: fatal: Symbol referencing errors. No output written to lisp.run that happens because the generated spsparc.o does not contain this symbol: $ nm spsparc.o spsparc.o: [Index] Value Size Type Bind Other Shndx Name [1]  0 0SECT LOCL 0 2  [2]  8 0NOTY GLOB 0 2 __get_g1 [3]  0 0NOTY GLOB 0 2 _getSP [4]  8 0NOTY GLOB 0 2 _get_g1 it is generated with these commands: cc E spsparc.c  grep v '^#'  grep v '^ *#line'  sed e 's,% ,%,g' e 's,\. ,.,g' > spsparc.s cc I/opt/home/vvv/src/inst/include dalign fsingle DUNIX_BINARY_DISTRIB DUNICODE DDYNAMIC_FFI DNO_GETTEXT I. Igllib c spsparc.s If i modify spsparc.d using this patch:  spsparc.d~ +++ spsparc.d @@ 9,6 +9,7 @@ .seg "text" + .global getSP .global _getSP .global _get_g1 .global __get_g1 it links without errors.  Comment By: Raymond Toy (rtoy) Date: 20080326 21:12 Message: Logged In: YES user_id=28849 Originator: NO The retl instruction (really some kind of jump instruction) has a single delay slot, so the next instruction is also executed. This allows something useful to be done as the pipelines and stuff are flushed for the jump.  Comment By: Vladimir Volovich (vvv2) Date: 20080324 15:43 Message: Logged In: YES user_id=1804953 Originator: YES BTW, i did not mention that i'm not an expert in sparc assembly language. :) my patch was just a naive attempt to fix a compilation issue. (i know intel assembly to some extent). in fact, looking at spsparc.d, it looks a bit weird to me, as the code looks like: _getSP: retl _ mov %sp,%o0 and __get_g1: retl _ mov %g1,%o0 because the mov instructions which supposedly should load the return value into the register occur *after* the return instructions. so how they will ever be executed?  Comment By: Sam Steingold (sds) Date: 20080324 14:26 Message: Logged In: YES user_id=5735 Originator: NO thank you for your bug report. the bug has been fixed in the CVS tree. you can either wait for the next release (recommended) or check out the current CVS tree (see http://clisp.cons.org) and build CLISP from the sources (be advised that between releases the CVS tree is very unstable and may not even build on your platform).  Comment By: Vladimir Volovich (vvv2) Date: 20080324 13:51 Message: Logged In: YES user_id=1804953 Originator: YES the patch i posted above is not correct  corrected version follows: =============================================  spsparc.d~ +++ spsparc.d @@ 9,11 +9,13 @@ .seg "text" + .global getSP .global _getSP .global _get_g1 .global __get_g1 # extern void* getSP (void); +getSP: _getSP: retl _ mov %sp,%o0 ============================================= with this patch, lisp.run successfully links (but there are other problems, reported in a separate bug report).  You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1924508&group_id=1355 