Hi guys, I am working on some mesh scripts and in evaluations of the vertices I wanted to coerce a point to check against, and then discovered that the vertex is vastly simplified compared to the coerced 3d point of that same vertex, why is that??? It seems very wrong that the mesh returns a lesser version of the vertex than a coerced version of the same point.

(The mesh is just a 100x100 mesh generated from a height field image, close to origin, nothing done to it, so it is as pure as can be)

Could be that the data type for the x, y, z components of a Point3d simply allows for a greater precision (more decimal places) than the data type of mesh vertex components?
Or itâ€™s just the output rounding to 5 decimal places in the first case and printing all available decimal places in the second case?
Either way, I wouldnâ€™t worry about this too much, since you probably wonâ€™t need that much precision.
If you for instance need to compare points in your script, simply do so with a tolerance, which by the way is always a good idea in Rhino.

Thanks, but that doesnâ€™t make sense to me since the 3D point IS from the vertex, so it should not be able to add inn more detailâ€¦ If it was just a bunch of 00000 filling up the space, then OK, but it isnâ€™t. And thatâ€™s what bothers me. I want the raw data and expected the vertex to show itâ€™s actual position. After all I am coercing that exact vertex, so what I coerce should be what the vertex IS and when I ask for that vertex I should get the same result as if I coerce it. (We work in Meters, so 5 digits are OK since that gives me 1/100 mm accuracy, I donâ€™t need more than that, BUT if I run a " is coercedPt0 == vertises[0]" then I donâ€™t expect a False with out me having to run round(coercedPt0,5) for the statement to be True.

OK, but what I donâ€™t understand is how coercing that point can add more data?
My understanding must be missing something hereâ€¦ Maybe how floating points work.

Does it make sense to you that the vertex returns x.xxxxx , y.yyyyy , z.zzzzz and that this once coerced into a 3d point is not x.xxxxx00000 , y.yyyyy00000 , z.zzzzz00000 ?

As mentioned multiple times on this forum donâ€™t assume bit-for-bit parity when working with floating point numbers (single or duouble precision).

Further, Python does its own things to numbers when printing, so donâ€™t rely on that either.

What may make sense to you as a normal human being does no longer hold in the realm of floating point computation and even just floating point representation in computer memory.

You can use the EpsilonEquals() utility functions provided by Rhino.RhinoMath:

Ouch, you are right, that hurts my normal way of thinking and calculating numbersâ€¦ donâ€™t know if I want to tumble down that rabbit holeâ€¦

But I still donâ€™t understand why coercing the vertex doesnâ€™t return the same number as just pringing the vertex valueâ€¦ why are they handled differently? Why is the vertex rounded when presented to me?

I recorded RH-58628 to keep track of this problem.

Right now, users can use the mesh.Vertices.GetPoint3dAt() function to look at the double precision vertex of the mesh. This is however a little less easy to find than the indexer [], which returns the single precision.

OK so I guess that with my new â€śknowledgeâ€ť it refines to a wish:
I wish that the coerced 3D point of the single precision indexed point results in the same value as the printed value of that given point.
(Is that accurately stated? I feel I know nothing nowâ€¦ )

Printing single precision, as you can see, has less accuracy than double precision.
We canâ€™t have the indexer return doubles now, because it would break existing plug-ins. And we are trying very hard to keep new versions of RhinoCommon compatible with older plug-ins.

We could deprecate the indexer, and print a warning that points to this or a similar discussion. It could also suggest the GetPoint3dAt method. Would that be enough?

Maybe that is what happens to the binary value.
And then the same (binary) number is simply formatted as decimal using different precisions â€¦
â€¦ I guess since one is a 32 bit value and the other a 64 bit value.

After 20 years of math,geometry programming I ended up to think geometry like what happens in the real world, a point a line and a surface do not exist. They are balls, cylinders and skins with a epsilon radius/thickness. This helps to make robust coding (at least I hope)
Gd