Quite offtopic, but just to make sure that you are aware:

* RoundTo (1.5,0); returns 2.*

But

* RoundTo (2.5,0); also returns 2.*

Actually, I have no idea what these functions can be used for.

Round to just multiplies by the decimal factor, calls round and divides by the factor again, so basically RoundTo(val, digits) is basically just Round(val*10^digits)/10^digits.

With digits = 0 this means, it is identical to calling Round(val).

The behavior you observe is part of the functionality of how round is implemented on the FPU which is (usually configurable, but the default is) round to nearest even.

So whenever encountering .5, the round function will round to the nearest even number, in 1.5 this is 2, in 2.5 this is also 2 because 1 and 3 are odd.

So doing something like this:

for i := 1 to 10 do

WriteLn(Roun(i+0.5));

Will result in the following:

The rationale behind this is to minimize the average rounding error.

All other numbers have an "opposite" rounding error, e.g. 1.7 has a rounding error of -0.3 and 1.3 has one of 0.3. So assuming you uniformly sample the numbers to be rounded on average, there will occur as many x.7 as x.3 meaning the average rounding error cancels out.

But for 0.5 the opposite element is itself, when rounding x.5 up you have a rounding error of -0.5, when rounding it down you have a rounding error of +0.5. Therefore it was decided to simply round half of all numbers down, and half of all numbers up. This way the rounding error still averages out to 0, meaning on average computations using round will be more precise then using any other rounding method