Precision of Math Node? To normalize the position coordinates of particles for an Image Texture node, I have to divide 1 by a very large number (119,617). After running some tests, I see that the colors of my image texture are off by a factor of about 1e-4 (0.0001). 

This has me wondering: how many decimal places does the Math node retain in its output? 

I've noticed that some fields (e.g., the values for a Divide operation) accept up to three decimal places (and that everything beyond that third decimal place is simply rounded up or down). Is the same true for the output of the Math node? If so, is there anyway to change the output precision so that I get at least 6 decimal places in my output? 

Many thanks if you know the answer and care to share it!

EDIT: Jaroslav pointed out that color is shown in the Data-Blocks view of the Outliner panel with six decimal places. However, when I look at the same view of my outliner, I see only three decimal places. Compare my screenshot (below) to that posted by Jaroslav. This is under Blendfile Data > Images > StarCol > Pixels. 



Is there a reason for this difference? Am I looking in the wrong place in the Data-Blocks view? Can I trust that under the hood the full RGBA color values are being used (at least to six decimal places)? I would post this in a separate question, but as I'm only asking for clarification, it seemed best to do it here. Thanks again!

EDIT 2: The Python output for the pixel color values, on the other hand, has far more decimal places than just six! I assume that the values shown in the Outliner panel and in the fields of the Math node are shown with three decimal places for conciseness only? It would be disappointing to have the full precision stored in the Blender file and not using it!
For values Blender uses IEEE single precision floats. This gives a precision of about 7 decimal digits. The displayed value is rounded to 3 decimal places and the displayed value when editing the field to 6 decimal places (probably because the precision limitations).

The RMB value viewer in image editor of render output is rounded to 5 decimal places, but render values will render in full 32bit. Stored and rounded in format you choose.

It is also unlikely you are experiencing limitations in floating point representation:

$1/119617 = 0.000008360015716829547 $

When rendering this and storing with 32bit .EXR you get:



A sampled value of 0.00001 in Image Editor (5 decimal rounding), a value of 0.000008 in Data-Blocks outliner view (6 decimal rounding):



And value of 0.000008360016181541141 that is saved in the file by inspecting it through the console:



That's an error of 0.00000000000046471159

All of these cannot explain the 0.0001 error you are seeing. The problem is somewhere else than in precision of Blender math or your math is more complicated than what it seems and your floating point limitations snow-balled into the 0.0001 error.