Why is the int() function giving a different output for int(logBASE(512,2))?

[24forChromium]

Sorry, I know this is not really a math problem (move it to where you think fit, if you like), but I have no idea what on the crazy Earth is going on here:

the "int()" function, as far as I know, takes the integer part of a number, for example:

int(24.83219) = 24

and I know that "int(9)" is just 9. However, as you can see, when I take the interger part of that log function, it is giving me a number that I can comprehend in this context. This has never happened to any other logs I tried. So, what's going on here and how can I get int(logBASE(512,2))'s output to be 9?

 

[Svein]

The calculator does log(512)/log(2) = 6.23832/0.693147 which is slightly less than 9, but is rounded up to 9. The integer part is still 8, even if the number is 8.99999999.

 

[TeethWhitener]

The calculator does log(512)/log(2) = 6.23832/0.693147 which is slightly less than 9, but is rounded up to 9. The integer part is still 8, even if the number is 8.99999999.

Just to be clear, ln(512)/ln(2) is exactly 9, but the calculator uses an algorithm (probably a Taylor series) to estimate the value of ln(x). It's the calculator's approximation of log₂(512) that is less than 9, not the mathematical expression itself.

 

[J.J.T.]

It's incredibly easy for log functions to have numbers of iterations into the 100's, 1000's or higher. Your calculator likely computed this a 8.999999999~ for hundreds if not thousands of iterations before it hit one that was not a 9 or reached it's limit of iterations and rounded it. Regardless, when you hit the int() key you're calculator was likely jumping for joy as it now only had to calculate a single iteration and stopped there.
Edit: no it actually isn't exactly 9 your calculator likely hit its limit on iterations for the calculation at which point it made the decision that 9 was actually the MORE EXACT output.

 

[Mark44]

It's incredibly easy for log functions to have numbers of iterations into the 100's, 1000's or higher.

I doubt that this is true. Calculators typically use the CORDIC algorithm to calculate trig, exponential, log functions, and others. They don't use Taylor series or other series to calculate these functions. See https://en.wikipedia.org/wiki/CORDIC.

Your calculator likely computed this a 8.999999999~ for hundreds if not thousands of iterations before it hit one that was not a 9 or reached it's limit of iterations and rounded it. Regardless, when you hit the int() key you're calculator was likely jumping for joy as it now only had to calculate a single iteration and stopped there.
Edit: no it actually isn't exactly 9 your calculator likely hit its limit on iterations for the calculation at which point it made the decision that 9 was actually the MORE EXACT output.

 

[J.J.T.]

I doubt that this is true. Calculators typically use the CORDIC algorithm to calculate trig, exponential, log functions, and others. They don't use Taylor series or other series to calculate these functions. See https://en.wikipedia.org/wiki/CORDIC.

I will admit I did originally think it was a Taylor series, but it seems like it would run into the same problem as the system is described as "shift and add" there must be an upper limit on the number of iterations.

 

[Mark44]

I will admit I did originally think it was a Taylor series, but it seems like it would run into the same problem as the system is described as "shift and add" there must be an upper limit on the number of iterations.

A lot of the calculation is done using lookup tables, so it doesn't take hundreds or thousands of iterations. I found a CORDIC implementation of the ln() function here: http://people.sc.fsu.edu/~jburkardt/m_src/cordic/ln_cordic.m. The implementation seems to have been done using matlab. I ported the implementation to C (I don't have matlab) and compared the results of the C standard library function log() with the ln_cordic() function in the link. Using 25 iterations I got exactly the same results from both functions out to 10 decimal places for ln(2). Using only 10 iterations I got agreement in 9 decimal places.

 

[tommyxu3]

Sometimes it depends on the type of calculators. I give 0.33333333*3 in mine and get 1 instead of 0.99999999...

 

[pbuk]

Only one additional decimal place for an extra 15 iterations? ln_cordic() should converge much faster than that, are you sure you are not running into arithmetical precision errors somewhere (a 32 bit integer has 10 decimal places so could this be a problem)?

 

[Mark44]

Only one additional decimal place for an extra 15 iterations? ln_cordic() should converge much faster than that, are you sure you are not running into arithmetical precision errors somewhere (a 32 bit integer has 10 decimal places so could this be a problem)?

The check I did was only a quick one. When my code did 25 iterations I was printing out only 10 decimal places of the results from ln_cordic() and from the standard library function log(). If I print 15 decimal places for the two functions, ln_cordic() agrees with the std. library function in 15 decimal places (with n = 25). The upshot is that in the calculation of ln(2.0), increasing the number of iterations from 10 to 25 increased the precision in ln_cordic() from 9 decimal places to 15 decimal places.

I am using double variables for all calculated values, not integers.

 

[pbuk]

The upshot is that in the calculation of ln(2.0), increasing the number of iterations from 10 to 25 increased the precision in ln_cordic() from 9 decimal places to 15 decimal places.

That makes more sense!

I am using double variables for all calculated values, not integers.

I just wondered - I have made mistakes similar to this particularly when translating between strongly and weakly typed languages and now when I see a truncation error O(2³²) it's the first thing I think of.

 

[Mark44]

I just wondered - I have made mistakes similar to this particularly when translating between strongly and weakly typed languages and now when I see a truncation error O(2³²) it's the first thing I think of.

That's a very large error! Did you mean O(2^-32)?