Why does my calculator compute ln(5) faster than ln(e)?

[NoOne0507]

Straightforward question for anyone who knows how calculators work.

 

[mariush]

First thought. 5 is a simple integrer. e is calculated as a limit or by series expansion.

 

[dextercioby]

Yes, I think it's a reasonable explanation. The ln is computed using the power series, so it's considerably faster with natural numbers.

 

[NoOne0507]

Okay. Makes sense, thanks.

 

[Borek]

You think there is a separate code for calculating logarithms of integer numbers? That would be rather unexpected - and I don't see a reason for such approach. Unnecessary complication.

 

[willem2]

You think there is a separate code for calculating logarithms of integer numbers? That would be rather unexpected - and I don't see a reason for such approach. Unnecessary complication.

The binary representation of 5 will have only 2 1 bits, so multiplying by it will be much faster, espescially on a very old processor with only 8 (or even 4) bits, and no multiplication instruction. (and it has to be something like that, or the calculation time would be too fast to notice a delay).

Actually the calculator may begin with ln(5) = 2 * ln(2) + ln(1.25), and then use the power series expansion of ln(x) around x = 1, so you end up with powers of 1/4, so you have only 1 bit to multiply by.

 

[AlephZero]

A couple of posts here have used the words "the power series", as if there was only one such thing. Presumably they mean a Taylor series that they learned about in a calculus course.

That is very rarely the way functions like logs are calculated in "serious" numerical work. For example one well-known method of calculating logs uses the ratio of two cubic polymonials, and is accurate to 16 decimal places in the range \sqrt {1/2} \le x \le \sqrt 2. That is much quicker than using enough terms to get the same accuracy from a Taylor series. (Ref: Plauger, "The Standard C library" - though the algorithm comes from an earlier book by Cody & Waite)

Having said that, some of the early electronic calculators (back in the 1970s) used horrible numerical methods. IIRC it was possible to send one of the early Sinclair calculators into an "infinte loop" evaluating some math functions, but with modern electronics there's no excuse for that sort of thing.

It's possible that some calculators do all their arithmetic in decimal rather than binary, and do multiplications the same way as doing long multiplication by hand. In that case it's possible that a value with a small number of non-zero digits will compute faster, if the program skips over doing operations on the zeros.

FWIW on my calculator (a Casio) I can't detect any speed difference in the OP's example, and I haven't noticed anything similar for other functions.