# strategies for dealing with machine epsilon

Say you have a situation where you divide and then multiply a float, and you need to guarantee that it survives macheps (ie multiplication output equals division input). What are known strategies for guaranteeing this? Rounding would work, but anything else?

• Use a different type that represents numbers as fractions. Then you can represent all rational numbers exactly. Mar 17, 2013 at 12:03

Traditionally, you multiply FIRST, and THEN you divide.

If your hardware and compiler are smart enough, the instructions emitted will preserve the full double-width result of the multiplication, for processing by the division.

Dividing first and then multiplying, you can't really do that. (Your compiler MIGHT at that point be smart enough to reorder the operations, but you are usually safer doing it yourself.)

Read Hamming's Numerical Methods for Scientists and Engineers. Early in the book, he goes into considerable detail on reorganizing your computations to reduce this kind of trouble. It's available from Dover. (If technical literature is your fetish, like it is mine, Dover is your FRIEND!)

Actually this error happens not only because of multiplication, it can be reproduced by a simplier way: `0.1 + 0.2`

There is a special website for this issue: http://floating-point-gui.de/

What can I do to avoid this problem?

That depends on what kind of calculations you’re doing.

• If you really need your results to add up exactly, especially when you work with money: use a special decimal datatype.
• If you just don’t want to see all those extra decimal places: simply format your result rounded to a fixed number of decimal places when displaying it.
• If you have no decimal datatype available, an alternative is to work with integers, e.g. do money calculations entirely in cents. But this is more work and has some drawbacks.

You can't guarantee that. Not while using floats, anyway. As the comment says, if you need a guarantee, you can use arbitrary-precision fractions.

In general, rounding doesn't offer such a guarantee, either -- you need to do some actual math before you can be confident it works within the range of your particular application.

The real question is: why do you think you need a guarantee? Your question suggests that you need to actually, seriously devote some effort to considering this, because its answer is likely the most relevant and important part of actually solving your problem, and you have not provided enough information to enable any more detailed constructive advice.