Financial applications are, indeed, typically written using some sort of integer representation; some that I've worked with require smaller than "penny" level representations, say, for commodity pricing. I have seen accounting done with floating point. It didn't end well. One of the problems is that floating point operations are just "close enough" to LOOK correct a lot of the time, and print "correctly" when rounded off, but things like interest calculations leave one with very odd fractions of pennies that will cause very interesting problems that are not immediately obvious. For instance, I earn a bit of interest on my checking account, so the floating value stored in the DB is now something like $66.6579423452. I look at my statement and my balance prints as $66.66, so I write a check for 66.66, and when it's cashed I suddenly display a balance of -0.00, and have an overdraft charge. Historical note: I came into contact with the "floating accounting" project after it was nearly a year in progress, and pointed this out to them, and gave them simple examples to run to prove their stuff wouldn't work, and it didn't. They had spent an awful lot of money to get to that point, and re-engineering it would have cost a lot more - they tried that, but the project - and the company - eventually failed. Lesson: financial applications, and generally most applications that rely on discrete values, should NOT be written in floating point.
On Thu, Aug 30, 2018 at 12:51 PM José Colón <jec....@gmail.com> wrote: > From what I've seen in the wild and searching for options on the Web, > using big integers to store the lowest denomination of any given currency > is very popular indeed, and I suspect ir should also perform better as a > bonus. > > On Wednesday, August 29, 2018 at 10:33:16 PM UTC-4, José Colón wrote: >> >> I read that a common way to demonstrate that floating point numbers >> suffer from approximation problems is by calculating this: >> >> 0.3 - 0.1 * 3 >> >> which should produce 0 but in Java, Python, and Javascript for example, >> they produce -5.551115123125783e-17 . >> >> Surprisingly (or not, ;) ), Go produces the correct 0 result! I wonder >> why is this so? Is it some higher precision being used versus these other >> languages? Or is it some extra correcting logic behind the scenes? >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
