我很惊讶地看到这种Python行为,但不明白为什么?我无法在 python 列表中搜索 0.3。
>> import numpy as np
>> Lambdas = np.arange(0.0, 1.05, 0.05)
>> print(Lambdas)
[0. 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65
0.7 0.75 0.8 0.85 0.9 0.95 1. ]
>> print(0.3 in Lambdas)
False
>> print(0.30 in Lambdas)
False
>> print(0.1 in Lambdas)
True
>> print(0.4 in Lambdas)
True
>> print(1 in Lambdas)
True
>> print(1.0 in Lambdas)
True
>> print(0.1 in Lambdas)
True
>>
最佳答案
根据http://0.30000000000000004.com/
Your language isn't broken, it's doing floating point math. Computers can only natively store integers, so they need some way of representing decimal numbers. This representation comes with some degree of inaccuracy. That's why, more often than not, .1 + .2 != .3.
Why does this happen? It's actually pretty simple. When you have a base 10 system (like ours), it can only express fractions that use a prime factor of the base. The prime factors of 10 are 2 and 5. So 1/2, 1/4, 1/5, 1/8, and 1/10 can all be expressed cleanly because the denominators all use prime factors of 10. In contrast, 1/3, 1/6, and 1/7 are all repeating decimals because their denominators use a prime factor of 3 or 7. In binary (or base 2), the only prime factor is 2. So you can only express fractions cleanly which only contain 2 as a prime factor. In binary, 1/2, 1/4, 1/8 would all be expressed cleanly as decimals. While, 1/5 or 1/10 would be repeating decimals. So 0.1 and 0.2 (1/10 and 1/5) while clean decimals in a base 10 system, are repeating decimals in the base 2 system the computer is operating in. When you do math on these repeating decimals, you end up with leftovers which carry over when you convert the computer's base 2 (binary) number into a more human readable base 10 number.
关于python - 在Python列表中查找 float ,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/56410690/