TOPIC:

Good morning forum. There are maths operation incompatibility between XSharp and FoxPro
I am using 2.6a because 2.7 is incompatible for bugs. Rolling back to 2.6 was Robert choice until new advice...

When in VFP assign a variable with default numeric type like:
a= 1 or a= 1.0
b= 2 or b= 2.0
? a/b output 0,5

But in XSharp the divide operator produce differents results
With variables with Usual default datatype is the same.
a:= 1
b:= 2
? a/b output 0
but
? 1.0/2.0 output 0.5

Another example with functions
? RecNo()/RecCount() in XSharp return without decimals, in FoxPro return the correct value

When the matematical calculate is a bit complex, it lost precision only when there are divisions.

Thanks
Juan

Hi Juan,

For the sample using a and b, I do not see this behavior here, I instead get 0.5 as expected. Can you please show a full sample showing this behavior? Maybe you have strongly typed the vars as INT?

Regarding the RecNo()/RecCount() sample, this happens indeed, because RecCount() is strongly typed to return an integer (not float or usual). But still you can force divisions also with integers to return floats, by enabling the option "Clipper compatible integer divisions" in the Project Properties/Dialect page.

Btw, what do you mean about 2.7 being incompatible?

Hi Chris,

i created from the XIDE-Gallery a "Foxpro Dialect" Application. Looking at the default compiler setting shows that only /memvar and /undeclared are checked. I think it would make sence to check some more options like /lb, /ins, /VO2, /VO12 etc. So the VFP Guys have a more compatible default environment.

regards
Karl-Heinz

Hi Karl-Heinz,

Agreed, will do that now, thanks for the suggestion!

Chris,

Chris wrote: Hi Juan,
Btw, what do you mean about 2.7 being incompatible?

Juan had a problem with the new feature where we added support for accessing array elements with parentheses. I advised him to switch back to 2.6 for that.

Robert

Hi All,

Here is a similar issue I have encountered. The following function takes an initial radius plus a 999 radius offsets that describe a closed shape in 1000 steps around a circle. The data comes in as hexadecimal strings. The code extracts values from the hex and the offsets, which are quite small, can be positive or negative, and stored in a single byte. It returns an array of polar coordinates for plotting the shape.

FUNCTION Ser2ArrayU(cInitVal AS STRING, cTrace AS STRING) AS ARRAY PASCAL
LOCAL nAngle,nInc AS FLOAT
LOCAL nRadius,nOffset AS FLOAT
LOCAL nCntr AS DWORD
LOCAL aNidek AS ARRAY

aNidek := {}

nRadius := Convert.ToSingle(Convert.ToInt32(cInitVal, 16)) / 100.0
nAngle := 0.00
nInc := 360 / 1000
AAdd(aNidek,{nRadius,360.00})
FOR nCntr := 1 UPTO cTrace:Length - 1 STEP 2
nOffset := Convert.ToDouble(Convert.ToInt32(SubStr(cTrace, nCntr, 2), 16))
IF nOffset > 127
// A negative offset
nOffset -= 256.0
ENDIF
nAngle += nInc
IF nAngle > 360
nAngle -= 360.0
ENDIF
nRadius += nOffSet / 100.0
AAdd(aNidek,{nRadius,nAngle})
NEXT
RETURN aNidek

That line nInc := 360 / 1000 cause a problem because, it did an integer division, and rounded down to zero. Stepping the angle by that amount later in the code did not get very far!

The fix was easy, just change that line to nInc : = 360.0 / 1000, and get the value 0.36.

The X# code originally came from VO, so it looks like VO would have done a floating point division for the original line, but X# does what you would get in C#, an integer division. I hunted down and fixed other examples of this in my code base with a regular expression, but if the normal behavior of VO was to do a floating point division, perhaps X# should do that too?

I have no VO experience at all, just inherited lots of code and Xported to X#.

I am very impressed with the X# system and hope my feedback may help improve it.

Best Regards,
John

John,
- Open the project properties
- Goto the dialect page
- Check the option "Clipper compatible Integer divisions"
This should fix it.

Robert

Thanks again Robert,
I have fixed lots of them manually but selecting this option should cover the ones I missed.
John