Marek14 wrote:[...]
However, it looks that our current state of CRF searching is really a mess. I think that the problem, ironically, is that we tend to be people with very good ability to visualize the higher dimensions. Almost any image is enough for us to see what we're talking about. But it's not systematic.
I agree.
I think that first thing we need is to have a database of models. The problem here is that each of us is using different tools, but the *.off files people sometimes post for me seem generic enough -- I was able to write several from scratch in text editor, though that method is really not feasible for complicated polychora.
When I first started writing my polytope viewer program, I was writing polytope definitions by hand -- it was extremely tedious and error-prone. I managed to write the 5-cell, 16-cell, and tesseract definitions by hand, but when I got to the 24-cell, the 96 edges + 96 polygons defeated me. There are just far too many surtopes to write by hand. That's when I started to realize that a convex hull algorithm is a must. It doesn't work for non-convex polytopes, but fortunately, for CRFs, it is exactly what we need.
So, I think we need models -- for every CRF polychoron we find (with exception of huge families like augmented duoprisms, though they probably COULD be handled by an automated program)
I already have a program for producing duoprisms of any size, both uniform and non-uniform (all polygons are regular, though).
we should have a file with complete data necessary so anyone could reconstruct it. If our discoveries (and this thread has seen some amazing discoveries) are to spread, we MUST do this. Not everyone is capable to understand the structure from a still image (even stereoscopic). I am very much helped by Stella in this regard since I can do things like setting model in slow 4D rotation and watching it change, examine the sections etc., but that program is not much help in actually constructing the polychora in first place
I think I could compile most of the nonuniform segmentochora from the list, though it would be probably nice to have a list of coordinates
IMO the Stella4D format is not perfect because it cannot store coordinates in algebraic form. I think storing coordinates in algebraic form is a must, because otherwise we cannot prove that anything is CRF except when it has only integer coordinates, because we don't know whether the edge lengths are exactly 1, or 1.00000001 but we didn't notice because roundoff error in computer floating-point arithmetic is usually ignored (it has to be, otherwise irrational numbers like the golden ratio will never measure up exactly). Having algebraic coordinates is the only way we can rigorously prove that something is CRF, and not just a near-enough CRF that the computer failed to notice the discrepancy.
This is one of the reasons I have been rewriting a new version of my polytope viewer, which is able to parse algebraic coordinates. It is still using only floating-point, but the important thing is that the source file of the polytope contains algebraic expressions that can be mathematically verified to have unit distances by a mathematician. Since listing coordinates can be very tedious, I've also incorporated Wendy's apacs, epacs, etc., operators, plus conveniences like ± that generates all sign permutations of its argument, etc.. Most of the CRFs that I've rendered have source files that give algebraic coordinates.
OTOH, just because we post the algebraic coordinates, doesn't mean people are going to be able to see what the polytope is, because that would require solving the n-dimensional convex hull problem in our head.
So I like Marek's idea of keeping a database of CRF models in Stella4D format -- the software is easily available and user-friendly (my polytope viewer is text-based, and not very user-friendly to point-n-click people
).
So here is my proposal: since this forum has an associated wiki, which already has a page listing CRF polychora that have been discovered (well, at least those that somebody has taken the time to add to that page), and since this wiki has the ability to upload files, why not use it? Every CRF we discover should be posted on the wiki, linked from the
CRF polychora discovery project page, along with a file containing its algebraic coordinates (or post the coordinates on the page itself), and another file containing the Stella4D .off file.
We should also talk about the canonical classification of CRFs, because that page right now, although it does have somewhat a similar organization to Johnson's list of 3D CRFs, still has a lot of overlaps between categories, and is not very navigable. Perhaps it is OK to have overlap between categories, since some CRFs can be understood in multiple ways, but there should be an official list of all known CRFs without repetition. There's also the official CRF count, which is hand-maintained right now and therefore not up-to-date. Ideally, there should be some way of automatically updating that count, based on which pages in the wiki are tagged with the 4D CRF category. (This is more tricky than it sounds, though, because we obviously don't want to have 1 page per CRF for the larger subsets like the duoprism augmentations or 600-cell diminishings, which would be too many; so for those cases we need to be able to specify a precomputed count for a particular subcategory of CRFs.)
In any case, please, people, go to the wiki's
CRF polychora discovery project page and update it. IIRC, if you have a forum account you should also have a wiki account, so you can just start editing pages. Hopefully, it will not just be Keiji and myself who update the wiki!