>
>
>> I have just pushed the partiton tuple patch, #13072, back onto the 5.2
>> queue and onto trac. If your offer extends to reviewing this patch I'd
>> appreciate it!
>>
>
>
>> Of course it does, and I will also review #9265 to take care of that
> dependency.
>
> Thanks very much Trav
> Another change you might consider working on, starting with
> PartitionsTuple, would be to use ClonableArray, ClonableIntArray, and
> friends rather than CombinatorialObject. The latter is doomed to
> deprecation in favor of the former which are cleaner, faster, and more
> powerful (e.g. yo
On 8/2/12 9:41 AM, Nicolas M. Thiery wrote:
> On Thu, Aug 02, 2012 at 10:30:19AM +0200, Martin Rubey wrote:
>> "factors" (I wouldn't look for tensor_factors in a Cartesian product)
>
> I like that. Other suggestions? Would it make sense to call it
> `operands`, by analogy with symbolic expressions
Hey Andrew,
I guess that no one is working on converting partitions to the category
> framework since no one has said anything. I'll volunteer to do this
> once/if? my partition tuples patches make it through. Until it's clear what
> is happening with these I'd rather not start another large pa
Hi Nicolas,
Thanks for your work on rebasing the queue.
I rebased trac_5457-symmetric_functions-mz.patch on sge-5.3.beta0
and folded in trac_5457-review-as.patch as well. However, this new
patch is unfortunately not compatible with the sage-combinat queue
since that then gives a conflict with /ca
In fact, there is no problem: I made a mistake that explains why the
compilation failed. Frédéric Chapoton helped me and everything is now in order.
Cheers,
Matthieu
De : Nicolas M. Thiery
À : sage-combinat-devel@googlegroups.com
Envoyé le : Jeudi 2 août 2012
On Thu, Aug 02, 2012 at 10:30:19AM +0200, Martin Rubey wrote:
> "factors" (I wouldn't look for tensor_factors in a Cartesian product)
I like that. Other suggestions? Would it make sense to call it
`operands`, by analogy with symbolic expressions?
sage: f = x+1
sage: f.operands()
[x, 1
Dear Matthieu,
On Fri, Jul 27, 2012 at 02:46:12PM +0100, Matthieu Deneufchatel wrote:
>I tried to compile sage 5.1 on Mageia 2. It did not work. Below is the log
>file and the result of ../sage. Since it is the first time I compile a
>program, I do not know what to do and I do
Hi Andrew,
On Tue, Jul 31, 2012 at 06:24:05PM -0700, Andrew Mathas wrote:
>I guess that no one is working on converting partitions to the
>category framework since no one has said anything.
I haven't heard of anyone working on it either, and I would expect the
preliminary patch to
> Pushed. Hmm, still getting a little conflict on
> concrete_combinatorial_statistics_and_maps-cs.patch after merging. I
> guarded it for now. Off to bed!
It's good to see the queue working, at least for 5.2, again.
Dan
--
You received this message because you are subscribed to the Google Gr
On Wed, Aug 01, 2012 at 08:38:49PM +0200, Nicolas M. Thiery wrote:
> Ok, I am hopefully done with the rebase: as soon as I'll have a
> network available to push, the Sage-Combinat queue should apply
> smoothly on both Sage 5.1 and 5.2. Please report any problem!
Pushed. Hmm, still getting a little
On Wed, Aug 01, 2012 at 04:54:45PM -0700, Volker Braun wrote:
>In general all your objections are already dealt with by the deprecation
>framework, its just that in this exceptional / self-referential case it
>didn't work. Fine. I'm open for constructive suggestions, but you haven't
>
On Wed, Aug 01, 2012 at 08:38:49PM +0200, Nicolas M. Thiery wrote:
> Ok, I am hopefully done with the rebase: as soon as I'll have a
> network available to push, the Sage-Combinat queue should apply
> smoothly on both Sage 5.1 and 5.2. Please report any problem!
I forgot to mention: thanks much to
On Mon, Jul 30, 2012 at 12:29:39PM +0900, Vincent Delecroix wrote:
> Dependencies should be used in trac (it is one of the field in the
> definition of the ticket and consists an a (possibly empty) sequence
> of patches). An example at [1]. When a patch is ready in sage-combinat
> it should apply c
On Wed, Aug 01, 2012 at 02:31:52PM -0700, Anne Schilling wrote:
> For me it does not apply on sage-5.2:
>
> applying trac_13243-new_methods_for_compositions-fs.patch
> applying trac_13233-add_sstposet.patch
> applying trac_13224-poset-slender-as.patch
> applying trac_12140-sf_schur_done_w_lrcalc-m
Hi Nicolas!
thanks for the detailed explanation! One thing I don't quite
understand:
> A consequence of the above is that a piece of code that takes a
> decision upon the properties of a parent should use the `R in Fields`
> or `R in Fields()` idiom, unless there is a very good reason not to.
S
Anne Schilling writes:
> On 8/1/12 12:23 PM, Nicolas M. Thiery wrote:
>> On Fri, Jul 27, 2012 at 09:01:46PM +0200, Martin Rubey wrote:
>>> Maybe f.parent()._sets is what you want?
>>
>> Speaking of which: we probably should expose that using some method
>> foo, so that if F is the tensor/cartesi
17 matches
Mail list logo
