Re: [sage-combinat-devel] Re: Compositions in reverse order?

2013-01-22 Thread Florent Hivert
On Tue, Jan 22, 2013 at 04:33:33AM -0800, Nathann Cohen wrote:
> Well, for a start you cannot ask Sage to reverse the iteration order of 
> anything that you can iterate on.
> 
> First example : reversed(NN)
> 
> And so there is no good solution in general unless you implement the 
> reversed iterator yourself, or list all elements.
> 
> Then, instead of list(reversed(Compositions(4).list())) (which creates the 
> list twice in memory plus an interator on top of it), you can do this :
> 
> C = Compositions(4).list()
> C.reverse()
> 
> Then :
> for c in C:
>print c
> 
> or
> 
> for i in range(len(C)):
> print C[i]

Tu peux faire aussi:

sage: Compositions(4).list()[::-1]
[[4], [3, 1], [2, 2], [2, 1, 1], [1, 3], [1, 2, 1], [1, 1, 2], [1, 1, 1, 1]]

Par rapport à la solution de Nathann, je fais une copie...

Florent

-- 
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: Compositions in reverse order?

2013-01-22 Thread Jean-Yves Thibon



On Tue, Jan 22, 2013 at 04:33:33AM -0800, Nathann Cohen wrote: 
> > Well, for a start you cannot ask Sage to reverse the iteration order of 
> > anything that you can iterate on. 
> > 
> > First example : reversed(NN) 
>

OK, but there is some inconsistent behavior, anyway:


sage: P=Partitions(4)
sage: len(P)
5
sage: C=Compositions(4)
sage: len(C)
---
AttributeErrorTraceback (most recent call last)

/home/jyt/monge/TEX/QSCHUR/ in ()

/home/jyt/src/sage-5.4.1/local/lib/python2.7/site-packages/sage/combinat/combinat.py
 
in __len__(self)
972 AttributeError: __len__ has been removed; use 
.cardinality() instead
973 """
--> 974 raise AttributeError, "__len__ has been removed; use 
.cardinality() instead"
975 
976 def count(self):

AttributeError: __len__ has been removed; use .cardinality() instead
sage: R=reversed(P)
sage: list(R)
[[1, 1, 1, 1], [2, 1, 1], [2, 2], [3, 1], [4]]



 

>
>

-- 
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/-/FOawuYfuDjwJ.
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: Compositions in reverse order?

2013-01-23 Thread Florent Hivert
  Dear Jean-Yves,

> OK, but there is some inconsistent behavior, anyway:
> 
> 
> sage: P=Partitions(4)
> sage: len(P)
> 5
> sage: C=Compositions(4)
> sage: len(C)
> ---
> AttributeErrorTraceback (most recent call last)
> 
> /home/jyt/monge/TEX/QSCHUR/ in ()
> 
> /home/jyt/src/sage-5.4.1/local/lib/python2.7/site-packages/sage/combinat/combinat.py
>  
> in __len__(self)
> 972 AttributeError: __len__ has been removed; use 
> .cardinality() instead
> 973 """
> --> 974 raise AttributeError, "__len__ has been removed; use 
> .cardinality() instead"
> 975 
> 976 def count(self):
> 
> AttributeError: __len__ has been removed; use .cardinality() instead
> sage: R=reversed(P)
> sage: list(R)
> [[1, 1, 1, 1], [2, 1, 1], [2, 2], [3, 1], [4]]

Yes ! As you probably already guessed, everything is not yet in a clean
state... The first call should raise the same error than the second one. We
can't answer consistently to len because Python specified it as being a
machine integer. This is much too small for cardinality of combinatorial set
and prevent for returning infinity. So as the error message tell you, please
write

sage: P=Partitions(4)
sage: P.cardinality()
5

sage: P=Partitions(4000)
sage: P.cardinality()
1024150064776551375119256307915896842122498030313150910234889093895

sage: P=Partitions()
sage: P.cardinality()
+Infinity

And indeed, I think that

sage: len(Compositions(4000))
[...]
AttributeError: __len__ has been removed; use .cardinality() instead

Is a much clean behavior than:

sage: len(Partitions(4000))
[...]
RuntimeError: maximum recursion depth exceeded in cmp

A++

Florent

-- 
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: Compositions in reverse order?

2013-01-23 Thread Nathann Cohen
> And indeed, I think that
>
> sage: len(Compositions(4000))
> [...]
> AttributeError: __len__ has been removed; use .cardinality() instead
>
> Is a much clean behavior than:
>
> sage: len(Partitions(4000))
> [...]
> RuntimeError: maximum recursion depth exceeded in cmp

Then patch it, if it is a bug !!! O_O

Nathann

-- 
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: Compositions in reverse order?

2013-01-23 Thread Florent Hivert
On Wed, Jan 23, 2013 at 10:45:06AM +0100, Nathann Cohen wrote:
> > And indeed, I think that
> >
> > sage: len(Compositions(4000))
> > [...]
> > AttributeError: __len__ has been removed; use .cardinality() instead
> >
> > Is a much clean behavior than:
> >
> > sage: len(Partitions(4000))
> > [...]
> > RuntimeError: maximum recursion depth exceeded in cmp
> 
> Then patch it, if it is a bug !!! O_O

Thanks for this very useful contribution !

Florent

-- 
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: Compositions in reverse order?

2013-01-23 Thread Nathann Cohen
> Thanks for this very useful contribution !

So what happens ? You know that there's a bug, it takes 3 seconds to
fix it, and you don't ?

Nathann

-- 
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: Compositions in reverse order?

2013-01-23 Thread Jean-Yves Thibon


>
> Yes ! As you probably already guessed, everything is not yet in a clean 
> state... The first call should raise the same error than the second one.
>

I understand, but in this case, one should teach  "reversed" to use
Cardinality instead of __len__. And this is python, not sage ... 

-- 
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/-/3XiisWOYN_gJ.
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: Compositions in reverse order?

2013-01-23 Thread Travis Scrimshaw
Hey everyone,

On Wednesday, January 23, 2013 3:42:55 AM UTC-8, Jean-Yves Thibon wrote:
>
>
>
>> Yes ! As you probably already guessed, everything is not yet in a clean 
>> state... The first call should raise the same error than the second one.
>>
>
> I understand, but in this case, one should teach  "reversed" to use
> Cardinality instead of __len__. And this is python, not sage ... 
>
> We could do this by just implementing the __reversed__() method in (the to 
be deprecated) CombinatorialClass. However on the deprecation note, we will 
need to decide whether or not __len__() and __reversed__() should be added 
to the (Finite) EnumeratedSets category. Without knowing exactly how sage 
handles __getitem__() with sage Integers passed in (my belief is everything 
is converted to machine ints and uses the python list (which is an  array 
in memory [1]) ), I feel like we should leave __len__() alone since if we 
are trying to create/manipulate a list longer than int (and hence the 
machine) can handle, you need a better data structure and storage method 
and __len__() should fail in the same way as trying to create/retrieve the 
list.

[1] 
http://stackoverflow.com/questions/914233/what-is-the-underlying-data-structure-for-python-lists

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/-/rXatiGt2fAoJ.
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: Compositions in reverse order?

2013-01-23 Thread Jean-Yves Thibon

The problem is that, for the average user, Partitions(n), or 
Compositions(n), or
Whatever(n) is expected to behave like, say, xrange(n). Removing __len__ 
breaks basic
python functionalities, results in  head scratching ("What am I doing 
wrong?"),
and drives the user to a hack-oriented programming style.

For algebraic purposes, I have never seen partitions of more than 25 or 
compositions
of more than 16, let alone permutations of more than 14 . 
For number theory or enumerative combinatorics, one needs much larger 
values, 
but a user trying to generate more than 
2**62 = 4611686018427387904 objects will probably accept an overflow error. 

So, why not let __len__ try to return int(cardinality) and throw and
exception if it is too large? 


-- 
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/-/ou74j7SCMasJ.
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: Compositions in reverse order?

2013-01-24 Thread Florent Hivert
  Hi Jean-Yves,

I'm very happy to see you starting to use sage and giving us constructive
feedback.


On Wed, Jan 23, 2013 at 11:31:37PM -0800, Jean-Yves Thibon wrote:
> 
> The problem is that, for the average user, Partitions(n), or 
> Compositions(n), or
> Whatever(n) is expected to behave like, say, xrange(n). Removing __len__ 
> breaks basic
> python functionalities, results in  head scratching ("What am I doing 
> wrong?"),
> and drives the user to a hack-oriented programming style.

I'm not sure to agree with that. I also think, you are not an average Sage
user, you know way too much of Python. In this case "xrange(n)" is an
iterator, that is a Python/computer stuff, whereas Partitions(n) models the
sets of all partitions of n. 

> For algebraic purposes, I have never seen partitions of more than 25 or 
> compositions
> of more than 16, let alone permutations of more than 14 . 
> For number theory or enumerative combinatorics, one needs much larger 
> values, 
> but a user trying to generate more than 
> 2**62 = 4611686018427387904 objects will probably accept an overflow error. 
> 
> So, why not let __len__ try to return int(cardinality) and throw and
> exception if it is too large? 

The main problem i see with that is that in many time cardinality is
implemented by running through the element... A similar problem is that I've
no way to prevent the user to write:

sage: list(Partitions())
...
infinite loop

which is closely related to

sage: len(Partitions())
...
AttributeError: __len__ has been removed; use .cardinality() instead

whereas I'd like to teach him as soon as possible to write

sage: Partitions().list()
[...]
NotImplementedError: infinite list
sage: Partitions().cardinality()
+Infinity

which both are fast to answer an perfectly makes sense. I've the feeling that
keeping the len stuff leads to more confusion for mathematician (not for
Python programmer).

Cheers,

Florent

-- 
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.