Here are some comments in sequential order on the wiki page at http://www.polymake.org/doku.php/tutorial/introduction:
Basic constructions: Actually, it is sort of a bad idea to use non-rational coordinates in these examples. polymake's key focus is to provide combinatorially exact output. This is what the class Polytope<Rational> provides. Using coordinates such as sqrt(5) is legal, but what happens is that the floating point representation of this number is converted into an exact rational representation, and then the computation continues with these exact rational coordinates. If the polytopes involved are simplicial, and the coordinates given are vertex coordinates, then one can barely see the difference, since the combinatorial types of the two polytopes (the one with exact irrational coordinates and the rational approximation) do not differ. In general, however, the rational approximation can be very different in terms of combinatorics. There is also Polytope<Float> but this is not very well developed.
It is good to have an example of this sort, but it needs an explanation.
Visualization of Polytopes: Which viewer is called depends on the local installation. JReality is shipped with version 2.9.9, so it is the default if no other viewer is installed. If JavaView is installed it will be the default, unless the user makes a change here, e.g., by saying
Code: Select all
prefer "jreality";The funny input notation POINTS=«”.” is standard Perl syntax.
The leading "1" coordinate means homogenization. This way polymake can deal with unbounded polyhedra in a very convenient way. I would have attached a pdf/svg/html file from our old documentation to explain this in more detail if I would have been allowed to upload an attachment of this kind. Maybe you want to include something like this here.
The ordering of the vertices and facets which is set by the user is kept throughout. The ordering of properties computed such as FACETS from POINTS or such may depend on the specific rule (here: the convex hull code). While it would be possible to choose a normal form, we refrained from doing so. We always saw it as an advantage that the users can fiddle with the ordering to organize their data according to their individual needs. polymake's rule mechanism is able to deal with the consequences resulting from permutations of vertex/facet data.
