Re: [fpc-pascal] round(2.5)=2

[Florian Klämpfl]

Am 13.06.2018 um 22:19 schrieb Marco van de Voort:

In our previous episode, Florian Kl?mpfl said:

In our previous episode, Sven Barth via fpc-pascal said:

Which is what FPC already provides with SetRoundMode() in unit Math.

As long as one changes the rounding mode only locally for some calculations
and restores it afterwards there should be no problem (the rounding mode
can be considered as thread specific as well).


Or soft fpu. (-Cfsoft). Or is that only for 16-bit mode ?


What does it change? -Cfsoft is also IEEE compliant.


I thought that Nikolai was working on a 48-bit TP real soft fpu?


Not that I am aware of? At least I cannot remember that I have seen any code.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] round(2.5)=2

[Marco van de Voort]

In our previous episode, Florian Kl?mpfl said:
> > In our previous episode, Sven Barth via fpc-pascal said:
> >> Which is what FPC already provides with SetRoundMode() in unit Math.
> >>
> >> As long as one changes the rounding mode only locally for some calculations
> >> and restores it afterwards there should be no problem (the rounding mode
> >> can be considered as thread specific as well).
> >
> > Or soft fpu. (-Cfsoft). Or is that only for 16-bit mode ?
> 
> What does it change? -Cfsoft is also IEEE compliant.

I thought that Nikolai was working on a 48-bit TP real soft fpu?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] round(2.5)=2

[Florian Klämpfl]

Am 13. Juni 2018 5:39:08 nachm. schrieb mar...@stack.nl (Marco van de Voort):

> In our previous episode, Sven Barth via fpc-pascal said:
>> Which is what FPC already provides with SetRoundMode() in unit Math.
>>
>> As long as one changes the rounding mode only locally for some calculations
>> and restores it afterwards there should be no problem (the rounding mode
>> can be considered as thread specific as well).
>
> Or soft fpu. (-Cfsoft). Or is that only for 16-bit mode ?

What does it change? -Cfsoft is also IEEE compliant.

> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] round(2.5)=2

[Marco van de Voort]

In our previous episode, Sven Barth via fpc-pascal said:
> Which is what FPC already provides with SetRoundMode() in unit Math.
> 
> As long as one changes the rounding mode only locally for some calculations
> and restores it afterwards there should be no problem (the rounding mode
> can be considered as thread specific as well).

Or soft fpu. (-Cfsoft). Or is that only for 16-bit mode ?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] round(2.5)=2

[Santiago A.]

El 12/06/2018 a las 23:12, Klaus Hartnegg escribió:

Am 11.06.2018 um 10:01 schrieb Michael Schnell:
 - the way of rounding is defined by the CPU hardware, even old Turbo 
Pascal executables do banker's rouding on modern hardware.


No, it does not depend on the hardware, but on the setting of $N. 
Turbo Pascal with $N+ rounds like FreePascal. But the default is $N-. 
In this mode Turbo Pascal always rounds up.


var
  a : real;
begin
  a := 35;
  writeln (round(a*1.1));
end.

FreePascal: 38
Turbo Pascal: 39

And when the compiler precalculates a constant expression, it always 
rounds up as well, regardless of $N.


Nobody expects that increasing a number by 10% will depend on whether 
the resulting number will be close to an even integer. That feels 
completely erratic.


I don't feel it is completely erratic. If instead of 35 it were 135 
would you mind if the result were 1100038 or 1100039? When you round 
small numbers, relative rounding errors skyrocket, that is a fact of 
life. Any software must be aware of this and live with it.




This behaviour does have advantages in the special case of adding up 
many rounded numbers, but it ruins the graphics output of my software. 
It should at least be configurable. And in {$mode tp} it should behave 
like Turbo Pascal, because that's what this mode is made for.


  - SetRoundMode is not only dangerous, but does not help, anyway, as 
there is no mode defining the "intuitive " "non-banker rouding" method.


That's why I'm looking for a better solution. The the only *reliable* 
solution appears to be compiling a modified version of FreePascal.
I think that is even more dangerous. Who knows how many internal 
freepascal will fail when you change rounding. It would be better to 
review  software to check  why it needs always round floor for 0.5




Klaus
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



--
Saludos

Santiago A.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] round(2.5)=2

[Sven Barth via fpc-pascal]

Wolf  schrieb am Mi., 13. Juni 2018, 09:27:

> Why not ask the CPU to do the rounding? This is what Intel offers in
> volume 1 of the Intel ® 64 and IA-32 Architectures Software Developer's
> Manual:
> 4.8.4.1
>  Rounding Control (RC) Fields
> In the Intel 64 and IA-32 architectures, the rounding mode is controlled
> by a 2-bit rounding-control (RC) field
> (Table 4-8 shows the encoding of this field). The RC field is implemented
> in two different locations:
> •
>  x87 FPU control register (bits 10 and 11)
> •
>  The MXCSR register (bits 13 and 14)
> Although these two RC fields perform the same function, they control
> rounding for different execution environ-
> ments within the processor. The RC field in the x87 FPU control register
> controls rounding for computations
> performed with the x87 FPU instructions; the RC field in the MXCSR
> register controls rounding for SIMD floating-
> point computations performed with the SSE/SSE2 instructions.
>
> Do you want more?
>

Which is what FPC already provides with SetRoundMode() in unit Math.

As long as one changes the rounding mode only locally for some calculations
and restores it afterwards there should be no problem (the rounding mode
can be considered as thread specific as well).

Regards,
Sven

PS: please don't add images as inline content, the archive can't display
them correctly.

> 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] round(2.5)=2

[Wolf]

Why not ask the CPU to do the rounding? This is what Intel offers in 
volume 1 of the Intel ® 64 and IA-32 Architectures Software Developer's 
Manual:



4.8.4.1
 Rounding Control (RC) Fields
In the Intel 64 and IA-32 architectures, the rounding mode is controlled 
by a 2-bit rounding-control (RC) field
(Table 4-8 shows the encoding of this field). The RC field is 
implemented in two different locations:

•
 x87 FPU control register (bits 10 and 11)
•
 The MXCSR register (bits 13 and 14)
Although these two RC fields perform the same function, they control 
rounding for different execution environ-
ments within the processor. The RC field in the x87 FPU control register 
controls rounding for computations
performed with the x87 FPU instructions; the RC field in the MXCSR 
register controls rounding for SIMD floating-

point computations performed with the SSE/SSE2 instructions./
/
Do you want more?

Wolf


On 13/06/2018 09:58, Klaus Hartnegg wrote:

Am 12.06.2018 um 23:24 schrieb Jonas Maebe:

On 12/06/18 23:12, Klaus Hartnegg wrote:
This behaviour does have advantages in the special case of adding up 
many rounded numbers, but it ruins the graphics output of my 
software. It should at least be configurable. And in {$mode tp} it 
should behave like Turbo Pascal, because that's what this mode is 
made for.


The basic issue is that FPC doesn't support the 6 byte real type used 
by TP in {$n-}, nor the associated behaviours such as rounding, 
range/precision cut-offs etc. FPC indeed can only support TP {$n+} 
mode compatibility at this time (and even that is not always exact, 
as it depends on the FPU precision support by the hardware and OS).


Nevertheless it could offer an option to use the other rounding method.

Yes, there would still be deviations in some math results, because of 
the different precision. But these deviations are much smaller than 
those from the other rounding method.


Klaus
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] round(2.5)=2

[Michael Schnell]

On 12.06.2018 09:01, Mattias Gaertner wrote:

Floats can represent 1.5 exactly.
Of course I do know how the binary representation of floats is done on 
X86 and similar architectures, and hence that same provides a bit 
combination that exactly defines 1.5.


That is why I did say *relying* on the exact value of a real number is 
erroneous. (Supposedly with the common archs, no representation of a 
rational a/b will be exact but those with b = 2**n).


But for an application programmer it should not be considered common 
knowledge, that on the architecture his program is to run on, 3/2 can be 
represented exactly while 2/3 can't.


That is why an application programmer should be trained not to do any 
assumptions which float value is to be considered  to be exact and which 
is not.


-Michael
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal