Hi. Normalization may not work in some degenerated cases. How about to check equality of triangles, smth like this: https://play.golang.org/p/W9Gc00HD7E
On Mon, Aug 28, 2017 at 2:13 PM Val <delepl...@gmail.com> 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. > -- 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.
