[SOLVED] Why doesn't the 'int' function return an integer value?

[Warfley]

n(iter) is 10⁷, so ~n/20 

Oh yes you are absolutely right, the chance of landing on .5 is 1 in 10 (as there are 10 possible digits 0-9) so in 10% of cases you have an error of 0.5, while all other cases cancle out (0.2 has the inverted rounding error of 0.8, 0.6 has the negative error of 0.4 and so on) so in 90% of cases you have no rounding error and in the 10% of cases you have 0.5 error resulting in 0.5*0.1=0.05 error per operation

[TRon]

Please forgive my ignorance as I did not follow this topic but SetRoundMode ?

[Thaddy]

  Yes.

[tetrastes]

Please forgive my ignorance as I did not follow this topic but SetRoundMode ?

Yes, when you change RoundingMode from rmNearest (which is the default) to something else, the problem of rounding .5 will disappear.
But in most cases one needs rmNearest, and so deals with banker's rounding. And while it's good to count money (as it follows from its name), for many mathematical and physical tasks it's not correct.

[Warfley]

But in most cases one needs rmNearest, and so deals with banker's rounding. And while it's good to count money (as it follows from its name), for many mathematical and physical tasks it's not correct.

I mean there is no "correct way" for rounding, rounding by definition is creating an error. The question is just what kind of error you want to minimize. Nearest Even rounding minimizes the commulative error. And it's not just for counting money, it's whenever you perform multiple operations and are interested in keeping the commulative error as low as possible. For example if you do a finite difference time domain simulation in physics, where you simulate in small time steps, and rounding is performed on each step, the result of which is based on the rounded result from the first step, you also want to have the rounding error to be as small as possible.

The only area that I know of where this is not wanted is statistics, because this rounding mode favors even numbers over odd numbers (basically increasing their prevalence by 10%), so you trade off commulative error for distribution error, and in statistics when the distribution of certain values is important, this can be an issue.

General rule of thumb: Nearest even rounding is preferrable when you do multiple computations that build on top of each other. So basically pretty much anything that models complex systems over time

[tetrastes]

I mean there is no "correct way" for rounding, rounding by definition is creating an error.

You are absolutely right in this. But it's hard to say anything without seeing formulae. And there is mathematical rule for .5 rounding, and it's not "banker's". I suspect that fpc's choice (following Delphi?) reflects the field which fpc mainly aimed to.

And not all choose "banker's". F.e. see the result of this Fortran code

Code: Fortran  [Select][+][-]

1. print *, nint(1.5), nint(2.5)
2. end

or the picture:

[Warfley]

You are absolutely right in this. But it's hard to say anything without seeing formulae. And there is mathematical rule for .5 rounding, and it's not "banker's". I suspect that fpc's choice (following Delphi?) reflects the field which fpc mainly aimed to.

Has very little to do with Delphi, but it's simply the default as specified in the IEEE 754 standard for floating point operations. The reason Fortran doesn't do it this way is probably just because Frotran predates this standard. But Every language that has been implemented since then usually follows the IEEE 754 standard. And Backwards compatibility is king. You can also see this in C, where the original round function that is part of the language since the beginning rounds away from zero, but later the standard introduced a new function rint, which is compliant with IEEE 754.

Also as I said it's the default configuration of the FPU. While you can change the FPU mode, I won't advise for doing it, because this changes the behavior for everything not just that one operation in your code. So enforcing a different behavior just for your code requires emulating it in software, which is for one more difficult to implement, but more importantly also slower. So most languages don't bother.

But if you really want it, you can always just link against libc and use their round function. it's also fairly optimized and only like 10%-20% slower than the bare metal rint function

[tetrastes]

Has very little to do with Delphi, but it's simply the default as specified in the IEEE 754 standard for floating point operations. The reason Fortran doesn't do it this way is probably just because Frotran predates this standard.

But standard defines 5 modes. And one of them "Round to nearest, ties away from zero". Why TFPURoundingMode has only 4 modes?

Also as I said it's the default configuration of the FPU. While you can change the FPU mode, I won't advise for doing it, because this changes the behavior for everything not just that one operation in your code. So enforcing a different behavior just for your code requires emulating it in software, which is for one more difficult to implement, but more importantly also slower.

You mean using SetRoundMode? If this is so, why it exists at all?

[Warfley]

Probably to be compatible with the C API for fesetround and fegetround which decided to not implement on tie away from zero

[Zoran]

Simply use

Code: Pascal  [Select][+][-]

1. N := Trunc(X + 0.5);

Edit: Sorry, I see Warfley gave this solution already.

[Kays]

Why doesn’t the 𝚒𝚗𝚝 function return an integer value?

I have not really read the answer in this thread:

System.int returns a real because if it was defined to return an integer, it should be an error if a value int(x) does not exist in integer.

Code: Pascal  [Select][+][-]

1. { Two times the assignment of the value 10²⁰ − 1 to a variable, yet (potentially) different behavior. }
2. myRealVariable    := 99999999999999999999.0; { ✔ if a reasonable approximation can be achieved }
3. myIntegerVariable := 99999999999999999999;   { ↯ if > maxInt }

If you want to provoke an error if the value’s magnitude exceeds that of integer is capable of, you need to use trunc.

[tetrastes]

Simply use

Code: Pascal  [Select][+][-]

1. N := Trunc(X + 0.5);

It's not so simple, as X may be negative (though it's still simple  ).
PS. And it is slower, compared to "Round to nearest, ties away from zero" implemented in FPU.

[tetrastes]

But if you really want it, you can always just link against libc and use their round function. it's also fairly optimized and only like 10%-20% slower than the bare metal rint function

When I really want it, I use Fortran. 

[Warfley]

The only reason Fortran is sometimes faster than C is because it does not allow aliasing and therefore doesn't need stuff like write barriers and can utilize registers more effectively. In cases where the GCC or clang knows there is no aliasing conflict (iirc you can set a Compiler switch to promise the Compiler that you don't do aliasing with you pointers) it produces equally efficient code. And with the round function being implemented in the glibc directly, which is shipped with the system and usually contains different implementations optimized for different CPUs, it shouldn't be less efficient than the Fortran round function.

The reason it's slower is because either there are multiple computations, or it must set and reset the rounding mode of the fpu and this is equally true for Fortran.

[tetrastes]

Of course gfortran relies on gcc, but I remember the times when Fortran was much faster than C in number crunching on PC, and not only PC.
Now I use Fortran as a hobby, some kind of nostalgy.  :'(

EDIT. Yes, gfortran's nint simply alias for lround.    O tempora, o mores...