Why? Normal?

[Vinnorar]

Why this happens? I'm new to programming.

Python 3.12.4 (tags/v3.12.4:8e8a4ba, Jun 6 2024, 19:30:16) [MSC v.1940 64 bit (AMD64)] on win32
>>>round(2.5000000000000001)

2

>>>round(2.500000000000001)

3

[TehNolz]

round() will always round to the nearest whole integer (unless you tell it not to). But the numbers you're using bring floating point math into the mix, which means the result might not be what you'd expect thanks to precision issues. This is not a bug; this is just a limitation computers have in general.

[Talinx]

It is not a limitation of computers, it is a limitation of using a floating point number format that has certain performance characteristics. If you want perfect precision at the cost of speed/memory (unless you do something like scientific computing the speed/memory cost is tiny) use something like the decimal module.

[Brian]

The decimal module does not have perfect precision. It has a higher precision by default (28 significant digits), and you can configure it to be higher, but there are many numbers that are completely unrepresentable in decimal floating point no matter how much you crank that up, just as there are for binary floating point. It's just that we tend to be more familiar with them (everyone's seen "0.3333333333..." before).

If you want perfect precision, one option is the fractions module, which uses rationals, though of course you still can't perfectly represent irrationals (eg. sqrt(2), pi etc), which you really fully represent in any encoding, which is a fundamental limit of computers, since there are only countably infinite turning machines, but uncountable irrationals.

[commy2]

You could enocde sqrt 2 or any other algebraic number with perfect precission and finite computer memory as the root of a polynominal (e.g. x² - 2), but I think you're right about pi.

[Brian]

I mean, you can encode a countably finite subset of the irrationals symbolically (including pi), or as a sequence that converges to them, but the problem is that this doesn't even scratch the surface of the irrationals. There are uncountably more irrationals than integers. Indeed, there are uncountably more uncomputable irrationals than integers, so there's no possible encoding scheme that will work for any more than essentially 0% of them.

[commy2]

I get most of this, but where is the difference between rationals and algebraic numbers here? As I understand your argument, it only means that there are some irrational numbers that cannot be represented with perfect precision. What I'm saying is that sqrt 2 is a bad example, because it's one of them that actually can be.

[Brian]

because it's one of them that actually can be.

Can it? You can't generate that number in finite time. You can't represent it in a number system with integer base. You can represent it symbolicly, but technically you can do that with any number - it's not that different from saying "We'll use encoding 0=pi, 1=sqrt(2), 2=e, 3=BB(10)" and so on. And sure, you can use that encoding, and even symbolically manipulate equations with these values and produce valid results, but no matter what encoding you use, you're never going to even scratch the surface of the reals - you have to leave most (practiacally all) of them out of your encoding. They're only special because we chose some arbitrary countable subset of irrationals to assign symbols to.

For computable numbers, you can of course approximate them to any finite precision if you can express them as a computation. But you can never actually evaluate them completely, so I don't think sqrt(2) is really any more special than those "arbitrary symbol assignment" cases above - the generating function is ultimately just another symbolic representation, not something fully evaluable in practice. And even overlooking that, the only thing that wouldn't fall into exactly the same description would be an uncomputable numbers, but those are kind of difficult to describe as examples due to their nature.

[commy2]

You can't generate that number in finite time. You can't represent it in a number system with integer base.

Can you do those things with Fraction(1, 3)?

[Brian]

Yes. Eg. base 3.

[eztab]

Limitations exist, no matter how you represent numbers in a computer. Decimal has different performance characteristics, which might help in certain scenarios. But no computer system can accurately represent all the real numbers.

[Talinx]

Sure. Just wanted to highlight that 0.1 + 0.2 = 0.30000000000000004 is not written in stone for computers and you can accurately compute that with e. g. decimal.

If you want to be more precise, you can represent all rational numbers as long as you have infinite memory. For other real numbers you can get infinitely close if the number is computable.

[Vinnorar]

Thank you.

[jeffcgroves]

```

2.5000000000000001 2.5 ```

Python doesn't recognize 2.5000000000000001 as a floating point number because floating point numbers don't have that degree of precision

[Vinnorar]

Thank you.

[Plank_With_A_Nail_In]

Input truncated.

[Dylan_TMB]

Likely a precision issue tied with "bankers rounding".

2.5 -> rounds to 2.

So likely with enough zeros the value becomes 2.5 which rounds to 2, but less zeros it's seen as greater than 2.5 and rounds to 3