0

Possible Duplicate:
Python float to int conversion problem 

def isPerfectCube(x):
   temp = x ** (float(1) / 3) 
   temp = temp ** 3
   temp = int(temp)
   print (temp == x)  
   return (temp == x)

I am trying to write a program to determine if a number x is a perfect cube. For some reason, some numbers have been rounding down a whole integer, instead of just truncating. I have never completely understood how floats work. I know they are inaccurate, so I am assuming the issue is coming from there.

For example:

  • 125.0 truncates to 124 when casted to int.
  • 64.0 truncates to 63 when casted to int.

Any help or explanations would be greatly appreciated.

Community
  • 1
  • 1
meyer0095
  • 137
  • 1
  • 1
  • 6
  • 63.999999999 truncates to 63. – nneonneo Jan 28 '13 at 23:04
  • 3
    [What Every Computer Scientist Should Know About Floating-Point Arithmetic](http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_goldberg.html) – NullUserException Jan 28 '13 at 23:05
  • 1
    This is not a plain duplicate. 64 can be represented exactly, as can the third root of 64 which is 4. This is about inaccuracies when computing the third root, not about storing decimal numbers. – phant0m Jan 28 '13 at 23:07
  • @phant0m The difference being? – NullUserException Jan 28 '13 at 23:08
  • @NullUserException The difference is, that he is not trying to store numbers that can't be represented, the duplicate, however, is. – phant0m Jan 28 '13 at 23:10
  • 3
    @phant0m: No, it's not. :-) The question explicitly uses `float(1) / 3`, which is an inaccurate representation (`1.0 / 3 * 3 <> 1.0`), and specifically asks about inaccurate values when **casting a float to an int**. – Ken White Jan 28 '13 at 23:10
  • @KenWhite Sure, but if you chose the fourth root, you could represent `float(1) / 4` exactly. It still wouldn't work. Even so, pointing out *which part* of the computations causes it to fail would have been nice, the duplicate wouldn't have helped him there. – phant0m Jan 28 '13 at 23:12
  • 1
    @phant0m: You missed the point. If you never reach `64.0` in the first place, it doesn't matter that it can be exactly represented. The function shown starts with introducing an inaccuracy by using `1.0/3`, and that inaccuracy can't be fixed by simply multiplying by the divisor again. `((1.0 / 3 * 3) + 7) * 8 <> 64.0` no matter how much you wish it was. :-) – Ken White Jan 28 '13 at 23:19
  • @KenWhite I smile a little when someone uses `<>` instead of `!=` for inequality :) – NullUserException Jan 28 '13 at 23:26
  • @NullUserException: I work with Delphi in my day job. (And a lot of non-programmers.) :-) – Ken White Jan 28 '13 at 23:27
  • Does anyone have any ideas to fix this code then? – meyer0095 Jan 28 '13 at 23:40
  • The third party `gmpy` module has a `root()` function – John La Rooy Jan 28 '13 at 23:58
  • @KenWhite That Point I do understand, which is why I referred to the fourth root, since you can exactly represent 1/4. – phant0m Jan 29 '13 at 07:36

0 Answers0