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 