Log question (ln(75))

[Savage]

So, I am trying to develop a report on how one could program their calculator to calculate a logarithm

For example, someone presses log _ 9 (75)

I would then use the change of base formula to convert log _ 9 (75) to ln(75)/ln(9) and my reason for choosing the e-base is because of its nice taylor series.

Problem: asking a computer to calculate the ln(.5) for example is easy because ln(.5) = ln(1 + -.5) and ln(1+x) has a nice  Maclaurin series that involves no logarithms and -.5 converges in that series.

Unfortunately neither 75, nor 9 can be manipulated like .5 to fit in the radius of convergence. I was curious if anyone had some sort of trick on how to create a taylor series to deal with this situation.

I know for a fact 9 to the "1 point something" power is 75, so I considered a taylor series around 2, but that won't converge for numbers as high as 75 or 9 still.

[andretimpa]

So, I am trying to develop a report on how one could program their calculator to calculate a logarithm

For example, someone presses log _ 9 (75)

I would then use the change of base formula to convert log _ 9 (75) to ln(75)/ln(9) and my reason for choosing the e-base is because of its nice taylor series.

Problem: asking a computer to calculate the ln(.5) for example is easy because ln(.5) = ln(1 + -.5) and ln(1+x) has a nice  Maclaurin series that involves no logarithms and -.5 converges in that series.

Unfortunately neither 75, nor 9 can be manipulated like .5 to fit in the radius of convergence. I was curious if anyone had some sort of trick on how to create a taylor series to deal with this situation.

I know for a fact 9 to the "1 point something" power is 75, so I considered a taylor series around 2, but that won't converge for numbers as high as 75 or 9 still.

Use ln(a.b) = ln(a) + ln(b) such that you know ln(a) and b is in the radius of convergence. An easy but not so efficient way is to keep dividing by e until the result is small enough and add the number of times you divided in the end.

[Savage]

Ugh, I understand exactly what you are saying, but that is going to get super messy very quick. I have also tried expressing, for example, 75 as:

sqrt(3) * sqrt(3) * 4th root (5) * ... * 4th root (5) (8 4th-roots here)

Reason: Now, I can express these roots as 1+number (Were doing a taylor series for ln(1+x)), where "number" is guaranteed to be between (-1,1].

Is there any taylor series out there that "moves' its radius of convergence and is still somewhat as simple as ln(1+x)? By moves, I mean moving (-1,1] to...say (74.5,75.5] or something.

[andretimpa]

The problem is that in this case using a different Taylor series boils down to the trick I gave you earlier.

What determines the radius of convergence of a Taylor series centered about a number a is the distance a is from a singularity of the function (in some series this is a bit harder to see because the singularities are complex numbers instead of real ones). The only singularity ln has is 0, so if you make a series centered about a you get a radius of convergence equal to a allowing you to calculate ln(x) for x in (0, 2a]. This would be

ln(x) = ln(a) + ln'(a)(x-a) + ln''(a)(x-a)^2 /2 + ln'''(a)(x-a)^3 /6 + ... = ln(a) + (x-a)/a - (x-a)^2/(2a) + (x-a)^3/(3a) - ...

Define z = (x-a)/a. This means that z + 1 = x/a, so ln(z + 1) = ln(x) - ln(a), putting it in our Taylor series we get

ln(z+1) = z - z^2/2 + z^3/3 - z^4/4 + ...

and we are back to where we started, which is just a popular rewording of the Taylor series centered about 1.

[Lost in Nowhere]

Probably the best option you have is to use the identity that ln(x)=-ln(1/x). With the Taylor series for ln(x) around 1 and positive x, if the series does not converge at x, it will converge at 1/x. This essentially gives you a second series with radius of convergence [.5,∞), allowing you to calculate the natural logarithm of any positive real number.

[andretimpa]

That's actually a good idea. I don't know which method would arrive at the answer faster.

[Jenkar]

That's actually a good idea. I don't know which method would arrive at the answer faster.

Your answer has a complexity of roughly log(number) * complexity of the different operations of the taylor series
His answer has a complexity of roughly complexity of the different operations of the taylor series.
His seems better :3

[andretimpa]

That's actually a good idea. I don't know which method would arrive at the answer faster.

Your answer has a complexity of roughly log(number) * complexity of the different operations of the taylor series
His answer has a complexity of roughly complexity of the different operations of the taylor series.
His seems better :3

My sugestion is actually log(log(number)) + taylor (you can divide by e, if that doesn't work, then by e^2, e^4, e^8, etc. If you find a number that works you can work your way back to refine the value. You only use Taylor once you figured which number you'll take the logarithm). Doing some tests, the real problem is error propagation with my idea, which starts to get ugly with ~ 10 digit numbers. You could probably get rid of that by using powers of 2 and storing ln(2) in the memory to make the conversion.

After thinking a bit, using 1/x is a bad idea if x is very large because of the rate of convergence. Since

ln(z+1) = 1-z+z^2/2-z^3/3+...

and we'd have z+1=1/x, that would mean z=1-1/x and so the term in the position n*x in the series would be (1-1/x)^(n*x)/(n*x) ~ e^(-n)/(n*x), so we'd need roughly O(x) steps to get each decimal place in the result, which becomes a problem for large x.

I also noticed that if you are using floating point numbers (which is how computers store real numbers) you can cheat your answer a bit.

These numbers are stored as a*2^b, so if you store ln(2) in your code you can get the logarithm with
b*ln(2) - ln(1/a).
By construction a is between 1 and 2, so using 1/a gives you a number between 1/2 and 1, that have all fast convergence.