Re: [sage-combinat-devel] Partition options and cleanup patch
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.
Re: [sage-combinat-devel] Partition options and cleanup patch
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. Note that the terminology is not uniform. Among others * evaluation * Parikh vector * Abelianization * number of occurences of letters * ... see [1] It would be nice that we have a convention for that. Should we put all of .evaluation(), .parikh_vector() and .abelianization() in the namespace of a word-like object ? Which one should be the prefered one ? [1] http://wiki.sagemath.org/LanguagesAndTilings#Parikh_vector.2C_evaluation.2C_abelianization Best, Vincent -- 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.
Re: [sage-combinat-devel] Partition options and cleanup patch
On Mon, Nov 05, 2012 at 03:15:35PM +0100, Vincent Delecroix wrote: 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. Note that the terminology is not uniform. Among others * evaluation * Parikh vector * Abelianization * number of occurences of letters * ... see [1] It would be nice that we have a convention for that. Should we put all of .evaluation(), .parikh_vector() and .abelianization() in the namespace of a word-like object ? Which one should be the prefered one ? Thanks for the pointer. Hmm, let's see. Here are my appreciations of pros and cons: - Parikh vector: sounds too specific to a community; people outside the community won't find it. We want to have variants that don't return the result as a vector. - Evaluation: probably specific to a community (algebraic combinatorics if not Marne-la-vallée). The name does not convey the main information (that we are going to the *commutative* world). It has been around for a long time in MuPAD-Combinat - Abelianization: contains the main information - number of occurences of letters: very explicit but long So altogether I hesitate between evaluation and abelianization, with a preference for the second one but mitigated by the advantage of minimal change :-) 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.
Re: [sage-combinat-devel] Re: Global options for elements set by their parents
On Wed, Oct 31, 2012 at 05:39:06PM -0700, Andrew Mathas wrote: I think that the problem is that when sage creates a class then it creates copies in memory of all of the (inherited) methods of the class. Not exactly. What happens is that, for P a parent (here P=Tableaux), the class P.element_class is not P.Element (here Tableau) but a subclass of it, constructed to let a tableau inherit code from categories: sage: T = Tableaux() sage: T.Element class 'sage.combinat.tableau.Tableau' sage: T.element_class class 'sage.combinat.tableau.Tableaux_all_with_category.element_class' sage: T.element_class.__bases__ (class 'sage.combinat.tableau.Tableau', class 'sage.categories.sets_cat.Sets.element_class') As a consequence: sage: issubclass(SemistandardTableaux().element_class, Tableaux().element_class) False even though: sage: issubclass(SemistandardTableaux().Element, Tableaux().Element) True So what you want to do is not to insert your method in the class of the tableau, but in its superclass (i.e. Tableau): sage: t = Tableau([[2]]) sage: s = SemistandardTableau([[2]]) sage: t.__class__.__base__.foo = lambda self: 1 sage: t.foo() 1 sage: s.foo() 1 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.
Re: [sage-combinat-devel] Global options for elements set by their parents
On Sun, Oct 28, 2012 at 06:50:19PM -0700, Travis Scrimshaw wrote: On Sunday, October 28, 2012 2:13:07 AM UTC-7, Andrew Mathas wrote: Not OK (this could break e.g. Symmetric Functions): sage: Partitions().options(cmp=dominance) In his patch Travis has an option for changing the default comparison method and I think that this would be useful. Yes, but only by creating a new parent: sage: Partitions(cmp=dominance) Not by changing an existing one: sage: Partitions().options(cmp=dominance) I believe we should allow individually created parents to set their options only via Partitions(3, order=...), that way we don't have to worry about changing something by surprise if something is a UniqueRepresentation. However by implementing this, we could then not break things by not necessarily having to call particular methods directly. So in SymmetricFunctions, if we need lex order, we call P = Partitions(3, order='lex') and then iterate over P. (Hopefully that makes sense...) +1 - Element classes may be shared between different parents. One needs to make sure that one does not affect by accident unrelated parents. Don't elements always have unique parents? Yes. But two elements with distinct parents may share the same class: sage: U = WeylGroup([A,2]) sage: V = WeylGroup([A,3]) sage: U.element_class is V.element_class True sage: U.element_class.foo = lambda self: 1 sage: V.an_element().foo() sage: U.element_class.foo = lambda self: 1 sage: V.an_element().foo() 1 So changing an option for the elements of one Weyl group will affect all other Weyl groups. I have no experience with cython yet but I wouldn't have thought this was a big problem because all that I am really doing to using optionable methods as aliases for the real methods. The idea is that a method like _repr_ simply becomes an alias for _repr_with_option and that changing an option for _repr_ just changes which function it is an alias for. Couldn't we just do that with function pointers? http://docs.cython.org/src/reference/language_basics.html Probably so. But then I guess you would need to predeclare in the Cython class each and every method that you might want to assign at some point. And this will use as many memory slots (besides, such changes requires to recompile all files that use that class, so we don't want to have such patches lying in the queue for long). 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.
Re: [sage-combinat-devel] sage-combinat repo is still down
On Mon, Nov 5, 2012 at 7:18 AM, Christian Stump christian.st...@gmail.comwrote: Hi all, any idea what the problem with the sage-combinat repository is, or when it will be alive again? It looks like the machine is firewall'ing itself, yet again, for no apparent reason, or ssh got killed: wstein@sage:~$ ping combinat PING combinat (128.208.160.193) 56(84) bytes of data. 64 bytes from combinat (128.208.160.193): icmp_seq=1 ttl=64 time=0.194 ms 64 bytes from combinat (128.208.160.193): icmp_seq=2 ttl=64 time=0.356 ms ... wstein@sage:~$ ssh combinat ssh_exchange_identification: Connection closed by remote host I will hook a console up to it today, within the next few hours, and see what happened. I uninstalled the firewall, fail2ban, and ubuntu automatic upgrades, so I'm surprised by this. -- William Thanks, Christian -- 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. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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.
Re: [sage-combinat-devel] Re: Global options for elements set by their parents
On Wed, Oct 31, 2012 at 12:12:14AM -0700, Andrew Mathas wrote: As a follow-up, since Nicolas suggested that what I was proposing looked more like options for arbitrary sage objects, so I experimented with adding my options method to SageObject. Cool Even though SageObject is implemented in cython, from the few quick checks that I made, my generic options code seemed to well for arbitrary sage objects. Have you tried for Cython (aka extension type) subclasses of SageObject, like e.g. Integer? sage: x = 1 sage: x.__class__ type 'sage.rings.integer.Integer' sage: x.__class__.foo = lambda self: 1 Traceback (most recent call last): ... TypeError: can't set attributes of built-in/extension type 'sage.rings.integer.Integer' 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.
Re: [sage-combinat-devel] Partition options and cleanup patch
On 11/5/12 6:50 AM, Nicolas M. Thiery wrote: On Mon, Nov 05, 2012 at 03:15:35PM +0100, Vincent Delecroix wrote: 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. Note that the terminology is not uniform. Among others * evaluation * Parikh vector * Abelianization * number of occurences of letters * ... see [1] It would be nice that we have a convention for that. Should we put all of .evaluation(), .parikh_vector() and .abelianization() in the namespace of a word-like object ? Which one should be the prefered one ? Thanks for the pointer. Hmm, let's see. Here are my appreciations of pros and cons: - Parikh vector: sounds too specific to a community; people outside the community won't find it. We want to have variants that don't return the result as a vector. - Evaluation: probably specific to a community (algebraic combinatorics if not Marne-la-vallée). The name does not convey the main information (that we are going to the *commutative* world). It has been around for a long time in MuPAD-Combinat - Abelianization: contains the main information - number of occurences of letters: very explicit but long So altogether I hesitate between evaluation and abelianization, with a preference for the second one but mitigated by the advantage of minimal change :-) evaluation is very common in tableaux combinatorics. Best, Anne -- 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.
Re: [sage-combinat-devel] sage-combinat repo is still down
Hi, I fixed combinat. It had not crashed, but something was amis with the networking. I restarted the network interface, and most things worked, but I couldn't get /home to properly remount over NFS. So I applied a bunch of OS updates, many involving networking, rebooted (for the first time in 2 months), and now everything seems fine. This may have been a networking-related bug in Ubuntu 12.04.1LTS. With luck it is fixed by this new upgrade. There were no processes running on combinat at the time, so the reboot should have been minimally invasive. William On Mon, Nov 5, 2012 at 7:37 AM, William Stein wst...@gmail.com wrote: On Mon, Nov 5, 2012 at 7:18 AM, Christian Stump christian.st...@gmail.com wrote: Hi all, any idea what the problem with the sage-combinat repository is, or when it will be alive again? It looks like the machine is firewall'ing itself, yet again, for no apparent reason, or ssh got killed: wstein@sage:~$ ping combinat PING combinat (128.208.160.193) 56(84) bytes of data. 64 bytes from combinat (128.208.160.193): icmp_seq=1 ttl=64 time=0.194 ms 64 bytes from combinat (128.208.160.193): icmp_seq=2 ttl=64 time=0.356 ms ... wstein@sage:~$ ssh combinat ssh_exchange_identification: Connection closed by remote host I will hook a console up to it today, within the next few hours, and see what happened. I uninstalled the firewall, fail2ban, and ubuntu automatic upgrades, so I'm surprised by this. -- William Thanks, Christian -- 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. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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.
[sage-combinat-devel] Re: [wst...@math.washington.edu: [sage-combinat-commits] [Sage] #13688: FiniteEnumeratedSets cardinality override]
Hey Nicolas,
On Monday, November 5, 2012 3:10:11 PM UTC-8, Nicolas M. Thiery wrote:
Hi Travis!
Answering on sage-combinat-devel since trac access is to slow from
here.
- Forwarded message from Sage wst...@math.washington.edujavascript:
-
Right now the category `FiniteEnumeratedSets` overrides a parent class's
`cardinality()` when creating a list. Below is a minimal example of this
behavior:
{{{
from sage.structure.parent import Parent
from sage.categories.finite_enumerated_sets import FiniteEnumeratedSets
class TestParent(Parent):
def __init__(self):
Parent.__init__(self, category=FiniteEnumeratedSets())
def __iter__(self):
yield 1
return
def cardinality(self, n):
EXAMPLES::
sage: P = sage.combinat.category_doctest_fail.TestParent()
sage: P.cardinality(-1)
-1
sage: v = P.list(); v
[1]
sage: len(v)
1
sage: P.cardinality()
1
sage: P.cardinality(-1) # This test breaks
-1
return n
}}}
This seems to be caused by not checking if the parent class has a
`cardinality()` function implemented, and just overriding it with
`_cardinality_from_list()` (which takes no [optional] parameters).
--
Yes: under the current conventions, the cardinality method is not
supposed to take an argument. So if the list of elements has been
computed, it can be safely overwritten by something faster.
Do you have a strong rationale for deviating from the conventions?
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?
Best,
Travis
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sage-combinat-devel/-/bXdXTxljJrgJ.
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.
