Re: [sage-combinat-devel] Re: Should ClasscallMetaclass do a consistency test?
Hi Andrew! ... about partition being or not a subclass of partition tuple The situation is pretty similar to skew partitions: a partition can be interpreted as a degenerate case of skew-partition as well as a degenerate case of tuple of partitions. The question is whether we want the trivial bijection between partitions and 1-uples of partitions to be implicit or explicit. I would not want the concrete class Partition to be a subclass of PartitionTuple because the data structure for a partition is not the same as for a tuple of partitions (unless we accept a level of indirection for partitions which seems a waste to me). More importantly, I don't expect the same result for p[0] when p is a partition or a tuple of partitions. On the other hand it could possibly make sense to have a common abstract super class for Partition and PartitionTuple. If I was to decide myself, I would listen to the code and see what, if anything, goes in this potential abstract class. 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 unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Should ClasscallMetaclass do a consistency test?
Hi Volker, On 2013-08-01, Volker Braun vbraun.n...@gmail.com wrote: The surprise factor that a function returns a differently-named class is a lot less than the surprise you get when something that looks like a class constructor call gives you a completely unrelated instance, that is totally at odds with normal Python syntax. Yes, that's the point I wanted to make. If it is a class, then it should return an instance of this class. If one wants the return value be just *anything* unrelated to a specific class, then one should use a factory function (that is not in disguise, i.e., a factory function that does not look like a class). The background of my original question is #14912 (UniqueRepresentation tutorial could use more love). From the discussion here, I got the impression that people do not like to actually raise an error if a class-with-classcall-metaclass returns an instance of an unrelated class. But it seems that people would accept if it would be stated in the documentation that one should use UniqueRepresentation (or CachedRepresentation) if the returned instances are actual instances, and that one should use UniqueFactory otherwise. Cheers, Simon -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Should ClasscallMetaclass do a consistency test?
On Tuesday, 30 July 2013 14:18:28 UTC+2, Simon King wrote: Hi all, On 2013-07-29, Simon King simon...@uni-jena.de javascript: wrote: After all, we have a class, and we call the class as if to create an instance---but what we get is in fact not an instance of this class, but is instance of a *totally* different class. OK, it is possible, Python let's you do it. But not all what can be done should be done. I have nothing against the following pattern: ... And I think this pattern is totally fine, since C(...) returns instances of sub-classes of C (namely of A resp. B)---hence, it returns instance of C! I could imagine that a similar pattern would be available for Partition versus PartitionTuple. I determined all classes-with-ClasscallMetaclass that sometimes return instances that are not instances of this class: sage.combinat.composition.Compositions sage.combinat.integer_vectors_mod_permgroup.IntegerVectorsModPermutationGroup sage.combinat.partition.Partitions sage.combinat.partition_tuple.PartitionTuple sage.combinat.posets.poset_examples.Posets sage.combinat.root_system.type_relabel.CartanType sage.combinat.tableau_tuple.StandardTableauTuple sage.combinat.tableau_tuple.StandardTableauTuples sage.combinat.tableau_tuple.TableauTuple sage.combinat.tableau_tuple.TableauTuples plus three classes that seem only to be made for doctests. What do you think? These are relatively few classes. Would it be reasonable to change them, such that when on tries to create instances of these classes then one is guaranteed to actually get an instance of these classes (or a sub-class, at least)? I have no objection provided that the new code continues to respect the underlying *mathematical relationships* between these classes. I think that changing the classes so that they respect semantic niceities whilst breaking the underlying mathematical relationships, which these classes are meant to emulate, would be a mistake. It would also delay my porting into sage what I think is probably the best avilable code for working with representation theory of the symmetric groups in positive characteristic. Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Should ClasscallMetaclass do a consistency test?
Hey Simon, On Tuesday, July 30, 2013 9:18:28 PM UTC+9, Simon King wrote: Hi all, On 2013-07-29, Simon King simon...@uni-jena.de javascript: wrote: After all, we have a class, and we call the class as if to create an instance---but what we get is in fact not an instance of this class, but is instance of a *totally* different class. OK, it is possible, Python let's you do it. But not all what can be done should be done. I have nothing against the following pattern: ... And I think this pattern is totally fine, since C(...) returns instances of sub-classes of C (namely of A resp. B)---hence, it returns instance of C! I could imagine that a similar pattern would be available for Partition versus PartitionTuple. I determined all classes-with-ClasscallMetaclass that sometimes return instances that are not instances of this class: sage.combinat.composition.Compositions sage.combinat.integer_vectors_mod_permgroup.IntegerVectorsModPermutationGroup sage.combinat.partition.Partitions sage.combinat.partition_tuple.PartitionTuple sage.combinat.posets.poset_examples.Posets sage.combinat.root_system.type_relabel.CartanType sage.combinat.tableau_tuple.StandardTableauTuple sage.combinat.tableau_tuple.StandardTableauTuples sage.combinat.tableau_tuple.TableauTuple sage.combinat.tableau_tuple.TableauTuples plus three classes that seem only to be made for doctests. What do you think? These are relatively few classes. Would it be reasonable to change them, such that when on tries to create instances of these classes then one is guaranteed to actually get an instance of these classes (or a sub-class, at least)? This part is for the parent classes. As it stands, the return type is something that behaves like the object you expect, so it still walks like a duck and quacks like a duck, even if it is not a duck. I don't like factory functions since you call Permutations(blah) and get an object of type Permutations_class, which make the code more difficult to understand wrt type-checking. However I'm okay with adding an extra level of abstract classes (which are probably just going to be a marker interface, i.e. have no methods/attributes) since it gives it a unifying type-check. For the element classes, this is more tricky since the data structure changes depending upon input, but this isn't strictly a bad thing. For example, if creating a complex number returned a real number if the imaginary part is 0, this should be okay because we might want to know it is a real number and take advantage of more specialized methods/algorithms. In the case of the tuples, a partition/tableau 1-tuple behaves exactly like a usual partition/tableau resp. so it doesn't seem like so much of a surprise that it returns an honest partition/tableau. Overall, I'm not convinced that __classcall__() should force its return to be a subclass of itself, but I'm okay with labeling the practice as evil. Best, Travis -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Should ClasscallMetaclass do a consistency test?
Am Sonntag, 28. Juli 2013 14:23:39 UTC+2 schrieb Simon King: It turns out that a lot of stuff in sage.combinat breaks. Apparently some people really want that if C is a class then C(*args,**kwds) is not an instance of this class. Here is an example: sage: mu = PartitionTuple([3,2]) sage: isinstance(mu, PartitionTuple) False sage: type(mu).mro() [sage.combinat.partition.Partitions_all_with_category.element_class, sage.combinat.partition.Partition, sage.combinat.combinat.CombinatorialObject, sage.structure.element.Element, sage.structure.sage_object.SageObject, sage.categories.category.InfiniteEnumeratedSets.element_class, sage.categories.enumerated_sets.EnumeratedSets.element_class, sage.categories.sets_cat.Sets.element_class, sage.categories.category.SetsWithPartialMaps.element_class, sage.categories.objects.Objects.element_class, object] sage: type(PartitionTuple) type 'sage.misc.classcall_metaclass.ClasscallMetaclass' I think it is a misuse to let a class create instances not of itself or a sub-class, but of a totally different class. Best regards, Simon -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
[sage-combinat-devel] Re: Should ClasscallMetaclass do a consistency test?
On Sunday, 28 July 2013 19:56:02 UTC+2, Simon King wrote: Am Sonntag, 28. Juli 2013 14:23:39 UTC+2 schrieb Simon King: It turns out that a lot of stuff in sage.combinat breaks. Apparently some people really want that if C is a class then C(*args,**kwds) is not an instance of this class. Here is an example: sage: mu = PartitionTuple([3,2]) sage: isinstance(mu, PartitionTuple) HI Simon, I wrote this and although I agree it is an abuse is it what I wanted and I think that, mathematically, it is the correct behaviour. The point is that a partition is a 1-tuple of partitions and hence a partition tuple. On the other hand, in most applications (in mathematics or in sage) you don't want to think of a partition as tuple of partitions. As such I think this is a mild abuse as the class s returning a closely related class. In terms of implementation, this was discussed a ittle on sage-combinat. The general feeling was that the implementation of PartitonTuple should not compromise the Partition class because partitions are in so many places. To avoid code duplication I would have liked to have both classes inherit from a common super class (but still with the behaviour above that you don't like), but the general feeling was that this was a bad idea. As it stands now,the Partition and PartitionTuple classes play very well together , I think. Even though PartitionTuple does not always return a PartitionTuple it behaves as if it does. In my own applications I *need* Partition and PartitionTuple to behave identically -- the methods that I use exist in both classes -- and the current code achieves this. To continue your example: sage: mu = PartitionTuple([3,2]) sage: mu in PartitionTuples() True I know your posts are more general than this one example, but hopefully having my (possibly misguided) rationale explained for this one example with help the discussion. If there are better ways to implement these classes Id be very pleased to hear them, but I do want the behaviour above. Cheers, Andrew -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
