Hi there,
it's not a bug... it's a feature
There is nothing really wrong with your output. The Matrix you get is a SparseMatrix to save memory. Since all but one row have exactly two non zero entries. So for higher dimensional simplices it does not make sense to store all the 0 entries:
Code: Select all
polytope > print simplex(5)->VERTICES;
(6) (0 1)
(6) (0 1) (1 1)
(6) (0 1) (2 1)
(6) (0 1) (3 1)
(6) (0 1) (4 1)
(6) (0 1) (5 1)
The output (6) (0 1) (3 1) is read: this row has 6 entries In the entry with index 0 is a 1. And in entry with index 3 is a 1. This notation is cheaper than storing: 1 0 0 1 0 0.
But the SparseMatrix implementation is "clever" in the sense that it knows when the sparse notation makes sense, and when it does not.
In your example the first row (3) (0 1) is the same as 1 0 0. It accually does not even make a difference for the memory in this case.
but for the second row: 1 1 0 is cheaper than: (3) (0 1) (1 1). Therefore the last two rows "look" like in a normal matrix.
If you do not want to parse the SparseMatrix notation you may use:
Code: Select all
polytope > print dense(simplex(5)->VERTICES);
1 0 0 0 0 0
1 1 0 0 0 0
1 0 1 0 0 0
1 0 0 1 0 0
1 0 0 0 1 0
1 0 0 0 0 1