xsharp.eu

Hello Robert and Chris,

I have been debugging the Loan Module, on PMT Annuity calculation and this one is a bugger:
If above code, period is FLOAT, it will give -12 which exactly the VO code result.

I do the same on C#, it is the same with VO.

The work around is turn period to FLOAT.


Thanks,

Rene

Above code resulted in mine: 244

Hi Rene,

Please have a read on this article: https://www.xsharp.eu/articles/blog/vo- ... metic-in-x

In short, we did put a lot of thought and effort in trying to reproduce VO's behavior in this area, but in the end we had to give up. VO's behavior is just so extremely inconsistent that it is impossible to replicate it reliably (and does not make sense anyway in a lot of cases), so this is an area where you will unfortunately have to manually check your calculations that they do the same results as they did in VO and adjust them if they don't.

I realize that in this particular case X# has different behavior also to c#, this is the result of our attempts to make the X# behavior closer to VO at least in some cases (when using the VO dialect, in Core dialect you get the same behavior as in c#). But making it more compatible in one case makes it incompatible in another. Similarly, if we adjust the case you pointed out, something else will be "broken" next. So I am afraid we'd better just let it be as it is now, in order to at least avoid breaking other existing code.

Chris,
semi OT: wanted to try R.'s sample in an "empty project" in Xide. Complained about not knowing "Float" in core. Consulted the help, and found, adding compiler option "-dialect: VO" should work.
Doing so, i get error XS2006: Command-line syntax error: Missing '<text>' for '/dialect:' option.
Apart from the discrepancy between "-" and "/", what do i wrong?

Hi Rene,
please let me add something for this particular case: it is absolutely useless using the byte datatype in such calculations as you will rather have a performance penalty on 32 bit systems - the best is always to use "full" datatypes, in this case dword or int, because otherwise the compiler has to fill up the variable to the full bitness, and remove the unused part after.
This is true also for VO.
Wolfgang

Karl, you have a space between ":" and "VO"

that helps, thx.
But i feel excused as the help has:
-dialect: Core | VO | Vulcan | Harbour | XbasePP | FoxPro
:whistle:

Karl,
The first 2 lines of that topic are:
[hr]
The -dialect compiler option selects the dialect that the compiler should follow. Valid options are: Core, VO, Vulcan, dBase, FoxPro, xBase++ and Harbour.
Note: There should be NO space between the colon and the dialect.
[hr]

Robert

Hi All,

So, I was right all along: This got to be another case of VO weird behavior that X# Team were trying to "align" as much as possible with VO. For me, it was "impossible" bug to passed the QA unless there is a "shotgun" pointed into one's head. Figuratively, that was what happened.

I resolve it but putting the "number of period" to FLOAT before the calculation. I did not change the the Function's arguments data type because, it will trigger another round of test.

Like my web guys who keep telling me: "Just use the TEXT datatype, rather than Varchar". And I tell him: It is part of the validation.

Yes, it was part of the validation. If the number exceeded BYTE, then something wrong with the data. Likewise, a shotgun in my head.

--

Rene

Touché
Nevertheless, i' can't find any option which contains a blank, so, i'd expect the commandlineparser to digest this - or to produce a better eror...