thanks again for all the replies, i think i ve got something to add but keep in mind that im a beginner
the issue doesnt seem to originate with the modulo function itself but rather with the floor rounding function which is part of the modulo functions / nodes obviously and thats why we are seeing the problem in modulo as well
I reported it anyway. Maybe someone will look into it.
few updates for any future visitors
(short version of a initially long post)
bug report
bug report made by ogonek - the bug has already been granted confirmed status
https://projects.blender.org/blender/blender/issues/131640
further testing
the problem manifests between divide and greater than / less than nodes
these nodes / functions are part of the floor node which is part of the modulo node and thats why we see the problem there as well
the nature of the bug mimics precision discrepancies but the problem is that it happens with an integer input, no decimals, so thats way beyond my knowledge
unfortunately this means that the chances of a 100% working workaround are slim
impact
the divide and the greater than / lesser than nodes are such essential nodes that effectively make the chances of anyone using the material preview to not have encountered this issue, zero (whether they realized it or not)
if it was just modulo it wouldnt be such a big problem but now with such basic nodes involved, the material preview in general cant be trusted really - at least not for people working with procedural geometric shapes shaders who need some minimum accuracy in basic math operations
i mean this is core stuff, i bumped on this in my first 15 minutes in the shader editor trying to make some 90 degree angles
so ll be looking for different software, waiting for an indefinite amount of time for a new version to fix this is not a realistic option
I find it interesting that the rounding error seems to be affecting different values for different users. Add your findings to the bug report please. Itās a peculiar bug that I wouldnāt have spotted. I thought you were crazy on first glance 
Yupā¦ Different GPUs and different drivers can do IEEE floating point calculations in a slightly different manner, and these math ops are particularly difficult to manage. 
I donāt know if this can be useful, but on my machine, testing the āmodulo.blendā file provided by fodd, if you scroll the value to reach, for example, ā3.000ā, the node gives a different output than if you click on the same numeric field to directly type the value. This I had noted some months ago in the modulo node, but I wasnāt sure it was a bug.
I made somel tests a day or two ago, that I didnt post.
First I tested the prebuilt modulo against a manual mod setup.
But that didnt lead to any differences in any case on my Nvidia card.
The second thing I did were a couple of isolated tests of subnodes like the one at the bottom of tthis next screenshot. And the increment in the value field isnt numerically stable or reliable. So if you use the increase buttons, the result isnt the same before and after editing the field, which is worse than just the rounding of the displayed value in nonedit mode. That will have its influence on the results we get.
It should e black in this case cause its not just stated as being 6.0 like this as nonedited display but also when you enter the field edit mode. ( The last value manually entered was 4 and then I clicked the right ui arrow ( add 0.1) until I reached 6)
But if you make the value editable and press directly return the result changes.
Hereās a test from my laptop (with an AMD chip)ā¦
Black stripes mean that the modulo output is wrong, and there are also differences between Orthographic and Perspectiveā¦
Thats a pretty tight precision limit for single floats, but yeah should be in range still. Happens quite often, maybe I give it a try later aswell.
And Iām using just 1 sampleā¦ there are more errors there. Thought at 10-5 should at least work as expected.
Yeah I see, well all is carried out in single float and there are quite some operations that sum up, so the expected error will get bigger than just the plain precision limit. and its even more prominent as we just test the āswapping pointā.
With single-precision floating point (according to IEEE), you should at least get a minimum accurancy up to 10-7ā¦ What Eevee is using (I suspect) is half-precision floating point (FP16) with no security net.
Yeah 6 to 7, and yeah maybe its using half, never looked into it.
Hi,
Please, we see the difference between Orthographic and Perspective, but what is the difference between the top and the bottom of the diagonal ?
I think it is because each triangle belongs to its own draw call, and that might also influence the vertices and its surface, in terms of floating point differences.
But iād need to look into Eeveeās source code to understand whatās really happening (thought Iām not familiar at all with that part of the source).
That happens with other things too (like translation-rotation etc), when you scroll Blender displays a rounded result but calculates the exact result. It is very difficult to scroll to an exact number scrolling to 3.000 normally gives a result of something like 3.0002 or 3.0004 but is displayed 3.000
Typing an exact number gives you that exact number.
If you want exact results type them in instead of scrolling the sliders.
You are right, btw this didnāt happen in older version of Blender; actually I discovered this behavior following a (not too much) old geo nodes tutorial about the modulo node where this didnāt happen also by scrolling the values. Donāt remember what Blender version was used in the tut, though.
Moreover, I noticed, by zooming in significantly, that the black lines (errors) are extremely fine (relative to the precision of the calculation) and it is therefore very difficult to be sure that this is not identical in the two projections, because there is also the precision of the display of the ācloudā of lines.
