🔒 why the difference?

[wet elm]

it doesnt make sense in the implementation of floating point

[plain mantle]

@wet elm

Python help channel opened

Remember to:

• Ask your Python question, not if you can ask or if there's an expert who can help.
• Show a code sample as text (rather than a screenshot) and the error message, if you've got one.
• Explain what you expect to happen and what actually happens.

:warning: Do not pip install anything that isn't related to your question, especially if asked to over DMs.

Closes after a period of inactivity, or when you send !close.

[wet elm]

ending of 2, 3, 2.0

it's like the +1 for the last one added 0 and not 1

[dreamy cargo]

this integer is too big to be exactly representable as a float, so it gets rounded to the nearest float.

the next float after 900...992 is 900...994, so adding 1 to the former doesn't change it.

[wet elm]

but it isnt ...994 though? why didnt it go to the next floating point then like you said? it didnt at all change after the +1 operation

[dreamy cargo]

Well, both of them are equally close to the true result (..993). I think float addition rounds towards zero in this case.

[wet elm]

but that means if i do +1 again itll again round down to 992

[dreamy cargo]

That's true, yes.

It also means that (x + 1) + 1 isn't the same as x + (1 + 1), so addition stops being associative.

[wet elm]

so i could do a 10^3 operations of adding +1 is what you're saying, and the variable wouldnt change ever?

[dreamy cargo]

Yes.

[wet elm]

yes exactly

[wet elm]

isnt that a flaw in the system?

this seems like something that has to be fixed

[wet elm]

because this could ruin actual real world solutions to problems

[analog ledge]

I think this has to do with how computers fundamentally work and represent numbers

[rustic panther]

This is more of a flaw in how computers see numbers, not python

[dreamy cargo]

It's one of the problems of IEEE floats, yes.

[analog ledge]

If you want to compare this number to another one, you can use math.isclose()

[dreamy cargo]

There isn't really a fix, though - floats are good for most of their usecases, and fixing their problems requires giving up on some of the nice properties (and also on performance).

[rustic panther]

Afaik there is a more accurate standard to work with floats, but it'll probably be much slower and won't be supported by many things

[wet elm]

there's other fraction implementations in python? i think python is famous for one them i cant remember which, one that could fix it with practically infinite number space allocation

[dreamy cargo]

For instance, decimals (fixed-point numbers) don't have most of these problems, but they have the problem of having a limited range of values rather than having a constant relative error like floats do.

[dreamy cargo]

You likely mean decimal. It's not really unique or anything - there's multiprecision math libraries for basically any language*, though Python is pretty cool for having an implementation in the standard library.
*E.g. the famous GMP comes to mind.

[wet elm]

by decimal you mean real numbers? or just whole numbers? or rational ones too?

i mean the base10 doesnt really make sense to me

[dreamy cargo]

(Also, in practice it's possible to compensate for many of the problems, it just takes some specialized knowledge. E.g. in the scenario you mentioned, adding up tons of numbers of very different scales, you can avoid the loss of accuracy by using the https://en.wikipedia.org/wiki/Kahan_summation_algorithm )

[wet elm]

since it still is a base2 in reality

[dreamy cargo]

decimal is the name of a builtin python library. It provides a fixed-point, base-10, variable-size representation for real numbers.

or rational ones
there's a different builtin for that, fractions. That one is pretty simple - python already has infinite-sized ints, so it's simple to represent rationals as a pair of those, and that's what that module does.

[wet elm]

could you explain this to me?

i mean i thought too to make a seperate variable to add the 10^3 +1s everytime to instead of the big number above

but it could also eventually reach the SAME problem the original big number had (+1 to itself is identical to +0)

[dreamy cargo]

not sure I can. check the algorithm itself, basically. It's possible to predict the error that'll occur when adding a+b, and add the error only to a separate variable.

[dreamy cargo]

Yup. there's no free lunch here - no matter what you do it'll be possible to produce an example which has numerical errors. There's just no way to accurately model real numbers with a finite-size representation.

[wet elm]

yeah thats true, but there could be an-ever-expanding represenation maybe? maybe when needing extreme precisions for exact calculations?

[dreamy cargo]

sure, that's done sometimes

[wet elm]

do you know if Kahan's algorithim is the best way to solve this issue?

[wet elm]

thats the implementation im looking for

do you know if it has a name?

well thats alright

ty anyway mate!

!close

[plain mantle]

Python help channel closed

This help channel has been closed and it's no longer possible to send messages here. If your question wasn't answered, feel free to create a new post in #1035199133436354600. To maximize your chances of getting a response, check out this guide on asking good questions.