▲ 100 ▼ Big Decimals: Stop Using Floats or Cents for Money (medium.com) submitted 10 months ago by Trev13@programming.dev to c/programming@programming.dev 54 comments fedilink hide all child comments
[–] Treczoks@lemmy.world 27 points 10 months ago (3 children) 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. permalink fedilink source hideshow 6 child comments replies: [–] MonkderVierte@lemmy.zip 12 points 10 months ago (1 child) And KSP (rocket exploding game) had ten years worth of floating point errors. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world 8 points 10 months ago (1 child) Like Minecraft has, too. Just go on a long, long walk in one direction. permalink fedilink source parent hideshow 2 child comments replies: [–] LowtierComputer@lemmy.world 3 points 10 months ago (2 children) What happens? permalink fedilink source parent hideshow 4 child comments replies: [–] ZILtoid1991@lemmy.world 5 points 10 months ago (1 child) The physics starts to glitch out, or at least used to, until it got upgraded to doubles. I also use doubles for my game engine, as well as (optionally) limiting pixel-precise things within int.max and int.min. permalink fedilink source parent hideshow 2 child comments replies: [–] LowtierComputer@lemmy.world 2 points 10 months ago (1 child) Does the world repeat after a set point? permalink fedilink source parent hideshow 2 child comments replies: [–] ZILtoid1991@lemmy.world 3 points 10 months ago Technically yes, and with tile layers, you can even set them repeating on a shorter area. permalink fedilink source parent [–] Treczoks@lemmy.world 3 points 10 months ago (2 children) All kinds of weird things. There is a video explaining the details, and you've got to be far, far out. permalink fedilink source parent hideshow 4 child comments replies: [–] LowtierComputer@lemmy.world 2 points 10 months ago I'll have to look it up after work. Sounds interesting. permalink fedilink source parent [–] ICastFist@programming.dev 2 points 10 months ago (2 children) Used to*, it was fixed in some version or another, where the procgen no longer evaluated how far you were from the origin permalink fedilink source parent hideshow 4 child comments replies: [–] kuberoot@discuss.tchncs.de 2 points 10 months ago The game, including worldgen, will still bug out at longer distances - the issues were reduced and a world limit was added to prevent you going too far, and IIRC past a certain point the world turns into non-stop ocean, but I'm pretty sure if you bypass those limits you'll encounter chunks that outright fail to generate. permalink fedilink source parent [–] Treczoks@lemmy.world 2 points 10 months ago OK, I have not played it for AGES. Nice to see something like that fixed, as it was a bit system-inherent. permalink fedilink source parent [–] Womble@piefed.world 9 points 10 months ago* (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world 20 points 10 months ago (2 children) 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. permalink fedilink source parent hideshow 4 child comments replies: [–] jasory@programming.dev 4 points 10 months ago (2 children) 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Treczoks@lemmy.world 6 points 10 months ago Yep. And in accounting this is done with integers. In my field (not accounting), calculations are done either in integer or in fixed-point arithmetic - which is basically the same in the end. Other fields work with floats. This variety exists because every field has its own needs and preferences. Forcing "One size fits all" solutions was never a good idea, especially when certain areas have well-defined requirements and standards. permalink fedilink source parent [–] soc@programming.dev 3 points 10 months ago (2 children) Yeah, but compared to counting money, nobody cares if some physics paper got its numbers wrong. :-) (Not to mention that would require the paper to have reproducible artifacts first.) permalink fedilink source parent hideshow 4 child comments replies: [–] azolus@slrpnk.net 2 points 10 months ago* We're using general relativity to calculate sattelite orbits - fuck your point of sale system if our sattelites come crashing down we're gonna have much bigger problems lol. permalink fedilink source parent [–] jasory@programming.dev 1 point 10 months ago Physics modeling is arguably the most important task of computers. That was the original impetus for building them; artillery calculations in WW2. All engineering modeling uses physics modeling, almost always linear algebra (which involves large summations). Nuclear medicine—physics, weather forecasting—physics, molecular dynamics and computational chemistry—physics. Physics modeling is the backbone of modern technology, it's why so much research has been done on doing it efficiently and accurately. permalink fedilink source parent [–] Womble@piefed.world -3 points 10 months ago* (last edited 10 months ago) (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world 4 points 10 months ago (2 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Womble@piefed.world 2 points 10 months ago* (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -2 points 10 months ago (1 child) I fail to see a difference there That I noticed some posts ago. The issue has not changed since then. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 3 points 10 months ago (1 child) And so instead of explain why and clarify any misunderstanding you chose to snarkily insult my intelligence, very mature. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -4 points 10 months ago (1 child) I did clarify my reasons. That you obviously didn't read. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 0 points 10 months 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. permalink fedilink source parent [–] FizzyOrange@programming.dev 2 points 10 months ago (2 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Treczoks@lemmy.world 2 points 10 months ago (1 child) As you said, better use integers. And that's exactly what is done at this point. permalink fedilink source parent hideshow 2 child comments replies: [–] FizzyOrange@programming.dev 0 points 10 months ago (1 child) Indeed, but there's no need to shit on people using floats because in almost all cases they are fine too. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -1 points 10 months ago Where the heck did I "shit on people using floats"? permalink fedilink source parent [–] amju_wolf@pawb.social 2 points 10 months 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". permalink fedilink source parent [–] entwine@programming.dev 7 points 10 months ago (1 child) There's a good documentary about this. permalink fedilink source parent hideshow 2 child comments replies: [–] mic_check_one_two@lemmy.dbzer0.com 4 points 10 months ago Fun fact: This is actually called the Salami Shaving Scam. Basically, shave off tiny pieces of a bunch of large chunks, and eventually you’ll have a massive amount. Like taking a single slice of salami from every sausage that is sold. permalink fedilink source parent
[–] MonkderVierte@lemmy.zip 12 points 10 months ago (1 child) And KSP (rocket exploding game) had ten years worth of floating point errors. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world 8 points 10 months ago (1 child) Like Minecraft has, too. Just go on a long, long walk in one direction. permalink fedilink source parent hideshow 2 child comments replies: [–] LowtierComputer@lemmy.world 3 points 10 months ago (2 children) What happens? permalink fedilink source parent hideshow 4 child comments replies: [–] ZILtoid1991@lemmy.world 5 points 10 months ago (1 child) The physics starts to glitch out, or at least used to, until it got upgraded to doubles. I also use doubles for my game engine, as well as (optionally) limiting pixel-precise things within int.max and int.min. permalink fedilink source parent hideshow 2 child comments replies: [–] LowtierComputer@lemmy.world 2 points 10 months ago (1 child) Does the world repeat after a set point? permalink fedilink source parent hideshow 2 child comments replies: [–] ZILtoid1991@lemmy.world 3 points 10 months ago Technically yes, and with tile layers, you can even set them repeating on a shorter area. permalink fedilink source parent [–] Treczoks@lemmy.world 3 points 10 months ago (2 children) All kinds of weird things. There is a video explaining the details, and you've got to be far, far out. permalink fedilink source parent hideshow 4 child comments replies: [–] LowtierComputer@lemmy.world 2 points 10 months ago I'll have to look it up after work. Sounds interesting. permalink fedilink source parent [–] ICastFist@programming.dev 2 points 10 months ago (2 children) Used to*, it was fixed in some version or another, where the procgen no longer evaluated how far you were from the origin permalink fedilink source parent hideshow 4 child comments replies: [–] kuberoot@discuss.tchncs.de 2 points 10 months ago The game, including worldgen, will still bug out at longer distances - the issues were reduced and a world limit was added to prevent you going too far, and IIRC past a certain point the world turns into non-stop ocean, but I'm pretty sure if you bypass those limits you'll encounter chunks that outright fail to generate. permalink fedilink source parent [–] Treczoks@lemmy.world 2 points 10 months ago OK, I have not played it for AGES. Nice to see something like that fixed, as it was a bit system-inherent. permalink fedilink source parent
[–] Treczoks@lemmy.world 8 points 10 months ago (1 child) Like Minecraft has, too. Just go on a long, long walk in one direction. permalink fedilink source parent hideshow 2 child comments replies: [–] LowtierComputer@lemmy.world 3 points 10 months ago (2 children) What happens? permalink fedilink source parent hideshow 4 child comments replies: [–] ZILtoid1991@lemmy.world 5 points 10 months ago (1 child) The physics starts to glitch out, or at least used to, until it got upgraded to doubles. I also use doubles for my game engine, as well as (optionally) limiting pixel-precise things within int.max and int.min. permalink fedilink source parent hideshow 2 child comments replies: [–] LowtierComputer@lemmy.world 2 points 10 months ago (1 child) Does the world repeat after a set point? permalink fedilink source parent hideshow 2 child comments replies: [–] ZILtoid1991@lemmy.world 3 points 10 months ago Technically yes, and with tile layers, you can even set them repeating on a shorter area. permalink fedilink source parent [–] Treczoks@lemmy.world 3 points 10 months ago (2 children) All kinds of weird things. There is a video explaining the details, and you've got to be far, far out. permalink fedilink source parent hideshow 4 child comments replies: [–] LowtierComputer@lemmy.world 2 points 10 months ago I'll have to look it up after work. Sounds interesting. permalink fedilink source parent [–] ICastFist@programming.dev 2 points 10 months ago (2 children) Used to*, it was fixed in some version or another, where the procgen no longer evaluated how far you were from the origin permalink fedilink source parent hideshow 4 child comments replies: [–] kuberoot@discuss.tchncs.de 2 points 10 months ago The game, including worldgen, will still bug out at longer distances - the issues were reduced and a world limit was added to prevent you going too far, and IIRC past a certain point the world turns into non-stop ocean, but I'm pretty sure if you bypass those limits you'll encounter chunks that outright fail to generate. permalink fedilink source parent [–] Treczoks@lemmy.world 2 points 10 months ago OK, I have not played it for AGES. Nice to see something like that fixed, as it was a bit system-inherent. permalink fedilink source parent
[–] LowtierComputer@lemmy.world 3 points 10 months ago (2 children) What happens? permalink fedilink source parent hideshow 4 child comments replies: [–] ZILtoid1991@lemmy.world 5 points 10 months ago (1 child) The physics starts to glitch out, or at least used to, until it got upgraded to doubles. I also use doubles for my game engine, as well as (optionally) limiting pixel-precise things within int.max and int.min. permalink fedilink source parent hideshow 2 child comments replies: [–] LowtierComputer@lemmy.world 2 points 10 months ago (1 child) Does the world repeat after a set point? permalink fedilink source parent hideshow 2 child comments replies: [–] ZILtoid1991@lemmy.world 3 points 10 months ago Technically yes, and with tile layers, you can even set them repeating on a shorter area. permalink fedilink source parent [–] Treczoks@lemmy.world 3 points 10 months ago (2 children) All kinds of weird things. There is a video explaining the details, and you've got to be far, far out. permalink fedilink source parent hideshow 4 child comments replies: [–] LowtierComputer@lemmy.world 2 points 10 months ago I'll have to look it up after work. Sounds interesting. permalink fedilink source parent [–] ICastFist@programming.dev 2 points 10 months ago (2 children) Used to*, it was fixed in some version or another, where the procgen no longer evaluated how far you were from the origin permalink fedilink source parent hideshow 4 child comments replies: [–] kuberoot@discuss.tchncs.de 2 points 10 months ago The game, including worldgen, will still bug out at longer distances - the issues were reduced and a world limit was added to prevent you going too far, and IIRC past a certain point the world turns into non-stop ocean, but I'm pretty sure if you bypass those limits you'll encounter chunks that outright fail to generate. permalink fedilink source parent [–] Treczoks@lemmy.world 2 points 10 months ago OK, I have not played it for AGES. Nice to see something like that fixed, as it was a bit system-inherent. permalink fedilink source parent
[–] ZILtoid1991@lemmy.world 5 points 10 months ago (1 child) The physics starts to glitch out, or at least used to, until it got upgraded to doubles. I also use doubles for my game engine, as well as (optionally) limiting pixel-precise things within int.max and int.min. permalink fedilink source parent hideshow 2 child comments replies: [–] LowtierComputer@lemmy.world 2 points 10 months ago (1 child) Does the world repeat after a set point? permalink fedilink source parent hideshow 2 child comments replies: [–] ZILtoid1991@lemmy.world 3 points 10 months ago Technically yes, and with tile layers, you can even set them repeating on a shorter area. permalink fedilink source parent
[–] LowtierComputer@lemmy.world 2 points 10 months ago (1 child) Does the world repeat after a set point? permalink fedilink source parent hideshow 2 child comments replies: [–] ZILtoid1991@lemmy.world 3 points 10 months ago Technically yes, and with tile layers, you can even set them repeating on a shorter area. permalink fedilink source parent
[–] ZILtoid1991@lemmy.world 3 points 10 months ago Technically yes, and with tile layers, you can even set them repeating on a shorter area. permalink fedilink source parent
[–] Treczoks@lemmy.world 3 points 10 months ago (2 children) All kinds of weird things. There is a video explaining the details, and you've got to be far, far out. permalink fedilink source parent hideshow 4 child comments replies: [–] LowtierComputer@lemmy.world 2 points 10 months ago I'll have to look it up after work. Sounds interesting. permalink fedilink source parent [–] ICastFist@programming.dev 2 points 10 months ago (2 children) Used to*, it was fixed in some version or another, where the procgen no longer evaluated how far you were from the origin permalink fedilink source parent hideshow 4 child comments replies: [–] kuberoot@discuss.tchncs.de 2 points 10 months ago The game, including worldgen, will still bug out at longer distances - the issues were reduced and a world limit was added to prevent you going too far, and IIRC past a certain point the world turns into non-stop ocean, but I'm pretty sure if you bypass those limits you'll encounter chunks that outright fail to generate. permalink fedilink source parent [–] Treczoks@lemmy.world 2 points 10 months ago OK, I have not played it for AGES. Nice to see something like that fixed, as it was a bit system-inherent. permalink fedilink source parent
[–] LowtierComputer@lemmy.world 2 points 10 months ago I'll have to look it up after work. Sounds interesting. permalink fedilink source parent
[–] ICastFist@programming.dev 2 points 10 months ago (2 children) Used to*, it was fixed in some version or another, where the procgen no longer evaluated how far you were from the origin permalink fedilink source parent hideshow 4 child comments replies: [–] kuberoot@discuss.tchncs.de 2 points 10 months ago The game, including worldgen, will still bug out at longer distances - the issues were reduced and a world limit was added to prevent you going too far, and IIRC past a certain point the world turns into non-stop ocean, but I'm pretty sure if you bypass those limits you'll encounter chunks that outright fail to generate. permalink fedilink source parent [–] Treczoks@lemmy.world 2 points 10 months ago OK, I have not played it for AGES. Nice to see something like that fixed, as it was a bit system-inherent. permalink fedilink source parent
[–] kuberoot@discuss.tchncs.de 2 points 10 months ago The game, including worldgen, will still bug out at longer distances - the issues were reduced and a world limit was added to prevent you going too far, and IIRC past a certain point the world turns into non-stop ocean, but I'm pretty sure if you bypass those limits you'll encounter chunks that outright fail to generate. permalink fedilink source parent
[–] Treczoks@lemmy.world 2 points 10 months ago OK, I have not played it for AGES. Nice to see something like that fixed, as it was a bit system-inherent. permalink fedilink source parent
[–] Womble@piefed.world 9 points 10 months ago* (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world 20 points 10 months ago (2 children) 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. permalink fedilink source parent hideshow 4 child comments replies: [–] jasory@programming.dev 4 points 10 months ago (2 children) 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Treczoks@lemmy.world 6 points 10 months ago Yep. And in accounting this is done with integers. In my field (not accounting), calculations are done either in integer or in fixed-point arithmetic - which is basically the same in the end. Other fields work with floats. This variety exists because every field has its own needs and preferences. Forcing "One size fits all" solutions was never a good idea, especially when certain areas have well-defined requirements and standards. permalink fedilink source parent [–] soc@programming.dev 3 points 10 months ago (2 children) Yeah, but compared to counting money, nobody cares if some physics paper got its numbers wrong. :-) (Not to mention that would require the paper to have reproducible artifacts first.) permalink fedilink source parent hideshow 4 child comments replies: [–] azolus@slrpnk.net 2 points 10 months ago* We're using general relativity to calculate sattelite orbits - fuck your point of sale system if our sattelites come crashing down we're gonna have much bigger problems lol. permalink fedilink source parent [–] jasory@programming.dev 1 point 10 months ago Physics modeling is arguably the most important task of computers. That was the original impetus for building them; artillery calculations in WW2. All engineering modeling uses physics modeling, almost always linear algebra (which involves large summations). Nuclear medicine—physics, weather forecasting—physics, molecular dynamics and computational chemistry—physics. Physics modeling is the backbone of modern technology, it's why so much research has been done on doing it efficiently and accurately. permalink fedilink source parent [–] Womble@piefed.world -3 points 10 months ago* (last edited 10 months ago) (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world 4 points 10 months ago (2 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Womble@piefed.world 2 points 10 months ago* (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -2 points 10 months ago (1 child) I fail to see a difference there That I noticed some posts ago. The issue has not changed since then. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 3 points 10 months ago (1 child) And so instead of explain why and clarify any misunderstanding you chose to snarkily insult my intelligence, very mature. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -4 points 10 months ago (1 child) I did clarify my reasons. That you obviously didn't read. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 0 points 10 months 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. permalink fedilink source parent [–] FizzyOrange@programming.dev 2 points 10 months ago (2 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Treczoks@lemmy.world 2 points 10 months ago (1 child) As you said, better use integers. And that's exactly what is done at this point. permalink fedilink source parent hideshow 2 child comments replies: [–] FizzyOrange@programming.dev 0 points 10 months ago (1 child) Indeed, but there's no need to shit on people using floats because in almost all cases they are fine too. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -1 points 10 months ago Where the heck did I "shit on people using floats"? permalink fedilink source parent [–] amju_wolf@pawb.social 2 points 10 months 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". permalink fedilink source parent
[–] Treczoks@lemmy.world 20 points 10 months ago (2 children) 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. permalink fedilink source parent hideshow 4 child comments replies: [–] jasory@programming.dev 4 points 10 months ago (2 children) 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Treczoks@lemmy.world 6 points 10 months ago Yep. And in accounting this is done with integers. In my field (not accounting), calculations are done either in integer or in fixed-point arithmetic - which is basically the same in the end. Other fields work with floats. This variety exists because every field has its own needs and preferences. Forcing "One size fits all" solutions was never a good idea, especially when certain areas have well-defined requirements and standards. permalink fedilink source parent [–] soc@programming.dev 3 points 10 months ago (2 children) Yeah, but compared to counting money, nobody cares if some physics paper got its numbers wrong. :-) (Not to mention that would require the paper to have reproducible artifacts first.) permalink fedilink source parent hideshow 4 child comments replies: [–] azolus@slrpnk.net 2 points 10 months ago* We're using general relativity to calculate sattelite orbits - fuck your point of sale system if our sattelites come crashing down we're gonna have much bigger problems lol. permalink fedilink source parent [–] jasory@programming.dev 1 point 10 months ago Physics modeling is arguably the most important task of computers. That was the original impetus for building them; artillery calculations in WW2. All engineering modeling uses physics modeling, almost always linear algebra (which involves large summations). Nuclear medicine—physics, weather forecasting—physics, molecular dynamics and computational chemistry—physics. Physics modeling is the backbone of modern technology, it's why so much research has been done on doing it efficiently and accurately. permalink fedilink source parent [–] Womble@piefed.world -3 points 10 months ago* (last edited 10 months ago) (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world 4 points 10 months ago (2 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Womble@piefed.world 2 points 10 months ago* (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -2 points 10 months ago (1 child) I fail to see a difference there That I noticed some posts ago. The issue has not changed since then. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 3 points 10 months ago (1 child) And so instead of explain why and clarify any misunderstanding you chose to snarkily insult my intelligence, very mature. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -4 points 10 months ago (1 child) I did clarify my reasons. That you obviously didn't read. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 0 points 10 months 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. permalink fedilink source parent [–] FizzyOrange@programming.dev 2 points 10 months ago (2 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Treczoks@lemmy.world 2 points 10 months ago (1 child) As you said, better use integers. And that's exactly what is done at this point. permalink fedilink source parent hideshow 2 child comments replies: [–] FizzyOrange@programming.dev 0 points 10 months ago (1 child) Indeed, but there's no need to shit on people using floats because in almost all cases they are fine too. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -1 points 10 months ago Where the heck did I "shit on people using floats"? permalink fedilink source parent [–] amju_wolf@pawb.social 2 points 10 months 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". permalink fedilink source parent
[–] jasory@programming.dev 4 points 10 months ago (2 children) 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Treczoks@lemmy.world 6 points 10 months ago Yep. And in accounting this is done with integers. In my field (not accounting), calculations are done either in integer or in fixed-point arithmetic - which is basically the same in the end. Other fields work with floats. This variety exists because every field has its own needs and preferences. Forcing "One size fits all" solutions was never a good idea, especially when certain areas have well-defined requirements and standards. permalink fedilink source parent [–] soc@programming.dev 3 points 10 months ago (2 children) Yeah, but compared to counting money, nobody cares if some physics paper got its numbers wrong. :-) (Not to mention that would require the paper to have reproducible artifacts first.) permalink fedilink source parent hideshow 4 child comments replies: [–] azolus@slrpnk.net 2 points 10 months ago* We're using general relativity to calculate sattelite orbits - fuck your point of sale system if our sattelites come crashing down we're gonna have much bigger problems lol. permalink fedilink source parent [–] jasory@programming.dev 1 point 10 months ago Physics modeling is arguably the most important task of computers. That was the original impetus for building them; artillery calculations in WW2. All engineering modeling uses physics modeling, almost always linear algebra (which involves large summations). Nuclear medicine—physics, weather forecasting—physics, molecular dynamics and computational chemistry—physics. Physics modeling is the backbone of modern technology, it's why so much research has been done on doing it efficiently and accurately. permalink fedilink source parent
[–] Treczoks@lemmy.world 6 points 10 months ago Yep. And in accounting this is done with integers. In my field (not accounting), calculations are done either in integer or in fixed-point arithmetic - which is basically the same in the end. Other fields work with floats. This variety exists because every field has its own needs and preferences. Forcing "One size fits all" solutions was never a good idea, especially when certain areas have well-defined requirements and standards. permalink fedilink source parent
[–] soc@programming.dev 3 points 10 months ago (2 children) Yeah, but compared to counting money, nobody cares if some physics paper got its numbers wrong. :-) (Not to mention that would require the paper to have reproducible artifacts first.) permalink fedilink source parent hideshow 4 child comments replies: [–] azolus@slrpnk.net 2 points 10 months ago* We're using general relativity to calculate sattelite orbits - fuck your point of sale system if our sattelites come crashing down we're gonna have much bigger problems lol. permalink fedilink source parent [–] jasory@programming.dev 1 point 10 months ago Physics modeling is arguably the most important task of computers. That was the original impetus for building them; artillery calculations in WW2. All engineering modeling uses physics modeling, almost always linear algebra (which involves large summations). Nuclear medicine—physics, weather forecasting—physics, molecular dynamics and computational chemistry—physics. Physics modeling is the backbone of modern technology, it's why so much research has been done on doing it efficiently and accurately. permalink fedilink source parent
[–] azolus@slrpnk.net 2 points 10 months ago* We're using general relativity to calculate sattelite orbits - fuck your point of sale system if our sattelites come crashing down we're gonna have much bigger problems lol. permalink fedilink source parent
[–] jasory@programming.dev 1 point 10 months ago Physics modeling is arguably the most important task of computers. That was the original impetus for building them; artillery calculations in WW2. All engineering modeling uses physics modeling, almost always linear algebra (which involves large summations). Nuclear medicine—physics, weather forecasting—physics, molecular dynamics and computational chemistry—physics. Physics modeling is the backbone of modern technology, it's why so much research has been done on doing it efficiently and accurately. permalink fedilink source parent
[–] Womble@piefed.world -3 points 10 months ago* (last edited 10 months ago) (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world 4 points 10 months ago (2 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Womble@piefed.world 2 points 10 months ago* (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -2 points 10 months ago (1 child) I fail to see a difference there That I noticed some posts ago. The issue has not changed since then. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 3 points 10 months ago (1 child) And so instead of explain why and clarify any misunderstanding you chose to snarkily insult my intelligence, very mature. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -4 points 10 months ago (1 child) I did clarify my reasons. That you obviously didn't read. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 0 points 10 months 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. permalink fedilink source parent [–] FizzyOrange@programming.dev 2 points 10 months ago (2 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Treczoks@lemmy.world 2 points 10 months ago (1 child) As you said, better use integers. And that's exactly what is done at this point. permalink fedilink source parent hideshow 2 child comments replies: [–] FizzyOrange@programming.dev 0 points 10 months ago (1 child) Indeed, but there's no need to shit on people using floats because in almost all cases they are fine too. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -1 points 10 months ago Where the heck did I "shit on people using floats"? permalink fedilink source parent [–] amju_wolf@pawb.social 2 points 10 months 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". permalink fedilink source parent
[–] Treczoks@lemmy.world 4 points 10 months ago (2 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Womble@piefed.world 2 points 10 months ago* (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -2 points 10 months ago (1 child) I fail to see a difference there That I noticed some posts ago. The issue has not changed since then. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 3 points 10 months ago (1 child) And so instead of explain why and clarify any misunderstanding you chose to snarkily insult my intelligence, very mature. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -4 points 10 months ago (1 child) I did clarify my reasons. That you obviously didn't read. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 0 points 10 months 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. permalink fedilink source parent [–] FizzyOrange@programming.dev 2 points 10 months ago (2 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Treczoks@lemmy.world 2 points 10 months ago (1 child) As you said, better use integers. And that's exactly what is done at this point. permalink fedilink source parent hideshow 2 child comments replies: [–] FizzyOrange@programming.dev 0 points 10 months ago (1 child) Indeed, but there's no need to shit on people using floats because in almost all cases they are fine too. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -1 points 10 months ago Where the heck did I "shit on people using floats"? permalink fedilink source parent [–] amju_wolf@pawb.social 2 points 10 months 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". permalink fedilink source parent
[–] Womble@piefed.world 2 points 10 months ago* (1 child) 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. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -2 points 10 months ago (1 child) I fail to see a difference there That I noticed some posts ago. The issue has not changed since then. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 3 points 10 months ago (1 child) And so instead of explain why and clarify any misunderstanding you chose to snarkily insult my intelligence, very mature. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -4 points 10 months ago (1 child) I did clarify my reasons. That you obviously didn't read. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 0 points 10 months 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. permalink fedilink source parent
[–] Treczoks@lemmy.world -2 points 10 months ago (1 child) I fail to see a difference there That I noticed some posts ago. The issue has not changed since then. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 3 points 10 months ago (1 child) And so instead of explain why and clarify any misunderstanding you chose to snarkily insult my intelligence, very mature. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -4 points 10 months ago (1 child) I did clarify my reasons. That you obviously didn't read. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 0 points 10 months 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. permalink fedilink source parent
[–] Womble@piefed.world 3 points 10 months ago (1 child) And so instead of explain why and clarify any misunderstanding you chose to snarkily insult my intelligence, very mature. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -4 points 10 months ago (1 child) I did clarify my reasons. That you obviously didn't read. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 0 points 10 months 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. permalink fedilink source parent
[–] Treczoks@lemmy.world -4 points 10 months ago (1 child) I did clarify my reasons. That you obviously didn't read. permalink fedilink source parent hideshow 2 child comments replies: [–] Womble@piefed.world 0 points 10 months 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. permalink fedilink source parent
[–] Womble@piefed.world 0 points 10 months 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. permalink fedilink source parent
[–] FizzyOrange@programming.dev 2 points 10 months ago (2 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Treczoks@lemmy.world 2 points 10 months ago (1 child) As you said, better use integers. And that's exactly what is done at this point. permalink fedilink source parent hideshow 2 child comments replies: [–] FizzyOrange@programming.dev 0 points 10 months ago (1 child) Indeed, but there's no need to shit on people using floats because in almost all cases they are fine too. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -1 points 10 months ago Where the heck did I "shit on people using floats"? permalink fedilink source parent [–] amju_wolf@pawb.social 2 points 10 months 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". permalink fedilink source parent
[–] Treczoks@lemmy.world 2 points 10 months ago (1 child) As you said, better use integers. And that's exactly what is done at this point. permalink fedilink source parent hideshow 2 child comments replies: [–] FizzyOrange@programming.dev 0 points 10 months ago (1 child) Indeed, but there's no need to shit on people using floats because in almost all cases they are fine too. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -1 points 10 months ago Where the heck did I "shit on people using floats"? permalink fedilink source parent
[–] FizzyOrange@programming.dev 0 points 10 months ago (1 child) Indeed, but there's no need to shit on people using floats because in almost all cases they are fine too. permalink fedilink source parent hideshow 2 child comments replies: [–] Treczoks@lemmy.world -1 points 10 months ago Where the heck did I "shit on people using floats"? permalink fedilink source parent
[–] Treczoks@lemmy.world -1 points 10 months ago Where the heck did I "shit on people using floats"? permalink fedilink source parent
[–] amju_wolf@pawb.social 2 points 10 months 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". permalink fedilink source parent
[–] entwine@programming.dev 7 points 10 months ago (1 child) There's a good documentary about this. permalink fedilink source parent hideshow 2 child comments replies: [–] mic_check_one_two@lemmy.dbzer0.com 4 points 10 months ago Fun fact: This is actually called the Salami Shaving Scam. Basically, shave off tiny pieces of a bunch of large chunks, and eventually you’ll have a massive amount. Like taking a single slice of salami from every sausage that is sold. permalink fedilink source parent
[–] mic_check_one_two@lemmy.dbzer0.com 4 points 10 months ago Fun fact: This is actually called the Salami Shaving Scam. Basically, shave off tiny pieces of a bunch of large chunks, and eventually you’ll have a massive amount. Like taking a single slice of salami from every sausage that is sold. permalink fedilink source parent