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 