The calculation error doubles with every calculation step, no matter how big epsilon is, you can construct a counterexample, where your rule breaks.

The error only doubles with every step if your algorithm is numerically badly conditioned.

For usual non-numeric calculations such errors tend to stay very small, unless you do things like substracting two numbers of nearly the same size, and dividing by the result.

If you do numerics, you should inform yourself in more detail about floating point arithmetics and error propagation (a standard subject in applied mathematics).

IMHO that's a ridiculous big effort compared to the normal possibility to stay integer right away by multiplicating the fractions away.

That might be true for literal constants, but when you read several numbers from user input, it gets very quickly very tedious to track the smallest possible multiplier, and outright stops working if you need to divide by a user-supplied number.

Another solution is to use a data type which stores numerator and denominator separately as integers, as Perl 6 does.

If you do numerics, you should inform yourself in more detail about floating point arithmetics and error propagation (a standard subject in applied mathematics).

Moritz it's first year computer science...

Cheers Rolf

I did a semester in computer science, and we only learned about floating point arithmetics, not about error propagations. But of course that can vary with country, university and course.