for money there is a natural limit to the number of digits that are useful, with certain exceptions <https://www.businessinsider.com/venezuela-hyperinflation-in-pictures-2018-8#a-24-kilogram-chicken-is-pictured-next-to-146-million-bolvars-or-222-2> . add to this the number of digits of fractional precision desired (4? 20? whatever) and you end with a reasonably small byte size.
64 bit uint, taken as decimal gives you 18 decimal digits. two of these with an implicit decimal point between high and low quadwords, gives you 999 quadrillion dollars with inversely fine precision. basic math ops will be 3x to 8x slower. all rounding will be perfectly and understandably managed. no need for arbitrary precision. On Sun, Sep 2, 2018 at 3:54 PM José Colón <jec....@gmail.com> wrote: > This thread is very similar to what you can find if you do a Web search > for how to handle financial calculations. From my perspective, and like all > matters in programming, the answer is "it depends". It depends on your > goals; do you want the highest performance, the highest precision, comply > with regulations, code readability / maintainability? It all depends. > Languages like Java and Python have their pre-built packages that make > infinite precision calculations easy for the programmer, but at a > performance penalty. My original question regarding Go floats, later > learning that the behavior is not of floats but of untyped constants, makes > me wonder if a package that could provide similar ease of use in performing > infinite precision calculations would be a good idea to have in Go's > standard library (like Java's BigDecimal or Python's decimal module). Or > then again, maybe this is already provided by the math/big package? > > > 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. > -- *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.
