## [ clisp-Bugs-1683394 ] TANH floating point overflow for large short or single float

 [ clisp-Bugs-1683394 ] TANH floating point overflow for large short or single float From: SourceForge.net - 2008-03-27 11:50:06 ```Bugs item #1683394, was opened at 2007-03-19 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: 2008-03-27 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 (1-exp(-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: 2008-03-26 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: 2008-03-26 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: 2007-03-19 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: 2007-03-19 15:40 Message: Logged In: YES user_id=501686 Originator: YES "(exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than most-positive-double-float (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 precision-dependent 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: 2007-03-19 10:19 Message: Logged In: YES user_id=5735 Originator: NO (exp 1.0l3) ==> 1.9700711140170469939L434 which is bigger than most-positive-double-float (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: 2007-03-19 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 ```