you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 1 year ago (10 children)

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.

  • source
  • parent
  • hideshow 10 child comments
  • [–] 3 points 1 year ago (4 children)

    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.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 2 points 1 year ago

    As someone who has implemented shopping carts, invoicing solutions and banking transactions I can assure you floats will be extremely painful for you.

    A huge benefit of big decimals is that they don't allow you to make a mistake (as easily) as floats where imprecision just "creeps in".

  • source
  • parent
  • [–] 2 points 1 year ago (2 children)

    As you said, better use integers. And that's exactly what is done at this point.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 1 year ago* (4 children)

    I fail to see a difference there, 10.0/3 = 3.33333333333 which you round down to 3.33 (or whatever fraction of a cent you are using) as you say for all accounts then have to deal with the leftovers, if you are using a fixed decimal as the article sugests you get the same issue, if you are using integer fractions of a cent, say milicents you get 1000000/3 = 333333 which gives you the exact same rounding error.

    This isnt a problem with the representation of numbers its trying to split a quantity into unequal parts using division. (And it should be noted the double is giving the most accurate representation of 10/3 dollars here, and so would be most accurate if this operation was in the middle of a series of calcuations rather than about to be immediately moving money).

    As I said before, doubles probably arent the best way to handle money if you are dealing with high volumes of or complex transactions, but they are not the waiting disaster that single floats are and using a double representation then converting to whole cents when you need to actually move real money (like a sale) is fine.

  • source
  • parent
  • hideshow 4 child comments
  • [–] -1 points 1 year ago (3 children)

    I fail to see a difference there

    That I noticed some posts ago. The issue has not changed since then.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 3 points 1 year ago (2 children)

    And so instead of explain why and clarify any misunderstanding you chose to snarkily insult my intelligence, very mature.

  • source
  • parent
  • hideshow 2 child comments
  • [–] -3 points 1 year ago (1 child)

    I did clarify my reasons. That you obviously didn't read.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 0 points 1 year ago

    No you spouted some stuff about "trust me I've seen it" (almost certainly relating to using single floats) then an irrelevant tangent about how ten doesnt divde cleanly into three and how thats a problem for floats, when you have exactly the same problem with fixed point/integer division.

    Do you have an actual example of where double precission floats would cause an issue? Preferably an example that could be run to demonstrate it.

  • source
  • parent