Hello,
That is really strange, but it looks like KNIME rounds numbers incorrectly
I've tried both math node and round double node,
In math node I use: round($column1$,2)
And in round double I use half-up and precision 2 decimal places.
Do you know why does this happen? At the moment I have to add 0.0000001 to every number to make the rounding work which is quite painful on big datasets.
Hi Joseph,
thank you for reporting this, yes it is a bug in the underlying API we are using. We fill fix this asap and I will let you know when there is any progress.
I don't see a better workaround, as adding a small number to your value before rounding. In the math node you could do this in the same node, as the rounding.
Hope this helps,
Iris
Or you could use any of Math, Java snippet, R or python node to write your own round function (e.g. for positive numbers: multiply by 100, then add 0.5, then truncate the integer, then divide by 100 again) or to use another round function if such exists.
Maybe that won't help with the workaround but just to give a bit of background on why this is happening. We are using a library to do the parsing and evaluation of the expression. The round function is using something called 'rint' and citing the documentation ([1] and [2]):
"If two double values that are mathematical integers are equally close, the result is the integer value that is even." and "This has better statistical properties." (I am not sure what properties that are, though.)
If you always round 'tied' values (that are equally close to possible rounded values) in the same direction, you introduce a bias in the data. That would be infinitesimal for data that was a continuous distribution of real numbers, but if your data consisted of randomly distributed values truncated to 1 decimal place (i.e. n.1, n.2, n.3 etc) and you rounded every n.5 up to n+1, you would effectively add 0.05 to the mean of the data set.
Rounding to the nearest even value avoids that bias.
Thanks for explanation Tom.
The problem is that in every application that I work with the rounding is done the biased way.
I think we'll all benefit if there is an option "Round (accounting)" and "Round (nearest even)". Hah, it'll even make people research the reasoning behind nearest even rounding, so win win :)
Careful with your choice of terminology: apparently rounding halves to even values is also known as 'banker's rounding' (https://en.wikipedia.org/wiki/Rounding#Round_half_to_even).
Presumably this is because rounding halves up would change the total of the data set as well as its mean, and bankers really don't like it if the total of a set of transactions changes (unless it changes in their favour).
If you call it banker's rounding, it's almost certain people won't use it. I like "commercial rounding", as in, lets make as much money as possible.