Hello,

In Xbase++ 1.9 main thread, the Round() function returned as its equilavent 
Excel.
For example, Round( 0.3 * 1.65, 2 ) returned 0.50.

Currently, in Xbase++ 2.0 the same function returns 0.49 like Clipper.

This is a big problem to applications that uses Round function, breaking 
backward compatibility for each Xbase++ version.
In my country, this is a serious problem because all invoice documents must 
have an hash control which becomes invalid.
This way I can´t use Xbase++ 2.0 in production, i paid in November 2014.

I was talking with Alaska Software Suport Team and I sugested a creation of 
another function that make Round() calculations like 1.9 but they deny.
To solve the problem, I used the function RoundX() below that works 
aparently well but in certain rare complex document calculations return 
wrong compared to 1.9 Round().

FUNC RoundX( nValue, nDecimals )
   IF nValue > 0.0
      RETURN Round( nValue + 0.0000000001, nDecimals )
   ELSEIF nValue < 0.0
      RETURN Round( nValue - 0.0000000001, nDecimals )
   ENDIF
RETURN Round( 0.0, nDecimals )

Now, I come to public to seach for some help because can´t find a solution 
in 623 build.

Best regards,
Carlos

Carlos,

>For example, Round( 0.3 * 1.65, 2 ) returned 0.50.

Please take a look at my response in the thread: "Problem with round" in the
"public.xbase++.bugreport" NewsGroup from June 27, 2015. Basically what you 
should do is a simple two-step rounding process. This will work for all
numbers and all versions of Clipper and Xbase++.

Just use the following replacement round function:

Function RoundX(nValue, nDecimals, nPrecission)
LOCAL nInitial := iif(empty(nPrecission), nDecimals + 1, nPrecission)
return (Round(Round(nValue, nInitial), nDecimals))

And here is a sample program to show you how and why this works:

Procedure Main()
LOCAL nValue := 0.3 * 1.65
   QOut('       0.3 * 1.65        ==> ' + str(       nValue       , 22, 20))
   QOut(' Round(0.3 * 1.65, 2)    ==> ' + str( Round(nValue, 2)   , 22, 20))
   QOut('RoundX(0.3 * 1.65, 2)    ==> ' + str(RoundX(nValue, 2)   , 22, 20))
   QOut('RoundX(0.3 * 1.65, 2, 2) ==> ' + str(RoundX(nValue, 2, 2), 22, 20))
   QOut('RoundX(0.3 * 1.65, 2, 3) ==> ' + str(RoundX(nValue, 2, 3), 22, 20))
   QOut('RoundX(0.3 * 1.65, 2, 4) ==> ' + str(RoundX(nValue, 2, 4), 22, 20))
   QOut('RoundX(0.3 * 1.65, 2, 8) ==> ' + str(RoundX(nValue, 2, 8), 22, 20))
return

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
web:   http://www.Aerospace-History.net

Andreas,

Your function RoundX() suffer similar problem of mine.
I tried also with Val( Str( RoundX() ) ) without sucess. Only aparently we 
obtain the same result.

In a customer with 2000 invoices, one of them with 21 rows have a diferent 
final value 763.99€ compared to 1.9 version 763.98€.
Without RoundX() in 2.0 the same customer have 5 diferent invoices compared 
to 1.9.

So I think that the solution is the company provide original 1.9 Round() 
function with another name.

I'm using windows 10 64bit.

Thank you,
Carlos




"Andreas Gehrs-Pahl" escreveu na mensagem 
news:18mh513kdsgpa$.fv3g0gf8u0j2.dlg@40tude.net...

Carlos,

>For example, Round( 0.3 * 1.65, 2 ) returned 0.50.

Please take a look at my response in the thread: "Problem with round" in the
"public.xbase++.bugreport" NewsGroup from June 27, 2015. Basically what you
should do is a simple two-step rounding process. This will work for all
numbers and all versions of Clipper and Xbase++.

Just use the following replacement round function:

Function RoundX(nValue, nDecimals, nPrecission)
LOCAL nInitial := iif(empty(nPrecission), nDecimals + 1, nPrecission)
return (Round(Round(nValue, nInitial), nDecimals))

And here is a sample program to show you how and why this works:

Procedure Main()
LOCAL nValue := 0.3 * 1.65
   QOut('       0.3 * 1.65        ==> ' + str(       nValue       , 22, 20))
   QOut(' Round(0.3 * 1.65, 2)    ==> ' + str( Round(nValue, 2)   , 22, 20))
   QOut('RoundX(0.3 * 1.65, 2)    ==> ' + str(RoundX(nValue, 2)   , 22, 20))
   QOut('RoundX(0.3 * 1.65, 2, 2) ==> ' + str(RoundX(nValue, 2, 2), 22, 20))
   QOut('RoundX(0.3 * 1.65, 2, 3) ==> ' + str(RoundX(nValue, 2, 3), 22, 20))
   QOut('RoundX(0.3 * 1.65, 2, 4) ==> ' + str(RoundX(nValue, 2, 4), 22, 20))
   QOut('RoundX(0.3 * 1.65, 2, 8) ==> ' + str(RoundX(nValue, 2, 8), 22, 20))
return

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
web:   http://www.Aerospace-History.net

Carlos,

>I'm using windows 10 64bit.

In that case, please see PDR 6678, which states that the issue is caused by 
the way Windows executes 32 Bit processes on 64 Bit CPUs. This PDR is marked 
as closed on 06/29/2015 with Build 2.00.598, so the "fix" -- if there was 
one -- should be in the current release of Xbase++, 2.00.623.

As the web-based PDR (text) search is not very accurate and misses a lot of 
valid entries as well as showing a lot of irrelevant ones when you do a text 
search, use the following URL to view it:

http://www.alaska-software.com/scripts/waa001.dll?WAA_PACKAGE=PUBLICDTS&WAA_FORM=DISPLAYPDR&PDRID=6678

Unfortunately, the Alaska Xbase++ Knowledge Base (or PDR system) doesn't say 
anything about how a PDR was "fixed" when it is closed. So it could very 
well be that this was closed as "This is Microsoft's fault and we can't do 
anything about it" without any change or fix being applied to the Xbase++ 
product. So I suggest that you use the latest build and run the test on your 
64-bit hardware (on Thread 1) to see if there is a difference. 

Another possible solution is indicated by the fact that the PDR mentions 
that the issue is only observable on Thread 1. So, you could try to run your 
routine (with your current version of Xbase++) in another thread, and see if 
that makes any difference.

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
web:   http://www.Aerospace-History.net

Hi Andreas,

Let me please clarify this:

> Unfortunately, the Alaska Xbase++ Knowledge Base (or PDR system) doesn't 
> say
> anything about how a PDR was "fixed" when it is closed. So it could very
> well be that this was closed as "This is Microsoft's fault and we can't do
> anything about it" without any change or fix being applied to the Xbase++
> product. So I suggest that you use the latest build and run the test on 
> your
> 64-bit hardware (on Thread 1) to see if there is a difference.

We do not document how a problem was resolved because
the information about is not relevant in almost all cases.
Additionally a resolution often affects the runtime internals.

If Xbase++ code from xppsys is affected then the location
often is given in the PDR description and a workaround is
given in the solution section. Often the fix is to apply the
solution to the code base.

The important point always is the behaviour of the system. Let's
take PDR 6678. Round returns 0.5 on 64 Bit machines on thread 1.

Because the PDR was closed you may assume that the result
is again consistent, meaning Round() returns identical
numeric values on all threads, Plus the behaviour on 64 Bit
machines is the same compared to 32 Bit machines.

We will never Close a PDR by definition without mentioning this
fact in the PDR description. Otherwise this would result in
much confusion in our customer base.

In case you are still curious: The fix for PDR 6678 was a
modification of the C-Runtime initialization sequence 

Hope this clearifies things a little bit.

Andreas Herdt
Alaska Software

-------------------------------------------------------------------- 

Technical Support: support@alaska-software.com

News Server: news.alaska-software.com
Homepage: http://www.alaska-software.com
WebKnowledgeBase: http://www.alaska-software.com/kbase.shtm

Fax European Office: +49 (0) 61 96 - 77 99 99 23
Fax US Office: +1 (646) 218 1281
-------------------------------------------------------------------- 


"Andreas Gehrs-Pahl" schrieb im Newsbeitrag 
news:19cy7bxnjd1zw.196yb4lxybgk2.dlg@40tude.net...

Carlos,

>I'm using windows 10 64bit.

In that case, please see PDR 6678, which states that the issue is caused by
the way Windows executes 32 Bit processes on 64 Bit CPUs. This PDR is marked
as closed on 06/29/2015 with Build 2.00.598, so the "fix" -- if there was
one -- should be in the current release of Xbase++, 2.00.623.

As the web-based PDR (text) search is not very accurate and misses a lot of
valid entries as well as showing a lot of irrelevant ones when you do a text
search, use the following URL to view it:

http://www.alaska-software.com/scripts/waa001.dll?WAA_PACKAGE=PUBLICDTS&WAA_FORM=DISPLAYPDR&PDRID=6678

Unfortunately, the Alaska Xbase++ Knowledge Base (or PDR system) doesn't say
anything about how a PDR was "fixed" when it is closed. So it could very
well be that this was closed as "This is Microsoft's fault and we can't do
anything about it" without any change or fix being applied to the Xbase++
product. So I suggest that you use the latest build and run the test on your
64-bit hardware (on Thread 1) to see if there is a difference.

Another possible solution is indicated by the fact that the PDR mentions
that the issue is only observable on Thread 1. So, you could try to run your
routine (with your current version of Xbase++) in another thread, and see if
that makes any difference.

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
web:   http://www.Aerospace-History.net

Hi,

RoundX() compared to Round() 1.9 fails in some documents like attached debug 
results.
I tried values from 1 to 15 to precision parameter.

I think the problem begin at line 9 rounded 5 decimals.
In 1.9 line VAT 23% excluded is 76.84000000000001. In 2.0 is 76.84.

In 1.9 document total 621.1249999999999 is rounded to 621.12.
In 2.0 document total 621.1249999999998 is rounded to 621.13.

Doing an individual document for each line, there are no diferences in final 
totals.

In customers with VAT 6% the problem happen more frequently in VAT value.

For faster execution, the round function used in 2.0 was your simplified 
below:

FUNC RoundX( nValue, nDecimals )
RETURN Round( Round( nValue, nDecimals+5 ), nDecimals )

The round problem can only be properly solved on Alaska Software releasing 
soon the original 1.9 function with another name. Then, with the saved 
version of the invoice, i will select the proper round function.

A refund because me and other colegues can not use Xbase++ 2.0 is a bad 
solution to all.

Now 2.0 Round(), have same results in windows 64/32bit.

Thanks,
Carlos.




"Andreas Gehrs-Pahl" escreveu na mensagem 
news:19cy7bxnjd1zw.196yb4lxybgk2.dlg@40tude.net...

Carlos,

>I'm using windows 10 64bit.

In that case, please see PDR 6678, which states that the issue is caused by
the way Windows executes 32 Bit processes on 64 Bit CPUs. This PDR is marked
as closed on 06/29/2015 with Build 2.00.598, so the "fix" -- if there was
one -- should be in the current release of Xbase++, 2.00.623.

As the web-based PDR (text) search is not very accurate and misses a lot of
valid entries as well as showing a lot of irrelevant ones when you do a text
search, use the following URL to view it:

http://www.alaska-software.com/scripts/waa001.dll?WAA_PACKAGE=PUBLICDTS&WAA_FORM=DISPLAYPDR&PDRID=6678

Unfortunately, the Alaska Xbase++ Knowledge Base (or PDR system) doesn't say
anything about how a PDR was "fixed" when it is closed. So it could very
well be that this was closed as "This is Microsoft's fault and we can't do
anything about it" without any change or fix being applied to the Xbase++
product. So I suggest that you use the latest build and run the test on your
64-bit hardware (on Thread 1) to see if there is a difference.

Another possible solution is indicated by the fact that the PDR mentions
that the issue is only observable on Thread 1. So, you could try to run your
routine (with your current version of Xbase++) in another thread, and see if
that makes any difference.

Hope that helps,

Andreas

Andreas Gehrs-Pahl
Absolute Software, LLC

phone: (989) 723-9927
email: Andreas.GP@Charter.net
web:   http://www.Aerospace-History.net