# Same operation, different results

Hi, I’m not sure if this should be in the bugs section, or if I am missing something when doing my operations, so feel free to move this post if it doesn’t belong in this section.

In my learning process, I am trying to achieve the same result in different ways.

In my example, I want to obtain the same two channels (r and g) from ramps; the first way starts with a ramp TOP, and the second, from a ramp in a pattern SOP.

Although I go through the exact same transformation process in both ways, I end up with slightly different results (as you can see in the example file).

As I am trying to replicate a fibonacci pattern, these differences make a big difference in the final results. Am I missing something?

Thank you!

TopChopQuestion.toe (4.6 KB)

Hi, You may have found a bug. When the Ramp TOP is other than 8-bit output format, and the ramp goes from 0 to 1, then the first value is not exactly zero, it’s a small amount. I’ll check with the programmers.

You can see this when you set the TOP Viewer to be Normalized Split.

I think that may be the only difference between your two approaches. I can’t think of a workaround - the CHOP method seems to be working right.

From my understanding, the issue lies with the fact that the UV-Chrodinates in GLSL are centered in the pixel. As the UV is normalized. So the U/V of the first pixel is of course not at 0/0 but offsetted by
`(1/res)/2`
Funny enough, there are also some rounding errors I suppose:

You can see the behaviour here exactly from a 1x1 ramp.

So, yeah, this is not a bug but by design and I’m affraid there is no direct way arround this except creating your own Ramp from a CHOP instead.

Thank you both for you answers! At least I wasn’t missing anything. I found a workaround for the SOP approach, in order to get a perfect fibonacci pattern : In the starting ramp pattern, I change the range from 0 to 1, to 0.0001 to 0.9999.