On Sat, 13 Jun 2015, Johan S. R. Nielsen wrote:
trust_me_i_know_what_i_am_doing=True for posets or lattices.
Such a parameter would make lots of sense, I think.
I have thinked about it. It needs some more thinking - how much should be
trusted? But at least for lattices it could just override the check of
DiGraph being a lattice. Posets are maybe harder part.
Trust fully. If the user willingly disables checks AND passes illegal
stuff, then it's the user's own fault. You see this in e.g. constructing
fields (where the irreducibility of the optional modulus can be
disabled)
But see http://trac.sagemath.org/ticket/14110 . There the C code of McKay
and Brinkmann gives posets and we can trust them to be acyclig graphs -
but some linear extension must be computed, because it is not readily
available from C code.
??? Why is is_lattice not overwritten by FiniteLatticePoset?
I don't know if that would be used feature...
Perhaps we're misunderstanding each other. I mean, in the class
FiniteLatticePoset, I would add:
def is_lattice(self):
return True
Since any finite lattice poset is a lattice.
I understood. But when do user have an object of class lattice and he or
she wants to check that it is a lattice?
Some of the unnecessary re-computation might be alleviated by using
@cached_method on strategic methods, such as join_matrix() and
meet_matrix(). You should strive for a design that is easy, comfortable
and efficient to use, for experts and novices alike. Don't rely on
strange things like unsetting private variables in order to get decent
performance.
Yes, but should it be cached when creating a lattice or when first used?
(Of course the whole question arises because check for a poset to be a
lattice is done by computing meet- and join-matrix. I don't know if there
is some easier way for it.)
In posets and lattices there seems to be similar issues with
e.g. initialisation of the hasse diagram. For many special poset
constructions, e.g. chain posets it's not actually necessary to
construct the Hasse diagram most of the time. Rather for most methods,
like meet and join, you could override the implementation (if chain
posets had their own class), and provide more efficient implementations
that did not use the Hasse diagram.
Then there should be implementation for AntichainPoset, BooleanLattice
etc. I guess that properties for those are already known, so they are not
used in "real life" other than testing algorithm, showing something to
students etc.
* * *
Do Sage has "normal users"? Is somebody making goat cheese, and using Sage
to compute how many goats are needed for a given amount of cheese?
--
Jori Mäntysalo
