Please check some of the online papers on Posit numbers and Unum computing, especially by John Gustafson. In general, Unums can represent more numbers, with less rounding, and fewer exceptions than floating points. Many software and hardware vendors are starting to do interesting work with Posits.
0.30000000000000004
371–380 of 422 posts
Re: 0.30000000000000004
#372Earlier quoted context omitted.
Decimal numbers are not conceptually any more or less exact than binary numbers. For example, you can't represent 1/3 exactly in decimal, just like you can't represent 1/5 exactly in binary. When handling money, we care about faithfully reproducing the human-centric quirks of decimal numbers , not "being more accurate". There's no reason in principle to regard a system that can't represent 1/3 as being fundamentally…
Money are really best dealt with as integers, any time you'd use a non-integer number, use some fixed multiple that makes it an integer, then divide by the excess factor at the end of the calculation. For instance computing 2.15% yearly interest on a bank account might be done as follows: DaysInYear = 366 InterestRate = 215 DayBalanceSum = 0 for each Day in Year DayBalanceSum += Day.Balance InterestRaw = DayBalanceSu…
>Money are really best dealt with as integers
I wish I could up vote you more than once. You are bang on.
Re: 0.30000000000000004
#373The big issue here is what you're going to use your numbers for. If you're going to do a lot of fast floating point operations for something like graphics or neural networks, these errors are fine. Speed is more important than exact accuracy. If you're handling money, or numbers representing some other real, important concern where accuracy matters, most likely any number you intend to show to the user as a number, f…
> I'd really appreciate it if Javascript had a native decimal number type like that. Was proposed in the late 90's Mike Cowlishaw but the rest of the standards committee would have none of it.
A new proposal for adding arbitrary-precision Decimal support to JavaScript is being presented at TC39 this week.
Proposal: https://github.com/littledan/proposal-bigdecimal
Slides: https://docs.google.com/presentation/d/1qceGOynkiypIgvv0Ju8u...
Re: 0.30000000000000004
#374The big issue here is what you're going to use your numbers for. If you're going to do a lot of fast floating point operations for something like graphics or neural networks, these errors are fine. Speed is more important than exact accuracy. If you're handling money, or numbers representing some other real, important concern where accuracy matters, most likely any number you intend to show to the user as a number, f…
In the world of money, it is rare to have to work past 3 decimal places. Bond traders operate on 32nds, so that might present some difficulties, but they really just want rounding at the hundreds. Now, when you’re talking about central bank accruals (or similar sized deposits) that’s a bit different. In these cases, you have a very specific accrual multiple, multiplied by a balance in the multiple hundreds of billion…
I'm curious about the "off tape" part. Presumably this means not on a ticker or not made public somehow - how are these transactions publicized and/or hidden?
Re: 0.30000000000000004
#375Earlier quoted context omitted.
You use that library when you want fractional values right? That is, numbers with a binary point but not floats.
For the most part, I use longs (for instance a FixedVec is a (long,long,long) struct where 1 = 1/1000 of a meter). However, complicated calculations or anything involving angles or other math functions quickly becomes more convenient when expressed as a Fix64, which is more or less a drop in replacement for float. I would ideally use Fix64 everywhere, but given the torturous route the C# takes to be transformed into…
That's rough, fortunately for my own projects I'm only doing Unity on desktop, so I haven't had to go this far.
Even something simple like multiplying up and dividing down quickly adds a lot of overhead, and when running on mobiles you really need all the speed you can get.
Re: 0.30000000000000004
#376Earlier quoted context omitted.
Well, if your decimals are fixed-point decimals, which is the case in finance, decimal calculations are very cheap integer calculations (with simple additional scaling in multiplication/division). I just use Zarith (bignum library) in OCaml for decimal calculation, and pretty content with performance. I don't think much domains needs decimal floating point that much, honestly, at least in finance and scientific calcu…
Why doesn't everybody do it this way then? We would probably have a transparent built-in decimal type in every major language by now if there were no problems with this.
> Why doesn't everybody do it this way then?
Why? Fintech uses decimal fixed-point all the way, there are libraries for them for any major language. Apps like GnuCash or ledger use them as well.
Re: 0.30000000000000004
#377Earlier quoted context omitted.
Beware that BCD, and decimal in general, accumulates roundoff error at a much higher rate than binary, if you do any inexact operations. It is more common these days to use base-1000, instead, when you need exact decimal representations. You can fit three base-1000 "digits" in a 32-bit word, with two bits left over for sign plus any other flag you find useful. (One such use could be to make a zero in the second place…
"Much, much better" in what sense? Just performance?
Performance, correctness, and maintainability. The amount of code needed is very small, and uses native instructions for the work, which are pretty well-tested.
Re: 0.30000000000000004
#378Please check some of the online papers on Posit numbers and Unum computing, especially by John Gustafson. In general, Unums can represent more numbers, with less rounding, and fewer exceptions than floating points. Many software and hardware vendors are starting to do interesting work with Posits.
Probably one of the more in depth technical discussions of the pros and cons of the various proposals that John Gustafson has made over the years:
https://discourse.julialang.org/t/posits-a-new-approach-coul...
Re: 0.30000000000000004
#379Earlier quoted context omitted.
World GDP is around 87 trillion dollars. $ ruby -e 'pp 87e12 + 0.01' 87000000000000.02 If you're certain that your software will never handle national-economy-scale or hyperinflationary use cases, then sure, you may be able to get away with 64-bit floats, but I think "no need to worry" is overstating your case. Please do worry about precision until you've proven you don't need to.
Yeah, I should had be more careful with my words. For the vast majority of person, there is no need to worry so much about using fp to represent currencies. There are other issues with float that will bite you in your back before precision became one of them.
Depending on context, you can assume that precision will bite you.
The problem is that rounding is kind of a big deal in certain financial contexts, and the process of rounding can greatly magnify floating point's decimal precision problems when you're dealing with numbers that are close to the .5's.
When I said up above that there are some contexts where IEEE floats are fine, those contexts are largely ones where you never have to round, or where you can guarantee that an accountant is never going to see or care how you rounded. So, to an approximation: Go ahead and fearlessly implement the Black-Scholes formula using doubles, but never, ever use them to do something simple like calculating an invoice.
Re: 0.30000000000000004
#380Earlier quoted context omitted.
> Floats aren’t random. They’re perfectly deterministic, predictable and reproducible. If you do the same operation in two places you get the same result. That's not exactly true in real hardware, or at least it wasn't until ~10 years ago. With the x87 FPU, internal precision was 80 bits, while the x86 registers were at most 64 bits. So, depending on the way the program would transfer data between the CPU and FPU you…
In a language like Java, all these factors are specified and fully deterministic.
False. Floating-point arithmetic in Java is generally nondeterministic. You will notice that the strictfp keyword exists and is off by default.