Trunc sometimes returns Value-1

Trunc sometimes returns Value-1

  

I was stuck on this problem with Trunc function. Sometimes it returns Value-1: for example Trunc(110) returns 109! I've spent quite a lot of time to figure out in which cases this happens, but could not find any clue. I also tried to reproduce it in a simple application, but also without luck. This just happens sometimes. The place where I was using it was having Currency input and Output, I have changed to Decimal and thought this helped because didn't see it happening for some time, but then it happened again. It was even giving different result for the same value - one call was from inside BL, and the other - from test, which was building the same input. I thought the problem could be in some "hidden" low decimal digits, and the value shown to me rounded, but in the test this can't be - it just summarizes several constant (from static entity, entered manually) values and passes that sum. There I also tried to change all types from Currency to Decimal - but this didn't help.

I can't give espace example, because this is in a big and complicated application, and also as I mentioned it's hard to reproduce - it just happens sometimes. What I can give are these screenshots from debug when I caught the problem (attached).

I did the function another way, without Trunc, and now it works OK.

Platform server 9.1.


Now I got invalid return from Round as well! The value was 4.5, and after Round() it became 4 (instead of 5)! I even have unit tests which cover this one function and there are different cases including *.5, expecting it rounded up - and they work. I have many other tests involving this functionality as part of bigger scenrious, I'm sure *.5 values appear often there, and those tests all succeed, except just one, where 4.5 became 4! I just can't believe I'm seeing it. Well I made a workround for this case also, but I'm thinking probably all the clean math calculations should better be done via C# extensions - those I can trust.

Hi Igor,

I did a test on my PE and could not reproduce your behaviour.

I created a new variable (currency and decimal) and did:

var1 = 125

var1 = var1*2

var1=trunc(var1)


The final result was 250.

What's your platform version? My PE is running Version 10.0.200.2.

João Heleno , as I wrote, this issue is very hard to reproduce, so you shouldn't even try. :) it happens sometimes, but it does happen, I could not determine waht affects it, even when I used the same values in separate test application - couldn't catch it. There must be some combination of factors that lead to it, but I can't get what they are, and don't want to spend any more time, hopefully the workarounds I did are enough. We have many tests involving this functionality as part of more complicated logic, and seeing them fail - this is how I catch it. In real application flow it would've been simply impossible to find.

Even if there is my mistake somewhere before the call - I can't explain why the value already composed and sent inside to the function produces wrong result, unless there is difference in how Outsystems shows values and what they contain in reality.

Hi,


Regarding the Round you should check the documentation. 4.5 is correctly rounding to 4

"round half to even (rounds to the nearest integer, 0.5 rounds to the nearest even integer)"


For the Trunc, there is an issue listed in the fixes done for 9.1.604.0 that looks tlike what you are saying:

"Fixed issue causing precision lost when using the Trunc Built In function (#1378817) "

What is your platform revision?


Regards,
João Rosado

Thanks for explaining about rounding João Rosado , I guess I was already too tired and started panic without checking more details. And about platform server - we have earlier, 9.1.401.0. Not sure if this is about the same issue, what's that "precision lost" supposed to mean? We are talking about Trunc, a function that cuts away any "precision" and in my case it seems to find some "precision" where there is none. ;) But well, maybe it's just explained not clearly, and I will probably never find this out because now I did the logic without Trunc and will be very careful using it in the future.

Due to the way Trunc was implemented it caused a type conversion internally ...and due to some wierd .Net precision stuff it caused numbers that were already integers to change a little bit.

So a number like 110 could either become something like 110.000000000001 or 109.999999999999.

I reported this as a bug YEARS ago and was told it was fixed.

This is really not acceptable, because it means that anyone using Trunc in financial stuff (like making an invoice, calculating tax, etc.) will randomly have minor errors.

Guess how I found this? INVOICES THAT DIDN'T ADD UP!

Can we get this fixed? It is not unreasonable for this to work. People don't need an explanation, they need math functions that work as expected.

J.Ja