Hi guys, I don’t understand why this happens:
in the first method the values of the X axis are not compared well, while in the second method it works well.
ps changing the value of the slider, the result of the first method always changes from time to time. . . . 
this is interesting, could you please post your grasshopper file with internalized geometries?
Occam’s razor says this first surface should not be planar, but you wouldn’t have opened this thread if it wasn’t 
so really curious to understand what’s going on there
Hi Inno, thanks for answer
I don’t have the Gh file,
both surfaces are identical since it is the same copied definition
excellent hypothesis, but I can tell you with certainty that it “should” not happen since the surface is extracted from a cube made directly in Gh and not in Rh, so in theory there shouldn’t even be minimal coordinate shifts.
ps it would also be advisable to try to repeat the same definition in other versions, it could be due to some bad setting. are some basic components that are easy to connect.
the only difference between the two definitions is that on the upper one first you DivideSurface then move the resulting division points, while on the second you move the whole surface by the very same amount first, then DivideSurface
I’m on Rhino 7.10.21243.17001 dated 2021-08-31, and it looks like it’s working properly
can’t say from your image what expression is embedded in the sliders, but it’s clear their output is 50
I think only the original GH file might tell us more 
i valori dello slider sono min 0 - max 10 mentre l’espressione è: x*10 quindi in uscita si ha: 0 10 20 30 to 100
Inno, grazie per la condivisione. da ciò che vedo funziona bene usando PlaneSrf
a questo punto l’unica causa potrebbe derivare dal cubo creato con “Box 2Pt” - A=0 - B={100,100,100}
oppure altra ipotesi dipendere dalla versione con la quale è stata realizzata la definizone che è datata.
ps cosa importante che mi sono dimenticato di dire, nella foto che ho postato,
se nell’input A del componente Equality lo collego con “Integer” la definizione funziona
in quel caso dovrebbe trattarsi di una questione di arrotondamento
the values of the slider are min 0 - max 10 while the expression is: x * 10 therefore in output we have: 0 10 20 30 to 100
Inno, thanks for sharing. from what i see it works fine using PlaneSrf
at this point the only cause could derive from the cube created with “Box 2Pt” - A = 0 - B = {100,100,100}
or another hypothesis depends on the version with which the dated definition was made.
ps important thing that I forgot to mention, in the photo I posted,
if in the input A of the Equality component I connect it with “Integer” the definition works
in that case it should be a question of rounding
Interestingly, using one of the following surfaces as the origin,
the problem also arises when using your definition INNO
ps with the Sfilter surface 1 in both definitions the result is 0
(but perhaps in the latest versions this does not happen)
I was able to reproduce the error using your “Filter=0” definition:
it looks like something related to rounding about which I have red in some dedicated topics I can’t find at the moment
it’s like if some of those X values (4 in particular) have some “invisible decimals” that -of course- will not make them pass the “equal” test
this is to make them appear:
in general you won’t get integers out of GH unless you force them to be int (or if you are dealing with indices)
you can use something like this to see “float” written wherever you haven’t forced it to be something else
like here: they are all floats despite being represented without point+decimal
the question to ask at this point would be: both the correct method in my first photo of the post and using PlaneSrf as displayed in your first definition, why in these cases the problem does not arise?
