a bit of context: KNIME development started when 64 bit processors were not common yet. Therefore KNIME supports 32bit integers and 64bit long integers. Today with 64bit processors being commonplace this distinction is not needed anymore from a technical point of view, at the same time it introduces additional barriers and confusion. As a result we started working towards using 64bit (long) integers everywhere.
The Expression nodes always uses 64 bit (long) integers. The naming of data types indeed is confusing. Unfortunately, we picked this up too late for the last release. With the upcoming 5.5 release we start to clean this up, however, there will be more work to be done.
If you have trouble using the long integers in downstream nodes, please, let us know. We are aware that there are a number of nodes that do not support these today. Your feedback can help us prioritize (also which nodes to convert to modern dialogs).
Thanks for the feedback and welcome to the KNIME forum,
nan
Thank you for the detailed explanation and the thorough reply, including the historical context of KNIME.
The reason for my question was that my downstream nodes are designed to receive the data as a LONG type. I was concerned that an error might occur if the return value of the truncate function were to be changed to INTEGER to match the documentation.
I am relieved to know that the current behavior of the Expression node returning a LONG type is the correct operation. Currently, my workflow is running without any issues, as the downstream nodes handle the LONG type correctly.
I understand that the confusion around the data type naming will be addressed in version 5.5 and later. I am looking forward to the upcoming updates.
I will be sure to provide feedback if I notice any other issues. Thank you again for your help.
