On Mon, Nov 05, 2012 at 04:06:52PM -0800, Travis Scrimshaw wrote:
> This is what was already done for Partitions_n when computing cardinality
> (you had the option of selecting Bober's, GAP's, and PARI's algorithm for
> the computation). I can change the doctest and put a big warning block in
> the cardinality() method. Perhaps a better solution would be to rename it
> cardinality_from_algorithm() (maybe a private method?) and set cardinality
> = cardinality_from_algorithm in the class?
Ok, in that use case, the extra parameters (algorithm) are not
changing the semantic of the output. Since we have already computed
the list of the elements of ``self``, getting its cardinality from
that list is for free; thus calling cardinality_from_list is at least
as good as any other implementation.
Now what you are saying is that cardinality_from_list is not a drop-in
replacement for a cardinality method taking an "algorithm" optional
arguments, because cardinality_from_list will bark at those optional
argument instead of just ignoring it. That's a good point!
What about:
- Writing in stone in the Set's category that, for `X` a set, the
semantic of X.cardinality(...) is to always return the number of
element of `X` regardless of the arguments. Otherwise said, the only
valid arguments would be things like "algorithm =...".
- Having cardinality_from_list ignore all its argument.
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--
You received this message because you are subscribed to the Google Groups
"sage-combinat-devel" group.
To post to this group, send email to sage-combinat-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
