Jori Mäntysalo writes:
>
>>> At least for now we don't have parameter like
>>> 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)
The check would mostly be used in Sage source code for making conversion
and construction cheaper when the check is known to pass.
>
>> ??? 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.
> But let's suppose that a
> function f returns a poset with at least elements 1 and 2. We want to
> print "foo" if the poset is not a lattice and join of 1 and 2 if it is.
>
> P = f(x)
> if P.is_lattice():
> L = LatticePoset(L)
> print L.join(1, 2)
> else:
> print "foo"
>
> First Sage tries to compute meet- and join-matrix to see if P is a
> lattice. If it is, then they are computed again when making L from P. And
> then third time - now only join-matrix - when printing join of 1 and 2.
>
> Advanced user migth say try: L = LatticePoset(P) and catch ValueError. So
> maybe for is_lattice() it is good to throw away just computed matrices.
> But when creating a lattice it feels unnecessary. Why to make a lattice if
> not for computing meets and joins? And in any case advanced user can say -
> after reading the code - something like unset(L._meet) or so.
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.
In rethinking how linear codes should be represented in Sage, we had the
issue of when certain properties for codes were computed, including
really basic ones that are very often used (e.g. generator matrix). We
opted for making initialisation of codes as cheap as possible, i.e. no
unnecessary construction or computation. This way the user can create
thousands of codes in a loop, as long as the methods he is calling on
these codes do not compute the "expensive stuff".
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.
But since I'm not an expert in posets and lattices, perhaps this is
overengineering it?
Johan
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
