Bug in Rename-node?

Hi there,

we found a strange behaviour when using the "Rename"-node to convert integer-values to double. After the conversion the column spec of this column says something like "Non-Native [...]" instead of "Double Cell".

I've attached a little workflow (created with KNIME 2.4 / MacOS) which should help you to reproduce the problem. (We just detected it by chance because another node later on was not working correctly anymore).

(By the way, is this the right place to report such things?)



Now, with Knime 2.5, I still observe this behaviour. I just was wondering, whether you could reproduce the problem at all...

Hi Antje,

The behavior of the node is expected. The purpose of the Rename node is to mask types, not really to convert the data (there is one exception though ... for some types, if you convert them to Strings and they are not String compatible in the first place, they get changed to a StringCell). If you feed it with an integer column and then change the target to double it will only set the meta data in the table to double; it will not touch the data as an integer cell is always compatible to double. The meta data is then used to derive (a) the representative icon (the output column has a "D" although the content is still an integer), (b) the renderer (although the int and double renderer look the same you will notice that you have a different default in the drop down when you change the renderer in a table), and (c) the sorting (which, again, for double and int is not really a difference).

I admit this usage scenario looks weird a bit, in particular for double and int type columns. However, changing the default comparator or renderer may be useful if you have other 3rd party data types (you may still question whether the "Rename" node is the proper place for that type of functionality).

Hope that explains it a bit. What was the problem that you ran into?



I agree that I am unsure this changing of column mask should be in the rename node.

I ran in to similarly confusing situations of columns not being changed to the format I was expecting, and I know many others perplexed by this.

I think this functionality would be best in a node of its own, called "Column Mask Type" for instance. At least it gives a better idea of what it does.!

But on top of that it would be good to have a node also that really will change the column type and its contents too.


Thanks a lot for the explanation. Indeed - it sounds a bit weird. And I guess, it can be confusing to the user (at least our people tend to look at the little icon at the table view).

I guess, I got the point, though I cannot imagine when I would need to mask the data type. Not yet, probably.

So how can I convert my data from int to double? (I would use the Math-node node, it always returns double, but it's not very 'elegant')

Maybe it's not a big deal at all but I came to this point, when one of our nodes did not offer the column in the configuration dialog though it should offer 'int' and 'double'-column.

Now, I'm wondering whether we did any mistake in the implementation...

We added a dialog component like this:

addDialogComponent(new DialogComponentColumnFilter(createPropReadoutSelection(), 0, true, new NumericFilter()));

while NumericFilter is declared like this:

	public class NumericFilter implements ColumnFilter {
public boolean includeColumn(DataColumnSpec dataColumnSpec) {
    return dataColumnSpec.getType().equals(DoubleCell.TYPE) || dataColumnSpec.getType().equals(IntCell.TYPE);

public String allFilteredMsg() {
    return "No matching (numerical) attributes";


sorry, for some reason the formatting of the code did not work…

Hi Antje,

two hopefully short answers:

  1. There is a node "Double to Int" for type conversion.
  2. Don't check equality on {Double|Int}Cell.TYPE but _always_ check using dataColumnSpec.getType().isCompatibleTo(DoubleValue.class) - once that returns true you can safely type-cast any cell (except for missings!) to DoubleValue (or whatever the argument to "isCompatibleTo" was).


Hi Bernd,

thanks for the hint for checking the cell type. I'll change the implementation.

the other answer: I was asking for 'Int' to 'Double' ...