function pow behaves differently in expression node compared to math formula node

[daniela_digles]

While trying to calculate pIC50 values I found a difference in behaviour from the Math Formula to the Expression node. I found a solution, but thought I share it here in case someone else runs into the same issue.

In the Math Formula node, I used to calculate pIC50 (the negative logarithm of molar IC50 values) with the following formula (starting from IC50 values in nanomolar range):

-log($Standard Value$*pow(10,-9)) where standard value is the column with my nanomolar IC50 values, which need to be multiplied with 10^-9 to convert to molar values. For a value of 64.5 this results in 7.19, which is the expected behaviour.

Using the corresponding formula in the Expression node - log10($["Standard Value"] * pow(10,-9)) however returns -infinity, due to a rounding issue I believe. Only by scrolling down in the description of the pow function, one can see the solution to this changed behaviour in the examples:

• pow(2, 3) returns 8

• pow(2.0, 3) returns 8.0

So pow(10,-9) returns 0, leading to the infinity result of the full formula. The solution is to use pow(10.0,-9) or (as suggested by K-AI): use 1e-9 for clarity and proper syntax.

For the developers: Not sure if this is a bug or probably expected behaviour. But I think returning 0 (integer?) while calculating a number to the power of a negative number is not intuitive, and it would be great if this would be treated as a float number instead.

(used KNIME version: 5.5.0, Windows)

[MartinDDDD]

Thanks Daniela for flagging - moved it to Feedback & Ideas for the developers to pick it up!

[bwilhelm]

Hi @daniela_digles,

You are completely right — thanks for sharing your findings here!

What you observed is an oversight in the design of the Expression language. When we originally designed it, we decided that exponentiation of two integers should yield an integer. However, as you noticed, this makes no sense for negative exponents, since the result will almost always be fractional. In your case, pow(10, -9) (or 10**-9) evaluated as an integer, which ends up as 0 and causes the -infinity result you saw.

Changing this behavior now is tricky: existing workflows may already rely on the current semantics. To fix it properly, we’d need to introduce a new version of the Expression language so that such changes don’t break compatibility. That’s something we might do once we’ve collected enough requested improvements that justify a new version.

To keep track of this design bug, I’ve created an internal ticket: AP-24944.

Thanks again for reporting this so clearly — it helps us improve the Expression node!

Best,
Benjamin