20 replies to this topic

[poita]

.oisyn said:

I don't think the approach should be to work with rounded numbers, but rather with exact numbers. The input are digits from text so you have finite precision, perfectly representable by rational numbers. The problem was square roots were hard to do on rational numbers. But converting it to float will not be a problem if the square root is the last calculation you'll do, as whole numbers can be represented exactly by floats and doubles (well, as long as their precision is within respectively 24 and 53 bits) - you'll throw away the bits after the decimal dot anyway.

trunc(sqrt(x) / 0.1) = trunc(sqrt(x) / sqrt(0.01)) = trunc(sqrt(x / 0.01))

In your example, if the 2.1 was the result of squarerooting 4.41 (also unrepresentable by float), you would avoid the problem if you have 4.41 represented as a rational number: 441/100. Dividing by 0.01 gives the rational number 441. The square root of 441.f is 21.f. Truncating will reveal 21.

You'll never get into trouble because the bordercase lies on the whole number. But if the result of a squareroot is a whole number, it's square is also a whole number and thus representable by a float or double.

Nice :yes: I didn't think about that last thing you said about the bordercase. I just discarded rational numbers as a solution because of the squareroot but as you said, in the cases where I'm having trouble the squareroot will be rational.

I think I'll right a rational number class before the competition just in case I need it.

Thanks everyone for your input.