Version: 2023.2.1.7 refuses to round

[TC00064]

Rounding issue with Version: 2023.2.1.7

Trying to round 3.d.p to 2.dp in the highlighted field

Ive tried every formula I could find on the forums including CEIL and ROUND to try and fix it.

Here is my current formula:

It makes no sense that .965 value gets rounded up to .96 using both CEIL and ROUND formulas. Got my colleagues to try this as well, same issue noted in 2025 version. 

[KGT · Accepted solution]

Wow, so looking into this showed how rounding half has many different interpretations. I would have expected it to be "Away from Zero" but I always called it, "round up" which is wrong. I expected to find that it was a floating point error, or something else to do with a coding language etc... and a lot of them have many posts regarding the topic... but it's not, it's intended.

Rounding away from zero, would yield -18.97 whereas rounding up would yield -18.96 as it's a negative number and so rounding up will go towards zero.

So, it's not a bug per se, as it's exactly how it's stated in the help on this topic which says the below. I'm not sure where this would be better stated though. This will be because of the flexibility in the rounding formula to state what you would like to round to, rather than stating decimal places.

Note

The rounding is done after dividing the number (x) by mult. If that result is negative (and is exactly an integer plus a half), the function rounds up instead of rounding away from zero. After it rounds to an integer, it multiplies again by the mult.

[TC00064 · Accepted solution]

This explanation makes a lot of sense.

Based on this understanding, here is how i changed my formula and it now works.

FORMULA: 

if [Amount]>0 then Round([Amount], 0.01)
else -Round(-[Amount], 0.01)
endif

Thanks for your help!

[Gaurav_Dhama_]

Alteryx uses the concept called banker's rounding when you assign Fixed Decimal data type. In this method you round to the nearest even, so 0.965 will round to 0.96 because nearest even is 0.96. Had it been 0.975 it would have rounded to 0.98.

Why you ask? This helps in preventing large rounding differences.

let's say you have two numbers

2.965 and 2.975, now sum of these two is 5.94.

Now let's make them fixed decimal 2 scale. you get numbers 2.96 and 2.98 and sum of these two will be 5.94. Which is exactly the same.

But if you round these values using the normal round method, you will get the values as expected because those formulas do not depend on this concept.

2.965 and 2.975 will round to 2.97 and 2.98 respectively, leading to sum of 5.95, which is 0.01 higher than original.

Hope that helps.

[KGT]

Note on that comment @Gaurav_Dhama_, that only applies when setting the decimal places using the FixedDecimal assignment (i.e. setting a field to FixedDecimal 19.2), not if you use Round() on a FixedDecimal.