138
submitted 4 months ago by abhi9u@lemmy.world to c/technology@lemmy.world
top 13 comments
sorted by: hot top controversial new old
[-] magic_lobster_party@kbin.run 34 points 4 months ago* (last edited 4 months ago)

TL;DR:

In Python, following returns False.

9007199254740993 == 9007199254740993.0

The floating point number 9007199254740993.0 is internally represented in memory as 9007199254740992.0 (due to how floating point works).

Python has special logic for comparing int with floats. Here it will try to compare the int 9007199254740993 with the float 9007199254740992.0. Python sees that the integer parts are different, so it will stop there and return False.

[-] Dark_Arc@social.packetloss.gg 28 points 4 months ago* (last edited 4 months ago)

Comparing floats for equality is generally a bad idea anyways.

Floats should really only be used for approximate math. You need something like Java's BigDecimal or BigInteger to handle floating point math with precision.

Looks like this is the equivalent for Python:

https://docs.python.org/3/library/decimal.html

[-] Cethin@lemmy.zip 6 points 4 months ago

Comparing is fine, but it should be fuzzy. Less than and greater than are fine, so you basically should only be checking for withing a range of values, not a specific value.

[-] kakes@sh.itjust.works 18 points 4 months ago* (last edited 4 months ago)

I assume this is because that number is so large that it loses precision, in which case this is more of a quirk of floating point than a quirk of Python.

Disclaimer: Have not read the article yet.

[-] magic_lobster_party@kbin.run 16 points 4 months ago

It’s both. As you said it’s because of loss of floating point precision, but it’s also with some of the quirks how Python compares int with float. These two together causes this strange behavior.

[-] Siegfried@lemmy.world 26 points 4 months ago

If i'm comparing ints with floats, it is my fault in the first place

[-] warrenson@lemmy.world 2 points 4 months ago

Exactly, I'd expect a warning, if not an error.

[-] Diabolo96@lemmy.dbzer0.com 20 points 4 months ago* (last edited 4 months ago)

I geuss it's something like : if close enough, set to true.

Now I'll read the article and discover it's like 100x more complex.

Edit : It is indeed at least 100x more complex.

[-] SwordInStone@lemmy.world 13 points 4 months ago

it's not only more complex it also doesn't work like you described at all

[-] Eximius@lemmy.world 11 points 4 months ago

Did nobody read the manual?

IEEE 754 double precision: The 53-bit significand precision gives from 15 to 17 significant decimal digits precision.

[-] Blackmist@feddit.uk 2 points 4 months ago

I'm not sure where the 17 comes from. It's 15.

[-] hades@lemm.ee 4 points 4 months ago

The "15 to 17" part is worded somewhat confusingly, but it's not wrong.

The number of bits contained in a double is equivalent to ~15.95 decimal digits. If you want to store exactly a decimal number with a fixed number of significant digits, floor(15.95) = 15 digits is the most you can hope for. However, if you want to store exactly a double by writing it out as a decimal number, you need 17 digits.

[-] vhstape@lemmy.sdf.org 6 points 4 months ago

Well-written 👍

this post was submitted on 27 May 2024
138 points (100.0% liked)

Technology

58239 readers
3473 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS