Hi @nan, picking up on the suggestion of using integer instead of double for monetary values, and then performing division at the end… I agree that this is certainly a valid and common approach in many systems, and I’ve certainly thought about that before.
Unfortunately it is not a suitable option in KNIME because of the lack of support for the Long datatype in the Math Formula (and many other) nodes, which we would need to use here, unless we only deal with values up to (+/-) 21.4 million ($21,474,836.47). This is the total value for a 32bit Integer field. If Long were properly supported across the calculation nodes, this would be become a viable option. (@mwiegand and I have had discussions on the range limitations of Integer elsewhere on the forum)
I know this might seem like it only affects “power users”, but put bluntly, who would expect (and accept) that Math Formula (the node that really should be capable of simple arithmetic) is incapable of returning the following as an integer value:
(it returns “missing value” unless you untick the “Convert to Int”)
I accept your point that it is difficult to move forward with such changes whilst ensuring backward compatibility, but improved support for Long here could be done iteratively. Math Formula really should support it, and I don’t see why that would require a massive reworking of other nodes, except of course that the future is now likely to be the Expressions node rather than an enhancement of Math Formula.
So, I remain hopeful that in the new Expressions node era, full support for Long will be included, and it would be great to see consideration for BigDecimal too.
Conceivably, for those nodes that don’t have existing support for Long data types, or new datatypes such as BigDecimal, the immediate solution would be for them to ignore any data types that they cannot use, just as Math Formula does, (and String Manipulation (Multi Column) doesn’t do(!) but should 
)