forums.silverfrost.com

AlisonV · Joined: 14 Sep 2015 Posts: 4 Location: Brisbane

realvar = 31.5
intvar = NINT(realvar)

When I compile these lines into a DLL (which is called by a C# GUI), intvar shows the value 31.
When I compile these lines as part of an EXE, intvar shows the value 32. I'm using the silverfrost compiler in both cases, with reals set to kind=2.

Is this behaviour expected? If it is, is there a way to force 0.5 to be rounded up (or at least to show the same value)?

Many thanks

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

I don't have an explanation for the DLL performance.
Is the expression "realvar = 31.5" exactly as you have typed ?
If the result of getting to 31.5 has some rounding noise so was less than 31.5, you would get the result 31.

31.5 when converted into a binary real is an exact representation, as there are lots of trailing zeros.
31.5 = 2^4 + 2^3 + 2^2 + 2^1 +2^0 + 2^(-1)

It should round up to 32.

The following code tries to demonstrate how 31.5 is mostly zeroes, but noise could change that.

mecej4 · Joined: 31 Oct 2006 Posts: 1886

AlisonV · Joined: 14 Sep 2015 Posts: 4 Location: Brisbane

Thanks Everyone. I'm sure precision must play a part in this .. but this happens dependent on whether the code is compiled by Silverfrost as a DLL or EXE. All other compiler settings are the same (as is possible).

Here's an expanded code block to better demonstrate the issue. The code is part of a calculation for percentiles - ivar selects the array element to return for a given percentile.

REAL :: rvar
INTEGER ::ivar,n,pc

n=45
pc=30
rvar= REAL(n)*((100.0-REAL(pc))/100.0)
ivar = NINT(rvar)

When I place the above self-contained code inside a DLL - the value for ivar is 31.
However, when I place this exact same code inside an EXE, the value for ivar is 32.
When I set rvar = 31.5, ivar does return 32 for both the DLL and EXE (apologies for misleading in previous post).

The DLL is Fortran Subroutine Main compiled in CLR mode as a DLL within a C# project. The EXE is the same Subroutine Main code, called by a Fortran input and output program.

PaulLaidler · Posted: Wed Sep 16, 2015 7:03 am Post subject:

Try using /explist on the FTN95 command line.
The resulting .lis file will show how the calculation proceeds in the two cases.

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

It isn't unusual for compilers to generate different assembly for the same code. You may just have one value that is a bit smaller than 31.5 and another that is a bit larger. In which case both answers are correct.

You could try re-writing your expression to minimise roundoff errors, something like:

LitusSaxonicum · Posted: Wed Sep 16, 2015 7:30 pm Post subject:

Sometimes, a standard function isn't the answer (particularly when I can't remember that one exists), and you have to do it yourself. A real to integer assignment always rounds down, and if you want to round up, then add 1 after rounding down.

You then get to decide how the difficult cases are dealt with when you code it yourself. Davidb's approach is a DIY round to nearest that lets you know what happens in every case.

Eddie

JohnCampbell · Joined: 16 Feb 2006 Posts: 2554 Location: Sydney

What does the rounding of exactly 31.5 mean anyway ? by convention 32
realval = nearest (31.5,-1.0) ! nearest real less than 31.5 is rounded to 31 ?

However shouldn't 31.4999999 be rounded to 31 ?
Given the rounding in the format writer, this becomes displayed as 31.500000 and so should be seen as being rounded to 32

In recording numbers in experiments, the meaning of rounding also becomes confused.
if the reading was initially 31.447
rounding to 2 sig fig becomes 31.45
then to 1 becomes 31.5
then to 0 becomes 32

So the history of the recording accuracy becomes an issue

This is the problem with roundoff

mecej4 · Joined: 31 Oct 2006 Posts: 1886

Repeated rounding with insufficient precision can produce absurd results. There is an infamous example from 1982, relating to the Vancouver stock exchange. From https://en.wikipedia.org/wiki/Vancouver_Stock_Exchange :

alex21 · Joined: 20 Apr 2011 Posts: 75 Location: Australia

Hello,

To clarify the code is behaving differently when it is compiled as Win32 vs .NET, I believe this relates to the default behavior of Math.Round() in the CLR which will round down from .5 unless MidpointRounding.AwayFromZero is specified.

Could this be what is leading to the difference in the behavior of the code when compiled for .NET vs Win32?

Thanks,
Alex.

AlisonV · Joined: 14 Sep 2015 Posts: 4 Location: Brisbane

I've totally missed PaulLaidler's post above. Below is part of the .lis file for the main subroutine when running it within the DLL. Any suggestions as to a solution would be welcome!

Thanks again,
Alison

IanLambley · Joined: 17 Dec 2006 Posts: 490 Location: Sunderland

Try this and see what happens.

mecej4 · Joined: 31 Oct 2006 Posts: 1886

The issue is related to basic binary real arithmetic and not to DLL/EXE or native/CLR.

Here is what happened. Consider the expression given in #1:

AlisonV · Joined: 14 Sep 2015 Posts: 4 Location: Brisbane

Thanks heaps mecej4 and everyone! Removing the brackets did allow a larger value to be divided by the 100.0, resulting in the desired answer of 32 for both the DLL and EXE. I am now getting the same (expected) answers for the percentile calculations from both DLL and EXE forms of the Main code.

Thanks also for the explanation - I will keep in mind the need to use brackets more carefully when dealing with double precision numbers.