Hi,
The answer must be stupid but...
I've got a table with 5 lines. I want to select the last row. So I use the row filter and use the include row by number with the First row number = 5 and the Last row number = 5.Ok it works.
Now I want to do it dynamically to select only the last row whatever the table dimension. Well, I use the Extract Table dimension node followed by the Table Column to Variable and adjust the flow variables panel to RowRangeStart=Number Rows and Row RangeEnd=Number Rows having Number Rows coming from the Table Column To Variable=5. But the result is an empty table.
Changing the parameters to 5 with a variable and "to the end of the table" as option give me too a void table.
Ok I put now the first variable to control the RowRangeStart to 4 using the other limit to "to the end of the table". The result is the fifth line as I wanted.
Then if I use now two variables one at 4 the other at 5 to control the limit then I obtain the fifth line. If you do it manually you obtain two lines the fourth and the fifth.
Conclusion : if you want to have the last line entering yourself your parameters you have to enter 5-5 but if you want to control the limits by variables you have to declare 4-5.
Workflow in attachment.
Best regards
Fabien
Hi Fabien,
Interesting one! To confirm what's going on, I took your first Row Filter node and passed your manually-set first and last row numbers back out as flow variables. This outputs 4,4 rather than the user-entered 5,5 - demonstrating that the Row Filter node is quietly zero-indexing the user-entered values.
ROWINDEX values are actually zero-indexed - so this makes; but I think the issue here is that a user would legitimately expect flow variables passed into a node to behave in the same way as values entered in the user dialogue. However, it seems that flow variables get passed through without getting the same processing (-1) as the user-entered values. Dangerous!!!
I'll let the KNIME guys comment/explain(fix?)!
Kind regards
James
Dear KNIME Team, this issue also occurs in my workflows and it is very annoying. When will this bug be solved or, if not, why do you think it is a proper way to program a row filter?
Hey @agaunt,
from my point of view, this isn’t a bug but a process tasks.
=> Arrays are zero-indexed - that’s how IT works.
=> Human being are one-indexed - that’s a fact.
In a conclusion, the developer has to take care to decrease a value entered by a human being by one. It’s like translating text between two languages - you get an answer in ‘human’ and have to translate it into ‘computer’.
Kind regards,
Patrick.
I understand your point, but when I (as a human person) insert a flow variable into a row filter node, I do not know that the row filter handles this value differently than it handles the same value that I write directly into the row filter node.
1 Like
Following this further down the aisle, node-2-node communication is in ‘computer’ while entering a value is human-2-node communication and subject to translation…
At least it should be written clearly in the documentation and not unveiled by trial and error.
1 Like