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.
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?)!
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?
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’.
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.
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.