438
0.30000000000000004
(feddit.de)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 17 Sep 2023
438 points (100.0% liked)
Programmer Humor
19817 readers
570 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
If working in currency, work in cents and divide by 100 and round to 2 decimals for output
Yeah round down and transfer the remainder to an account you own.
Indeed, Lex
No, not Lex. Gus!
Awesome movie, regardless!
I just recalled, in that project I did have to divide money, which would leave fractional cents
It was a budgeting program, I could put rogue cents where I liked. I think my solution made accounts due $12.553333333... (internally 1255.3333...) each pay period get 12.54, so after n/3 pay periods they'd be 2n cents over. I could deal with that imprecision.
Most languages have decimal libraries to correctly handle floating point arithmetics, where precision is necessary.
They are as incapable of handling one third of a dollar as binary positional notation is incapable of handling one fifth (0.2).
It’s not really a float problem. It’s a positional notation one. Some perfectly rational numbers refuse to squeeze into that mold.
Also decimal system is not exatcly that much better since you also cant write 1/3 in decimal
If working with currency use types and formating functions appropriate for currency. Not float.
I was recalling a project in perl, which doesn't have a variety of types. If you add values, you get a scalar, which will be a float if the numbers are not integers.
I am aware my statement isn't true in several languages
Even then that can contain bugs on large amounts.
You're telling me there's someone that has more than 20 million dollars? /s
If you're handling people's money you should probably be using arbitrary-precision arithmetic. I mean, you might get away with a long int, but finance is serious business and the amount of data you're going to be processing relative to your funding is probably going to be small.
Not the project I was thinking about above, but at work my team delivered software handling 13 digit numbers, but that's in COBOL which does fine with money
And remember not all currencies are 2dp so get a list and use the appropriate exponent.
I had to update our currency database this week because there's new currencies. It's almost as bad as timezones.
Buckshot@programming.dev wake up, new currencies just dropped
That's what I wound up doing on a work project. Works really well.
Some programming languages use different rounding method. Might bite you in the ass if you're not aware of it and using multiple programming language in your application to handle different areas.