Hi @TotalDataLoss,
actually quite interessting case 
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:
Or similar problems most likely better explained:
“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
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:
Then you can use them like this (sometimes you have to change to file-path option in the node as well):
which would write the file to your Multiply1000-Workflow group - which if exported will work for anyone who imports the group 