#20669: LatticePoset: add function to get all sublattices
-------------------------------------+-------------------------------------
Reporter: jmantysalo | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-7.3
Component: combinatorics | Resolution:
Keywords: latticeposet | Merged in:
Authors: Jori Mäntysalo | Reviewers: Travis Scrimshaw
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/jmantysalo/all_sublattices | 1bb87bd775eece24a586b9ccedb7dfd6ca0b5488
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by tscrim):
Replying to [comment:4 jmantysalo]:
> Replying to [comment:3 tscrim]:
> > I think you should use a backtracking algorithm instead of a
recursion. It will be faster (and you don't have to constantly get things
like `self.cardinality()`), never run up against the Python maximum
recursion limit, and have better input (which `set()` and `0` should be
defaults anyways).
>
> Maximun recursion limit is 999 by default, and that is too small only if
we have a `ChainPoset(n)` with `n > 999`; recursion stack will have at
most as many steps as the lattice has elements. And it will have `2^999`
sublattices anyway, so this is not valid argument.
People could want to do some partial tests on some really big example of a
lattice or wanted to run a month-long-type computation on a big lattice
(of which, there are a number of examples of finite exceptional cases that
I come across in my research where the easiest way to prove things can be
to do long computations).
> For example after `B4 = Posets.BooleanLattice(4)` it takes 0,02 seconds
to count 732 sublattices with
`len(list(B4._hasse_diagram.sublattices_iterator(set(), 0)))`, whereas it
took 1,13 seconds with `len(B4.sublattices())`. So if one wants to
optimize lattices, then bottleneck is usually not in `hasse_diagram.py`
but in `lattices.py`.
I don't disagree with this, but you should not be creating the lattice by
using the `LatticePoset` but directly creating the necessary data and
passing it to `FiniteLatticePoset`. This avoids the extra overhead and
checks that is in the `Poset` code.
> Of course I can change this to use backtracking, but... Then why not
move this to static sparce graphs class, if we really want as fast code as
possible?
I have no inherent objects to this, but does the static sparse digraph
code have the capacity to do the meet and joins?
--
Ticket URL: <http://trac.sagemath.org/ticket/20669#comment:5>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" 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 https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
