extract pointCoordinates to python for analysis

dear all,

while trying to extract and compare x and y coordinates of sets of points (points of distinct curves, to see which ones differ only in the z direction) inside a python component with the least string-methods and/or gh-nodes possible, i am just hitting a series of walls.

as it may be seen in the attachment i chose python, and chose it because it seemed more consistent with my way of thinking regarding lists.

in theory the solution looked as easy as appending tuples of the z coordinates to an empty list IF pt[0] and pt_[0] (xCoordinates) along with pt[1] and pt_[1] (yCoordinates) are equal in two (or more) sets of points.

the obvious turned out quickly: python does not know if a string is a coordinate, neither if a bunch of characters belong together, and while iterating, a loop just explodes the strings to characters and new lines.

i must miss at least two things, possibly on both grasshopper and python side, since it s only my first year in this wonder of programming geometries and anything so thank you in advance.

Attachments:

gh_pointCoordsToPython.jpg, 689 KB

Replies to This Discussion

Permalink Reply by Giulio Piacentino on October 11, 2017 at 10:53am

Hi Lukacs,

If you pass stuff through panels or "text" params, it will be converted to text. That means, it will no longer be made of "neat" objects/numbers, but rather a piece of text.

This is generally the issue I see happening in your script. But, probably, there is something else you are also after. Please have a look at the GhPython getting started document here: http://developer.rhino3d.com/guides/rhinopython/your-first-python-s..., or read the GhPython documentation by right-clicking on the component's "Help...".

Giulio
--
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

Permalink Reply by LukacsPeter on October 13, 2017 at 4:50am

hi Giulio,

thank you very much for the quick and useful read !

i followed the lead and got to the exciting concept of intersection() and enumerate() (bless the good souls, smartness and diligence at grasshopper3d and stackoverflow), and yet, hit the next wall:

in the attached jpg there are [a pythonscriptGHnode with inputs from a deconstructPoint component, the script used in the pythonGHcomponent, the script used in jupyterNotebook, panels with the lists to compare and panels displaying the indices hunted for] shown.

it is clear that the script in GH did not find all the results while the very same script in the jupyterNotebook did find all the matches.

am i still missing an important bit from understanding how the python component works or is it another thing beyond my understanding ?

with kindest regards:

Peter

Attachments:

gh_pointCoordsToPython_02.jpg, 1004 KB

Permalink Reply by Giulio Piacentino on October 13, 2017 at 12:28pm

If you type numbers, as text, they will be exactly as you ... well, type them.

In Grasshopper, however, all numbers are rounded for display. That means that, say, 0.00000000000000000000001 will be shown as 0. However, it obviously it is not 0, nor it is the same as 0. This is an inherited feature of limited-precision floating point arithmetic.

I am sure what you are seeing is this: something very close to a number NOT being the same as the number.

Luckily there are a few ways around this. First, you could round the numbers yourself. Or, you could compare them with some tolerance. Welcome to the world of computer numbers! :)

Permalink Reply by LukacsPeter on October 18, 2017 at 3:04am

Thank you for your insight ! i ve read about binary to decimal a couple of months ago, but until seen in action this phenomenon was so spooky it slipped my mind. thanks again, hope to finish this short script soon and finally make my first and bitsy contribution to this fantastic world of programming geometries.

Permalink Reply by Nader Belal on August 13, 2018 at 12:04pm