Hi all,
A what sounded simple task became once more more complicated than I thought:
I want to identify the positions of duplicate points (not remove them!).
Prune duplicates deletes those additional points, but that’s not what I need.
No packages for this allowed (needs to work for Dynamo in Alias, therefore package existance cannot be guaranteed).
Any ideas without using Python?
List of dup points.dyn (7.3 KB)
This might help work things forward: Points inaccuracy in Dynamo - #6 by jacob.small
Instead of focusing on “no packages” focus on ‘sandbox compatible packages’ as those will work in any host/environment.
This seems to work on the list you provided.. I don’t think it would work if there are more than 2 duplicate points though..
List of dup points2.dyn (19.6 KB)
Thanks for the link, that was quite an impressive post you made there, absolutely worth reading! 
Interesting to see your DesignScript solution, but I guess it would still need Python for the looping once you get beyond just one list of entries, which I don’t seem to need due to the post from willyoung.
On the packages side, I am not scared that they wouldn’t work for Alias, the problem would be that I cannot expect the Automotive user to have that package, respectively expect the user to be able to easily install a package my script depends on.
Thanks for your post here, always great to hear from you! 
That is an absolutely awesome way of solving the problem!
I couldn’t bend my mind enough to come up with that solution of basically removing all remaining points of the pruned result from the original list!
Thanks a lot!
Yeah @willyoungMF8K3’s solution is really good, but note that geometry comparison (the index of node) can return incorrectly, which is why the distance to node was utilized in the other thread. Simple use cases should be fine with this as is though.
Not sure I understand why that would happen? I am deleting a point from a list, and then checking for the index of the remaining points in the original list. Why would Dynamo fail to recognize the point (which should be the same) on the original list? I understand that Dynamo (respectively computers) can have accuracy issues, but how can that happen here, where a point hasn’t been touched at all? I would belive that two representations of the same point in Dynamo should be the same, or am I wrong here?
The issue stems from floating point math.
Basically computers don’t do math using the clean XYZ values in your list as they only have base two (on or off - binary math) so the points are not the same from an equality check (index of) unless they stem from the same constructor (when you built the point).
This isn’t a Dynamo thing but a computers thing. Try the excel sample I brought up in the other thread.
Third time I am rewriting this before posting. 
I don’t think the accuracy problem of systems (which I understand) should apply here:
Nor do I; however it can as each node can produce a new instance of the objects in memory as things move to/from the scratch disc the values from a pure equality perspective can vary (finding index 1 instead of 2), or even fail entirely (null result).
If the point class had an equality check then List.IndexOf would work reliably 100% of the time (a non-trivial task due to the inconsistency in ASM versions across Dynamo, which Alias in particular is likely to see); but until then the statement Point.ByCoordinates(x,y,z) == Point.ByCoordinates(x,y,z); wont be as reliable as a distance comparison which is therefore my recommended method.
Lacing and list levels can also be made to work on an multi-level list via definition or by specifying list levels while maintaining the list level.
Thanks, Jacob, I marked my code accordingly, including a link to this topic, so I have an idea for a rewrite if the problem should occur.
