Hello everybody, while testing some data i stumbled across the strange situation that after some numbers were multiplied by 1.000 they were often 1 to small. after i ran this process: [image] totaldataloss/Public – Multiply1000 contains 3 items like the first occurence where this happens is: [Bild1] I included into the outputfile the original data (column “Volume”) its the column next to 32.299 and shows the original value of 32.3. (You can jump there by searching for the unixtimestamp of that line:1328216204). The transformation in this process consisted of: Import from a textfile into a variable with Datatype double In a math expression node multiply with 1000 and save as integer: toInt(column(“Volume”)*1000) So obviously the result should be 32.3K and not 32.299. This error happend in the 500K lines of the input file 236 time so approx every 2000 lines. I had some time ago that i had some discrepancies after the 15 digit after the comma. But this is a discrepancy on the first digit after the comma. What is the reason for this? Greetings to all of you! Edit PS : is there a way to upload the workflow with pointing to the input file in a more “embeded way”? Right now if one wants to use it he has to change the path from my local path…

Hi @TotalDataLoss , actually quite interessting case :slight_smile: As far as I can see this is not a KNIME problem but a general problem of binary representation for floating-point numbers. So if you would do the exact casting in java/c++/… you will most likely get the same result E.g. for your example case the 32.3 is actually stored as the Most accurate representation = 3.22999999999999971578290569596 as it cannot store the exact 32.3 in the available bits. So 3.2299 * 1000 = 32299 e.g. better visualized: [image] Online Binary-Decimal Converter Or similar problems most likely better explained: [xyz] Double multiplied by 100 and then cast to long is giving wrong value java, floating-point, numbers asked by xyz on 06:41AM - 20 Nov 12 UTC “To be precise, it’s not decimal at all, it’s binary. A number like 17.3125 has an exact binary representation because it is 17 + 5/16, but 17.31 has no exact binary representation. You can’t express it as a finite sum of powers of two” from Mike Dunlavey in the linked thread. ->But thanks for giving me a heads up - this can really screw something up if you do not expect it… And sorry for not providing a helpful solution - but I hope I at least could provide an explanation for this problem :slight_smile: For your second question - you can use relative paths for most of the reader/writer nodes. E.g. in your case: knime://knime.mountpoint/Multiply1000/Output.csv Which you can directly copy from Knime: [grafik] Then you can use them like this (sometimes you have to change to file-path option in the node as well): [grafik] which would write the file to your Multiply1000-Workflow group - which if exported will work for anyone who imports the group :+1:

32.3*1000 equals 32.299 in Knime?

KNIME Analytics Platform

ipazin August 13, 2020, 9:50am 3

Hello!

Explicit rounding should help in this case if not mistaken. Same discussed here:

Br,
Ivan

2 Likes