log/ln calculates not correct for large/tiny arguments

[Former user]

Originally reported on Google Code with ID 98

What steps will reproduce the problem?
1. log(1e100)
2.
3.

What is the expected output? What do you see instead?
expected 100, got something near 110

What version of the product are you using? On what operating system?
0.8 release, kubuntu

Please provide any additional information below.
the effect is noticeable from 1e87 on and gets really bad near the overflow
limit, when the log is almost twice the true value. A similiar effect can
be observed for arguments less than 1e-55. 

Reported by [e-mail] on 2007-07-27 14:26:38

[Former user]

``` I started my debugger and had a look at the problem. The reason for the failure is the sqrt function. sqrt(1e100) does not yield 1e50, as one might expect, but roughly 7e54. And because sqrt is used to reduce the argument of log, log fails as well. The sqrt algorithm is such that it converges sufficiently only when it is fed with a sane start value, meaning it is best chosen from near the final result. Unfortunately, it is always set to 1, and that's ways too far from the result 1e50. A very quick and dirty patch changes line 1333 in hmath.cpp to for( int i = 0; i < 2*HMATH_MAX_PREC; i++ ) That does not address the root of the problem, but is good enough to get away for the moment. Wolf Lammen ```

Reported by `[e-mail]` on 2007-07-27 20:59:33

[Former user]

``` Hi Wolf, how does your current floatnum merge compare to it? ```

Reported by `helder.pereira.correia` on 2007-07-27 21:09:03

[Former user]

``` floatnum does not have these problems. I carefully chose stable algorithms, and that means, I deal with the exponent first. Example: 2e101 is separated into 20 and 1e100. The square root of 1e100 is found by dividing the exponent by 2, yielding 1e50. And 20 enters the sqrt algorithm of bc_num, yielding 4.47.. So the end result is 4.47e50. In addition, floatnum avoids the square root as much as possible, because I know, it's a slow operation. So, logarithms are computed without using sqrt. (In the beginning, I checked the AGP algorithm to compute ln, which is based on successive application of sqrt. This algorithm is known to be faster than Taylor series for high precision calculation, but in the range of 100 digit results, it was 8 times slower) Wolf Lammen ```

Reported by `[e-mail]` on 2007-07-27 21:25:01

[Former user]

``` So do you perform range checking in any math function, then applying the fastest for each case? ```

Reported by `helder.pereira.correia` on 2007-07-27 21:39:02

[Former user]

``` That's right. Wolf Lammen ```

Reported by `[e-mail]` on 2007-07-27 21:48:42

[Former user]

``` fixed in trunk ```

Reported by `wolf.lammen` on 2007-08-08 21:20:26

[Former user]

``` Close the bug as it's fixed. ```

Reported by `ariya.hidayat` on 2007-08-09 10:54:03 - Status changed: `Fixed` - Labels added: Milestone-0.9

[Former user]

Reported by `helder.pereira.correia` on 2007-08-09 11:30:10