2/15 "is_int" : My prog work but not as will


<Below this line, add a link to the EXACT exercise that you are stuck at.>


<In what way does your code behave incorrectly? Include ALL error messages.>

The auto-correction valide it but my prog dont works for marginal case.

<What do you expect to happen instead?>

i want my prog works for all case

def is_int(x):
  if x - int(x) == 0:
    print x, "is a integer"
    return True
    print x, "is Not a integer"
    return False
is_int(7.00000000001) #display that is Not a integer as Well
is_int(7.000000000001) #display that is a integer but it's NOT !!!


Hi @seb16120,

Specifically what does you code do that differs from what it should do?


My prog should said if the input i give is a integer.

For that i subtract int(x) to my input.

If the rsult is greater than 0 my input is not a integer.
The problem is that for you langage considere 0.0000000000000001 = 0 : it’s annoying …


this problem occurs because python counts using base two, we humans use base ten. This difference causes the problem, codecademy is only teaching python, we can’t do anything about this implementation in python

but this problem has been given some thought, smart people attempted to fix it, and it didn’t work.

So there isn’t much we can do. We wish there was something we could do, but the truth is, we can’t.


Thanks, @stetim94.

For additional information on the precision of Python float objects, see Floating Point Arithmetic: Issues and Limitations.


thanks you for this information !

i read the article and as a lover of maths i’m little sad to learn that fact.

But even in mathematics there is a proverb that says, “all models are false, there are some that are just more useful than others”

Do you know what langage use calculator for have not / less this issue ?

p.s : sorry for my bad english i’m french :c


from the docs appylpye provided:

Representation error refers to the fact that some (most, actually) decimal fractions cannot be represented exactly as binary (base 2) fractions. This is the chief reason why Python (or Perl, C, C++, Java, Fortran, and many others) often won’t display the exact decimal number you expect:

The languages listed above, are big ones, and they face exactly the same problem.

unfortunately, this analogy can not be applied in this situation. Computers are dumb, they know two things: signal (1) or no signal (0)

this also explains the base 2 counting system:

and given this is fundamental limitation within the computer, the programming language can’t do anything about it

Worrying about this problem doesn’t help, the only possible solution would be a quantum computer, given its able to have values between 0 and 1, then you could possible implement a base 10 counting system, which might fix the issue. But quantum computers are still in development, so for now, we will have to live with the restrictions of base 2)


There are some partial solutions to the problem. Python offers a decimal module. See 9.4. decimal — Decimal fixed point and floating point arithmetic.

Under the hood, of course, we still have a binary computer. However, the module is designed to keep track of the decimal digits.

The above woks well for addition, subtraction, and multiplication, although the decimal arithmetic may be slower than binary arithmetic. However, for division there are many cases where the quotient will be inexact, for example, when the operands are prime numbers.

Python also offers a fractions module for working with numbers that can be expressed as numerators and denominators that are integers. See 9.5. fractions — Rational numbers.


Thanks you for these infos

i will read the article when i get some time :wink:


Yes i saw the “decimal” import in the article : " Floating Point Arithmetic: Issues and Limitations"

And thx for share me “fraction” import who can help to keep 1/3 instead of have a approximation of 0.33333333… (b10 ) or 0.0101010101… (b2)


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.