Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

Those are unit prices or interval prices. Any transaction will almost definitely be in an amount of dollars and centers if dealing in US, rounding to a whole cent based on the total units or interval.

For example, if you're paying #3.089 a gallon at the pump, and you pump exactly one gallon, you don't pay $3.089, you'll pay $3.09, and neither your account or the account you're paying into will need to know or care about the tenth of a cent difference, because our monetary system doesn't really deal with denominations that small in transactions.



yeah but this is where you really have to be careful where you do your rounding.

  3.089 * 10,000 = 30890
  3.09 * 10,000 = 30900
A one cent rounding added up to $10 difference. It's easy to screw this up in code, sending values to databases or across APIs, etc.

Also reminds me of the plot of Office Space. Which is a bit humorous since they screwed up their own scamming scheme in similar fashion.

https://www.youtube.com/watch?v=yZjCQ3T5yXo


There a subtlety in what I was saying that's being lost (which means you aren't wrong, but what you're stating doesn't necessarily apply specifically to what I was trying to say). You don't round rates, or prices, but you do round accounts because those represent real money. Your account can't actually have a fraction of a cent in it. Either the account it came from keeps the cent, or your account gets it. In a very real way, an account can be thought of as an integer number of cents (because often it's implemented that way). That may or may not make sense for your inventory or service system, where sub-cent rates make sense because the number of units is often greater than one.

To bring this back to the original comment and the items it was referencing, store money (real money, like accounts) in the smallest possible subdivision (cents for USD), but that doesn't need to apply to pricing, which is a potential amount of money. Potential money needs to be changed into real money at the time of a transaction, and real money cares about quantities it's possible to have, and it's not really possible (or at least useful, in most cases) to have less than the smallest possible subdivisible amount of a currency.

You're entirely correct though that you can't assume that cents is enough to accurately model everything to do with a business that works in USD, and ignoring that will result in problems like you showed.


I worked on a gambling webapp a long time ago. Gambling is heavily regulated here (.au) and all financial calculations are required to be done with 1/10,000th of a cent resolution, and rounding is only allowed to be applied once at the final display step.

(I used the regulations as a way to ensure _all_ calculations happened on the (Java) backend that other people were responsible for, given Javascript's documented mathematical insanity meant any client side calculations couldn't possibly pass compliance...)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: