3 ms·
People often say "Just use (x) decimal arithmetic system for important stuff like finances." Out of curiosity, I'm wondering how much trade you would have to b
by Cushman 16y ago
People often say "Just use (x) decimal arithmetic system for important stuff like finances."
Out of curiosity, I'm wondering how much trade you would have to be doing for floating-point imprecision to cause an actual problem.
Taking 0.2+0.1 as an example and figuring an imprecision of $0.00000000000000004 per $0.30, figuring a loss of one cent as being significant, I have 0.01/(0.00000000000000004 / 0.3) = 7.5e13, or... seventy-five trillion dollars?
Never mind that you're as likely to get 0.6+0.1 = 0.69999999999999996, which should roughly cancel out the error over time.
This is basically just an aesthetic problem in finance, yes?
- flatline 16y agoThere is a term for this in mathematics and now I can't remember it, but with some systems, e.g. number crunching with large matrices, a very small change like this can magnify into huge differences and give you totally wrong results. It's definitely something you must be aware of and take into account.
- Cushman 16y agoYeah, I guess if you're doing more complex math with the figures than just addition and subtraction there's the possibility for magnification effects. I'd be interested to see an actual example from business, though.
- anigbrowl 16y agoDon't know about business, but when you're working with audio it's very common to multiply the contents of a stream against those of an array, such as a filter kernel with the coefficients computed in advance. With multiple channels which are being mixed in unpredictable ways, there's plenty of room for errors to propagate. Most of the time the only result is an imperceptible rise in noise, but it's not uncommon to have threshold-dependent routing of signal flow or for audio signals to used as input to modulation processors and vice versa. Every audio synthesis tool I've ever used had at least one bug resulting from error accumulation. They don't stand out very well in testing, but then people start reporting things like I was playing a tune with this patch and stopped to eat dinner, but when I came back my keyboard would only make a horrible noise, is it broken?
- regularfry 16y agoConditional stability?
- silvestrov 16y agoNope, it makes code more complex. For example, if the customer makes payments in 2 installs and you want to check if they have payed the full amount, you can't do "if (a + b >= c)" if you use floating point. You'd have to use something like "if (a + b >= c - 0.01)". A normal double (IEEE 64) has only ~15 digits of precision, so when the amounts grow large, you loose the precision for the cents. Example (in Java, which uses IEEE): double d = 1e9; System.err.println("d: " + d); d += 0.01; System.err.println("d: " + d); d -= 1e9; System.err.println("d: " + d); d -= 0.01; System.err.println("d: " + d); What is 'd' at the end? Not zero. This adds a gazilion weird cases in the code that you have to handle. Some countries have laws are very strict about how rounding should be performed and that all amounts must be an integral number of 'cents', so using doubles are completely out of the question in those cases.
- silentbicycle 16y agoAnother example would be conversion dimensions back and forth between imperial and metric. If you're using floating point carelessly, it can introduce enough distortion to derived calculations (say, volume or material cost per cubic meter) to cause pricing or manufacturing errors.
- jessriedel 16y ago> which should roughly cancel out the error over time. To be pedantic, if the errors of size e are as likely to go one way as the other for each of N steps, the expected magnitude of the total error will be sqrt(N)e. It's a random walk.