• Treczoks@lemmy.world
    link
    fedilink
    arrow-up
    9
    ·
    3 months ago

    I stopped using floats 30 years ago when I learned what rounding errors can do if you only deal with big enough numbers of items to tally. My employer turned around 25M a year, and it had to add up to the cent for the audits.

    • Womble@piefed.world
      link
      fedilink
      English
      arrow-up
      7
      arrow-down
      2
      ·
      edit-2
      3 months ago

      Single floats sure, but doubles give plenty of accuracy unless you absolutely need zero error.

      For example geting 1000 random 12 digit ints, multiplying them by 1e9 as floats, doing pairwise differences between them and summing the answers and dividing by 1e9 to get back to the ints gives a cumulative error of 1 in 10^16. assuming your original value was in dollars thats roughly 0.001cent in a billion dollar total error. That’s going deliberately out of the way to make transactions as perverse as possible.

      • Treczoks@lemmy.world
        link
        fedilink
        arrow-up
        6
        ·
        3 months ago

        Nope. With about a hundred thousand factored items, things easily run off the rails. I’ve seen it. Just count cents, and see that rounding errors are kept in close, deterministic confines.

        • jasory@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          3 months ago

          You can use Kahan summation to mitigate floating point errors. A mere 100 thousand floating point operations is a non-issue.

          As a heads up computational physics and mathematics tackle problems trillions of times larger than any financial computation, that’s were tons of algorithms have been developed to handle floating point errors. Infact essentially any large scale computation specifically accounts for it.

        • Womble@piefed.world
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          3
          ·
          edit-2
          3 months ago

          You are underestimating how precice doubles are. Summing up one million doubles randomly selected from 0 to one trillion only gives a cumulative rounding error of ~60, that coud be one million transactions with 0-one billion dollars with 0.1 cent resolution and ending up off by a total of 6 cents. Actually it would be better than that as you could scale it to something like thousands or millions of dollars to keep you number ranger closer to 1.

          Sure if you are doing very high volumes you probably dont want to do it, but for a lot of simple cases doubles are completely fine.

          Edit: yeah using the same million random numbers but dividing them all by 1000 before summing (so working in kilodollars rather than dollars) gave perfect accuracy, no rounding errors at all after one million 1e-3 to 1e9 double additions.

          • Treczoks@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            3 months ago

            The issue is different. Imagine you have ten dollars that you have to spread over three accounts. So this would be 3.33 for each, absolute correctly rounded down. And still, a cent is missing in the sum. At this point, it is way easier to work with integers to spread leftovers - or curb overshots.

            • FizzyOrange@programming.dev
              link
              fedilink
              arrow-up
              0
              ·
              3 months ago

              That doesn’t make any sense. As you say, in that case you have to “spread leftovers”, but that isn’t really any more difficult with floats than integers.

              It’s better to use integers, sure. But you’re waaaay over-blowing the downsides of floats here. For 99% of uses f64 will be perfectly fine. Obviously don’t run a stock exchange with them, but think about something like a shopping cart calculation or a personal finance app. Floats would be perfectly fine there.

  • randy@lemmy.ca
    link
    fedilink
    arrow-up
    8
    ·
    edit-2
    3 months ago

    I got hung up on this line:

    This requires deterministic math with explicit rounding modes and precision, not the platform-dependent behavior you get with floats.

    Aren’t floats mostly standardized these days? The article even mentions that standard. Has anyone here seen platform-dependent float behaviour?

    Not that this affects the article’s main point, which is perfectly reasonable.

    • nimpnin@sopuli.xyz
      link
      fedilink
      arrow-up
      20
      ·
      3 months ago

      Mostly standardized? Maybe. What I know is that float summation is not associative, which means that things that are supposed to be equal (x + y + z = y + z + x) are not necessarily that for floats.

    • a1studmuffin@aussie.zone
      link
      fedilink
      English
      arrow-up
      3
      ·
      3 months ago

      Floating-Point Determinism | Random ASCII - tech blog of Bruce Dawson https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/

      The short answer to your questions is no, but if you’re careful you can prevent indeterminism. I’ve personally ran into it encoding audio files using the Opus codec on AMD vs Intel processors (slightly different binary outputs for the exact same inputs). But if you’re able to control your dev environment from platform choice all the way down to the assembly instructions being used, you can prevent it.

      • randy@lemmy.ca
        link
        fedilink
        arrow-up
        1
        ·
        3 months ago

        Thanks, that’s an excellent article, and it’s exactly what I was looking for.

    • bleistift2@sopuli.xyz
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      3 months ago

      If you count the programming language you use as ‘platform’, then yes. Python rounds both 11.5 and 12.5 to 12.

      • WolfLink@sh.itjust.works
        link
        fedilink
        arrow-up
        1
        ·
        3 months ago

        This is a common rounding strategy because it doesn’t consistently overestimate like the grade school rounding strategy of always rounding up does.

    • pinball_wizard@lemmy.zip
      link
      fedilink
      arrow-up
      1
      ·
      3 months ago

      The real standard is whatever Katherine in accounting got out of the Excel nightmare sheets they reconcile against.

  • ∃∀λ@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    3 months ago

    I become suspicious when I see a Medium user posting well-written deep articles as frequently as this user appears to be doing. How can we tell whether this is AI slop or not?

    • jasory@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      3 months ago

      Their articles aren’t that deep and they mostly focus on similar topics.

      I think it’s perfectly possible for someone to have a backlog of work/experience that they are just now writing about.

      If it were AI spam, I would expect many disparate topics at a depth slightly more than a typical blog post but clearly not expert. The user page shows the latter, but not the former.

      However, the Rubik’s cube article does seem abnormal. The phrasing and superficiality makes it seem computer-generated, a real Rubik’s afficionado would have spent some time on how they cube.

      Of course I say this as someone much more into mathematics than “normal” software engineering. So maybe their writing on those topics is abnormal.

    • TehPers@beehaw.org
      link
      fedilink
      English
      arrow-up
      0
      ·
      3 months ago

      The medium (lol) is annoying, but it didn’t ask me to pay. Is the article not free for you?

  • Kissaki@programming.dev
    link
    fedilink
    English
    arrow-up
    0
    ·
    3 months ago

    Scroll to the second paragraph, get a subscribe popover. So annoying. I haven’t even read any reasonable amount of content yet.