Beginner question again. Please see attached hiplc.

My main question is about the small deviation in the calculation of y-positions in the half circle, and the preferred way to deal with this.

Short hints welcome!

Interesting question, My guess would be floating point imprecision.

It's likely down to the way this circle node point locations are actually created I would imagine using sin, cos
to plot each location......so the divisions in the underlying code would be mathematically calculated as steps around a circle
rather than a fixed start and end point.

As you are probably aware as accurate as computers are they are not quite perfect, is anything?, it can be impossible to calculate infinite accuracy, eventually the precision will run out of steam unless the app was specifically designed to deal with ridiculously high precision, which is where the mathematical variable "epsilon" is used for error bounds with very precise calculations that breach the accuracy boundary that an 32,64,1024 bit values can deal with.

Hopefully this comes close (no pun intended :P) too an answer why we get the tiny, tiny difference between -8.742277657347586e-8 and 0.0 when using this way of creating an arc using the circle node.

-8.742277657347586e-8 as a real number is -0.00000008742277657347586.


To get the values as you expected if necessary use a fixed start and end point for an arc.

To achieve this use the curve node set to bezier and while drawing the curve use "a" to create an arc
so you can have the exact start and end point.

if you were a mathematician that enjoys finding "discrepancy's"......or an accountant.....you could probably find
one of the points between the start and end locations along the arc might not be quite accurate to 8238764850856308508768653408 decimal places but the computer and the apps are doing the best they can.


Hope this helps!

EZiniT
Hope this helps!

Yes! I was aware of the limitations of computer mathematics, that's why I tried radians too ...
Thanks for the Bezier tip!

The other question I had in mind is, if there is some Huodini idiomatic way to deal with this

I haven't come across a function that sets the amount of decimal places or UI option that tells Houdini to be less
accurate but this can be done using vex or an expression.

For point locations or any value that you want to round to something a little less precise than:

-8.742277657347586e-8..... -0.00000008742277657347586.

Multiply the value by 10000 for example then use the "rint" function in vex or the "round" expression to round the
value to the nearest integer then adjust the decimal places back again by multiplying by 0.0001

EZiniT
…

Multiply the value by 10000 for example then use the "rint" function in vex or the "round" expression to round the
value to the nearest integer then adjust the decimal places back again by multiplying by 0.0001

vector r_Val = @P * 10000;

r_Val = rint(r_Val);

@P = r_Val*0.0001;

That's clever!

**Generally** you can ignore small numerical variations like this - apart from things like numeric based selection where you do have to be careful. All other 3D software will have this sort of discrepancy - but simply won't show you : )
An alternative selection approach for your second extrude might have been using the 'group' SOP with the 'by normals' (0,-1,0) spread angle < 90, or 'Include by edge angle' options.

The correct way to compare floats is by using a defined acceptable threshold. You should expect a direct comparison to fail.

You would do


Obviously, in this case, subtracting by 0 makes less sense, so you can omit the subtraction here, but for everything else, that's the formula you want.

Mike_A
An alternative selection approach for your second extrude might have been using the 'group' SOP with the 'by normals' (0,-1,0) spread angle < 90, or 'Include by edge angle' options.

Thanks - I will try this and commit to memory!