One more jit.gl.pix question: unusual results from %?
I hope that I'm not being a nuisance or asking unnecessarily basic questions, but as I've continued troubleshooting ports from jit.gen to jit.gl.pix, I've noticed the following anomaly.
(cell.x + (cell.y * dim.x)) % 2
in jit.gen and the equivalent
((cell.x - 0.5) + ((cell.y - 0.5) * dim.x)) % 2
in jit.gl.pix often produce different outputs for the same input matrix, depending on the dimensions of that matrix.
The output of jit.gen is a series of alternating cells of 0 and 1 as expected, but some cells in the output of jit.gl.pix which should be 0 (i.e. multiples of 2) unexpectedly and seemingly impossibly have a value of 2.
If I take the jit.gl.pix cell index
cell.x - 0.5 + ((cell.y - 0.5) * dim.x)
modulo some other integer n and vary the dimensions of the input matrix, I can always find several states in which the index modulo n returns n instead of zero. Doing the calculation directly with the problem values rather than variables always returns the correct result, and the cell index itself is always calculated correctly.
I suppose that I could try to hack around this, but I'd very much prefer to understand whether it's a known issue, a bug, something I should understand better about jit.gl.pix, etc.
The included patch demonstrates this for a simple case (index of a 3 x 3 matrix % 2).
…aaaaand of course the answer was staring me in the face. I missed an important detail regarding floating-point precision and equality tests that's missing from the PDF Gen documentation online but present in the Jitter Gen "Technical notes" section of the in-application documentation.
In case anyone happens across this thread while having similar issues in the future, I've included a modified patch with the fix implemented in the jit.gl.pix patcher. I'm still curious to know why jit.gl.pix has internal precision issues different from those of the other Jitter Gen objects, but for now, I'll be happy to have figured out how to work around it.