#16553: Clean IncidenceStructure
-------------------------------------+-------------------------------------
Reporter: vdelecroix | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-6.3
Component: combinatorial | Resolution:
designs | Merged in:
Keywords: | Reviewers:
Authors: Nathann Cohen, | Work issues:
Vincent Delecroix | Commit:
Report Upstream: N/A | dffcc4a8118a8bc5d9dfa6c1ab1aabe7aaaaa25a
Branch: public/16553v2 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by ncohen):
Yo !
> - one possibility: we can avoid sorting the ground set and consider
[0,1,2], and [2,0,1] as different sets. For blocks, we convert everything
to tuple of integers and it is fine for them to do the comparison. What do
you think?
NOnonono, saying that the order of the vertices matters for equality
really isn't what one would expect ! But it isn't so bad to make equality
test slower, is it ? I mean, does anybody use it for anything ? I wonder
why such methods are even defined...
Just to play it safe, we can rewrite this to relabel+convert to set the
blocks of self and other before comparing them. It is slow but it is
correct, and we can change the data structure later if it becomes a
problem. Or use graphs as a data structure, as they do that already
`:-PPP`
I don't mind not having an equality test, but if there is one I want to be
sure that it works as expected. Because otherwise I cannot complain
constantly about #14019, and that's important to me `:-P`
> You are right, it is the way it was before. So I will put it back. And
just for fun, here is the verbatim old implementation:
> {{{
> def block_sizes(self):
> self._block_sizes = map(len, self.blocks())
> return self._block_sizes
> }}}
GNIiiiiiiiiiiiiiiiiiii `>_<`
> All right: I can put it back, but assume that the user feed the object
with sorted tuples of tuples. It is not that complicated. Is that ok for
you? I would like it to not waste my time with the constructor.
What we can do is something like "set 'copy=False' if you do not want the
constructor to make a copy of your data, but know that it will be
modified. Use this flag only if you will not use your data anymore
afterwards, or if you know what you are doing".
> - right now the structure are immutable but it would makes sense to have
mutable ones (that can be turn into immutable ones). For example,
removing/adding blocks that contain a given point is a useful operation...
Ahahahaah. Yeah.... Like a bipartite graph ? `:-P`
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/16553#comment:119>
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 http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
