I have run into a problem when I am using the "double to int" node. Whenever I have a double that contains more then 10 digits the double to int node will round them somehow. From my quick investigation it looks like that the double to int node will only work as I need it to if the double contains 10 digits or less. An example can be seen below:
Before double to int node After Double to int
Column 1 Column 1
What I would like is for this last row to look like this: 1234567891011
Is there any way to achieve this or this this just a limitation of knime?
This number is simply to big to be converted into an integer. In Java this number can reach 2147483647 maximum; all greater numbers need to be converted into a long, i.e. by using the Java Snippet node.
Thank you for the quick reply.
The reason I have asked this question is that my final goal is to export these numbers without comma's into a flat file for a user to be able to enter into an application. If I export a double data type the data is printed to the flat file in this format, 1.23457E+12. The way I have historically worked around this problem is by using the double to int node. Is there a way that I can convert a double data type to a string data type with out the formatting change as discussed earlier in my reply? Or is it just a case of needing to convert lengthy double data types into a long format before writing them to a flat file?
I see your point which is also shows a problem of the writer that does not support different numeric formats. The work around is to use the Java Snippet node and convert the double into a long (if you want to work with numbers downstream) or into a string using 'return Long.toString((long) $my_column$);' Hope it helps?
At least over here it is!
Yes this does help but I guess I think this is just harder then it was to be especially for users who dont know java in order to script solutions like this. I guess the best solution would be if the writer just printed what was shown (I understand the limitations behind this but speaking from an end users perspective this would be best). What made this more difficult as well was because it was a number format I couldnt even use the string manipulation node to strip out the comma's.
I appreciate the solution though and this is what I have used to solve the problem.
Maybe the double to int node could also handle long convertions?
Thanks for your valuable comment. Indeed the String Manipulator can be used as well with the proposed line of code which needs to wrapped into a additional string(...)-function call. I will open a feature request for this kind of convertion. Thanks again.
Just wondering if this feature has been incorporated in any of the nodes. Because I am facing the same issue while exporting double format column.