> Some of my other project ideas are more substantial. Checking the moon calendar here:
https://www.timeanddate.com/moon/usa/kansas-city Tomorrow, the Ice Moon rises full in Gemini. After another half cycle it goes dark, and the snake loses its legs, so to speak. In the meantime, here's another golang "count to 2025" calculation: https://go.dev/play/p/QkfBMn6lJi- https://www.youtube.com/watch?v=kZIybvTZ4kI If you run locally, it can produce 20K trees per second on a laptop. That's about the same rate as the article from the 80's, which I found after writing the decrement function (see hyperlinks in header). This is a first attempt, so if anyone wants to point out flaws, feel free to. Having an efficient successor (or predecessor) function is really a separate issue than getting an efficient, never-breaks canonicalizer. The canonicalizer is what matters more, imo. Before doing this calculation I had never really thought about minimal representations of trees. I guess it can just be a list whose length is dimensionalized about equal to vertex count. This is slightly different than the situation with graphs where a matrix is necessary, and might need optimize for sparsity. One of my tiling projects has a lot of interesting search tree data needing to be re-generated, canonicalized and published, so that's where I'm investigating growth options. All the best, --Brad -- 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. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/32e82237-7dd3-461c-ad75-121b590d735en%40googlegroups.com.
