yes. another way to say it is that money is best considered integral in terms of some chosen "minimum accounting unit" which in the case of USD might be a dollar, a cent (1/100 dollar), or a finer thing, such as 1/100 or 1/1000 of a cent. This allows crossfooting to work, balances to zero, and other critical financial expectations to be met even when computing interest and other fractional matters.
On Fri, Aug 31, 2018 at 8:56 AM Ken MacDonald <drken...@gmail.com> wrote: > 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. > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- 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.
