On Mon, 8 Jun 2015, Nicolas M. Thiery wrote:
So far we have been aiming at the following rule of thumb, for posets
and elsewhere:
- Where parent/elements/categories are relevant, abstract code that
does not depend on the data structure shall go in sage.categories.
What this means for, say, is_selfdual() or directed_subsets() on posets?
Those functions are now on categories.
I can understand the point on coding, somehow. Whenever we have a poset
class implementing is_meet_semilattice() and is_join_semilattice() we can
have is_lattice() on higher level: it is just those two combined with
and-predicate. But then, we don't need "concrete" is_meet_semilattice() if
we have dual() and is_join_semilattice().
* * *
These questions might be too hard for me. And anyways, I'm more interested
to make a unified and clear interface for the user, including good
documentation.
1 second vs. 1 minute computation time makes little difference compared to
1 hour vs. 2 hours time for the user to understand how to use the
system...
--
Jori Mäntysalo
