Hi Travis!
On Fri, Nov 02, 2012 at 07:45:35PM -0700, Travis Scrimshaw wrote:
> +1 on Partitions(order=...)
> -1 on Partitions().options(order=...)
>
> I'm currently planning on changing it to the first way.
Thanks!
> > - Deprecating the following methods and classes:
> > * evaluation()
>
> It was from MuPAD-combinat and the name doesn't make sense to me. I don't
> feel strongly about this, so if you (or anyone else) want to keep it
> there, I have no objections.
Here is the rationale: The *commutative evaluation*, often shortened
to *evaluation* of a word is its image in the free commutative
monoid. In other words one counts how many occurrences there are of
each letter. By extension this definition extends to any word-like
object (partitions, ...). And that's exactly what `to_exp` is doing.
(and it turns out that for a partition this contains all the information).
Granted: there should be an abstract class for word-like objects (or
more possibly generally objects with labels), and this method should
be implemented there. But in the mean time just leave it there.
> So then make OrderedPartitions similar to how Partitions is (as a factory
> class)?
Precisely. But this can wait as it currently is until we indeed have
more than one class to justify the existence of a factory.
> > - Changed *_lengths into *_length_tableau() (ex. arm_lengths()
> becomes
> > arm_length_tableau() ) and deprecated old names
>
> What is the rational?
>
> The output is a tableau (whose entries are the *_lengths) and I believe it
> is more clear. Again I have no strong opinions.
We have that general rule of thumb that one should name the
mathematical meaning of the output rather than its data structure.
>From my point of view, the output is the lengths of the arms of all
the cells; the fact that we use a tableau as data structure to store
that information is essentially an implementation detail.
Opinions anyone else?
> > - Made Partitions_n inherit from Partitions
>
> This breaks the "is_a" rule: the set of all partitions of 3 is not an
> instance of the class Partitions; the (by the way unique) instance of
> the latter indeed models the set of all partitions. Hmm, I would have
> expected UniqueRepresentation to bark about this.
>
> When I said inherit, I meant I made Partitions_n a subclass of Partitions.
That's also how I interpreted inherit. My point is precisely that
making Partitions_n a subclass of Partitions breaks the "is_a" rule.
> If you run sage -t partition.py with the current version of the
> patch, you'll see this occur (in particular, it doesn't know how
> to handle the additional arguments).
Ok, I'll try to pull, but there is no guarantee that this will get through.
> I'll write a small example illustrating this and open a new trac
> ticket.
Thanks!
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.
