Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

LogBASE(512,2) != 9 ?

  1. Jul 16, 2015 #1
    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?
  2. jcsd
  3. Jul 16, 2015 #2


    User Avatar
    Science Advisor

    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.
  4. Jul 16, 2015 #3


    User Avatar
    Science Advisor
    Gold Member

    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 log2(512) that is less than 9, not the mathematical expression itself.
  5. Jul 16, 2015 #4
    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.
  6. Jul 16, 2015 #5


    Staff: Mentor

    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.
  7. Jul 16, 2015 #6
    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.
  8. Jul 16, 2015 #7


    Staff: Mentor

    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.
  9. Jul 16, 2015 #8
    Sometimes it depends on the type of calculators. I give 0.33333333*3 in mine and get 1 instead of 0.99999999...
  10. Jul 17, 2015 #9
    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)?
  11. Jul 17, 2015 #10


    Staff: Mentor

    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.
  12. Jul 17, 2015 #11
    That makes more sense!

    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(232) it's the first thing I think of.
  13. Jul 17, 2015 #12


    Staff: Mentor

    That's a very large error! Did you mean O(2-32)?
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook

Similar Discussions: LogBASE(512,2) != 9 ?
  1. 48÷2(9+3) equation (Replies: 117)

  2. 48÷2(9+3) = ? (Replies: 6)

  3. Rearranging 48/2(9+3) (Replies: 4)

  4. 6÷2(1+2) = 1 or 9? (Replies: 4)