Calculating e^x-1 on classic HPs

[Gerson W. Barbosa]

(01-15-2016 06:46 PM)Dieter Wrote:  

(01-15-2016 06:07 PM)Gerson W. Barbosa Wrote:  I'm currently running this on an ordinary 12C and Dieter's program on a 12C+, so I cannot compare speeds, but Dieter's should be slightly faster because it requires no tests.

Hm, seems you forgot an essential test here: if x is so small that e^x rounds to 1 (here –5 E–11 < x < 5 E–10), the term (u–1)/ln u becomes 0/0... #-) In such a case the program should return x. This additional test would also handle the x=0 case that's now tested in the first line.

BTW, W. Kahan's method is supposed to calculate (e^x–1)/x. Even if this quotient is evaluated exactly, i.e. for small x very close to 1, there is always a potential error of half an ULP or 5 E–10 on a ten-digit device. This translates to a possible error of up to 5 ULP in the final result, i.e. after the multiplication with x.

Example: x=9 E–9. The exact quotient is 1,000000045... which on a ten-digit calculator is rounded to 1,000000005. This indeed is the correctly rounded ten-digit value. But the final result is returned as 9,000000045 E–9 instead of 9,0000000405000...E–9, i.e. there is an error of +4,5 ULP.

So, it's better to stick as close as possible to the modified original algorithm:

Code:


% Algorithm 2.
y = e^x
if y = 1
   f = l
else
   f = (y - 1)/(log y)*x
end

Code:


01- ENTER
02- e^x
03- 1
04- CHS
05- x<>y 
06- +
07- x=0
08- GTO 14
09- LSTx
10- LN
11- /
12- *
13- x<>y
14- Rv
15- GTO 00

I'd imagined the final multiplication by x might be an issue, as you've pointed out, but in my (few) tests I didn't find significant differences compared to your results. The program is now two stpes longer and slightly slower than the previous one. Anyway, a good exercise after two cups of cheap Argentinian wine (they're still better than our finest ones :-)

Quoting Professor Kahan, as found in the book, perhaps applied to your proposed method:

"There will always be a small but steady demand for error-analysts to ...
expose bad algorithms' big errors and, more important,
supplant bad algorithms with provably good ones.
- WILLIAM M. KAHAN, Interval Arithmetic Options in the
Proposed IEEE Floating Point Arithmetic Standard (1980)"

Gerson.