When are two vertices considered equal? If by X, Y, Z, then what is the precision of if?
How often does Vertex position change? How often are new Triangles created? Anyways: 1. if you can use unsafe: https://play.golang.org/p/6cMS6aMCz7 2. if you cannot use unsafe and can add 1 field to vertex: https://play.golang.org/p/gVCU795Abw 2.1. you can store the ID and create one as needed in external map[*Vertex]int, with the obvious drawbacks 3. or use index into the vertex array as ID: https://play.golang.org/p/gtkKbmOyvw On Monday, 28 August 2017 14:13:34 UTC+3, Val wrote: > > Hello, > I have some geometry data modelling with > type Triangle [3]*Vertex > > (The exact definition of Vertex is unimportant here, but I'd like to avoid > adding more fields inside Vertex if possible.) > > Then I'd like to use a triplet of vertices as the entry point of a map > containing more data like color, texture, etc.: > var mesh map[Triangle]Data > > When I traverse a big list of Vertices (following edges) to construct the > list of all Triangles and their Data, it's important that I don't recreate > Data for triangles that have already been visited, even if triplet is in a > different order: > A B C > A C B > B A C > B C A > C A B > C B A > ... are all the same triangle in my specific modelling. > > To achieve this, I consider normalizing the triplet so that all keys of > the map verify > A *<* B *<* C > for some arbitrary definition of *<* . This ensures that I can detect > any Triangle already present as key in the map, regardless the order of its > Vertex pointers. > > Unfortunately for this approach, direct pointer arithmetic doesn't exist > in go: I can test individual Vertex pointers for equality with ==, but not > for ordering with < or sort.Slice or sort.Sort. > I could "print a numerical string representation" of each Vertex and use > the strings as keys, but this looks costly and I'm not sure about this way > being reliable. > I could try package unsafe to convert pointers to uintptr, but this looks > unsafe and may impair portability. > > My problem arises from the fact that a Vertex doesn't hold its own ID, > it's a value object whose identity is solely determined by its memory > location (its pointer), which is usually fine except for this normalization > step! > Note that I can't rely on the values of X, Y, Z coordinates for Vertex > identity, because several Vertices may be at the same geographical > position. Inspecting the values stored in each Vertex is irrelevant. > > Any creative idea ? > This may be a starting point: https://play.golang.org/p/qvldUtH68C > > Thanks in advance :) > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
