[sage-combinat-devel] Re: Using lots of posets in Sage 5.0 and later causes high memory usage and eventual crash

[Simon King]

Hi Martin,

On 2012-11-23, Martin Malandro  wrote:
> --=_Part_784_25730379.1353708869141
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi everyone,
>
> I've dug around in the source code for several days now, and the issue is 
> not in the poset code specifically. Rather, the above problem is being 
> caused by this bug in UniqueRepresentation, which FinitePoset inherits from:
>
> http://trac.sagemath.org/sage_trac/ticket/12215

No surprise. The problem with #12215 and related tickets (#715, #11521,
#12313) is that some memory corruptions in libsingular become immanent
only when the garbage collection works properly - hence, before being
able to merge #12215 stably into sage, one needs to fix some bugs in
(lib)singular, part of which seem to be upstream bugs.

Cheers,
Simon

-- 
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: Permutations... again.

[Andrew Mathas]

Hi Nathan,

I'm sure that I should drop this but...

I don't know. People usually pay attention to the code they wrote even much 
> later. I still write to Robert Miller when I have questions on the graph 
> backends, and I like to have his advice on Sage things from time to time. 


When ever anything gets big enough I think this starts to break down. For 
example, when I whined about the lack of documentation for the pickle jar 
the people who put this is place didn't feel the need to step in and 
address this. Even though I am just a sage-combinat customer:), I posted a 
patch on trac and it is being reviewed (really!).

>
> > The absent or poor documentation is what I like least about sage.
>
> Welcome to the graph world :
>
 
I agree that's nice, but what I am complaining about is a general lack of 
documentation in sage, particularly for the metaclass framework, rather 
than documentation for code in sage/combinat. If you check, the code in 
sage/combinat has a relatively high coverage rate.

One other point I really do not like about the combinat model is that, 
> unfortunately, you all know each other. 


I am really quite amazed that you see this as a bad thing! Because the 
people in sage-combinat do talk to each other you can, if you want, get a 
lot of feedback when writing something. Moreover, in my experience, when a 
patch is ready to be reviewed it normally happens very quickly.

1) A bugfix patch for something that is in Sage should NEVER be included in 
> Sage-combinat. It should be sent to Sage, and sage-combinat will inherit it 
> later, when Sage is updated. This way bugfix patches will be merged before 
> the author's death
>

 I think that was you are really complaining about are bug fixes which end 
up in the sage-combinat queue but are *not* posted to trac. I fully agree 
that patches should be posted to trac as soon as they are ready for review 
and that people shouldn't keep half finished patches lying around in the 
sage-combinat queue, or elsewhere. I don't see any harm, however, in a 
patch being both on trac and also in the sage-combinat queue if it is 
relevant.
 

> 2) Something I discussed with Florent : everybody in Sage-combinat should 
> have at most 2 or 3 patches in the queue. Nothing more. If you want to add 
> another one, get your patches merged into Sage
>
 
As Anne said, "it would be a good idea to try to integrate patches in the 
sage-combinat 
queue more quickly."

3) Why the hell do you need to have your own fork anyway ? (just my own 
> thought, but I still don't exactly get it)
>
 
For me one of the key advantages of the sage-combinst queue is that it 
allows code to be used and tested while it is being developed and before it 
is reviewed. The best way to test code it to use it, so this actually saves 
a lot of time and leads to better code.

4) Just look at the TRAC section named combinat. Each time I go look at the 
> patches, I just dream to put them all on "need_work" state.
>

I think this is a little spurious: you see a similar picture with every 
component of sage, especially when you adjust for the size of the 
components. I think that this is a fair criticism of the sage-combiat *patch 
queue* but not of the patches on trac. Btw, many of these posts on trac 
come from the general sage community and in addition to patches being 
reviewed there are also feature requests

Let me end by saying that I thought it funny that you make such a big 
distinction between sage and sage-combinat as I don't really see a 
difference. As I see it, the development model of sage and sage-combinat, 
which is after all just a subset, is exactly the same. The sage-combinat 
patch queue makes it easier for people working on applications in algebraic 
combinatorics to talk with each other and to exchange ideas. The queue is a 
pain to maintain sometimes but I think it's infinitely better than emailing 
patches back and forwards or pushing half finished patches to trac. 

The bottom line, which is completely independent of the sage-combinat patch 
queue*,* is that if you don't like something in sage then you have to jump 
in and fix it -- or convince some one to do it for you!

Cheers,
Andrew

-- 
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/-/DnT5syYPTGMJ.
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: [sage-devel] Re: Changing the default behaviour of Poset

[Travis Scrimshaw]

Hey everyone,
   I just had an idea, and maybe this is more wishful thinking, but I feel 
like we should be able to pass a poset/lambda function(s)/class which 
contains comparison methods into a parent and have that be able to override 
the default ordering (similar to what C++ does in the STL). Something like 
this:

sage: g = DiGraph([(0,1),(0,2)]) 
sage: p = Poset(g)
sage: G = IntegerRingMod(3, ordering=p)
sage: G(0) < G(1)
True
sage: G(0) < G(2)
True
sage: G(1) < G(2)
False

Or for partitions under dominance order (instead of how we currently are 
doing them in 13605):

sage: P = Partitions(3, cmp_lt=Partition_class.dominates) # after 13605 
this would just be Partition.dominates
sage: P([2,2,1]) < P([3,1,1])
True

Thoughts?

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/-/cxHdEtxOcrAJ.
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: state of the queue: 5.4, 5.5.beta0

[Andrew Mathas]

> Andrew, I've rebased the patch by changing the compact option in _repr_() 
> to the method _repr_compact() (to fit into the display options framework 
> for partition/tableau objects).
>
> Thanks for doing this for me Travis and Nicolas! I've just synced and 
everything is fine.

Cheers,
Andrew  

-- 
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/-/a0l7PdMYpLIJ.
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: Permutations... again.

[Nathann Cohen]

> 1) I will try to upload a patch this very week-end that changes the dfault
> behaviour of Poset as mentionned there :

Done ! It is now patch 13747 :
http://trac.sagemath.org/sage_trac/ticket/13747

And it is also very, very late... :-P

Good night everybody !

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.

[sage-combinat-devel] Re: Using lots of posets in Sage 5.0 and later causes high memory usage and eventual crash

[Martin Malandro]

Hi everyone,

I've dug around in the source code for several days now, and the issue is 
not in the poset code specifically. Rather, the above problem is being 
caused by this bug in UniqueRepresentation, which FinitePoset inherits from:

http://trac.sagemath.org/sage_trac/ticket/12215

-- 
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/-/LeVVgmUWFzUJ.
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: state of the queue: 5.4, 5.5.beta0

[Travis Scrimshaw]

That was my fault due to changes in trac_13605-partition_options-ts.patch.
<.<
>.>
Andrew, I've rebased the patch by changing the compact option in _repr_() 
to the method _repr_compact() (to fit into the display options framework 
for partition/tableau objects).

The queue should now apply cleanly. Thanks Nicolas.

Best,
Travis


On Friday, November 23, 2012 6:38:32 AM UTC-8, Nicolas M. Thiery wrote:
>
> On Fri, Nov 23, 2012 at 03:21:56PM +0100, Christian Stump wrote: 
> > I would really appreciate if we could make the queue apply on 5.5.rc0, 
> > if possible (or has this happened already without me noticing?). 
>
> Ok, I'll work now on rebasing my patch for 5.5.rc0. Sorry it's taking 
> so long. 
>
> Btw, Andrew: on 5.4 I get a failure for tableaux-combinatorics-am.patch: 
>
> patching file sage/combinat/tableau_tuple.py 
> Hunk #2 succeeded at 235 with fuzz 1 (offset 1 lines). 
> Hunk #4 FAILED at 431 
> Hunk #11 succeeded at 1955 with fuzz 2 (offset 58 lines). 
> 1 out of 22 hunks FAILED -- saving rejects to file 
> sage/combinat/tableau_tuple.py.rej 
>
> Cheers, 
> Nicolas 
> -- 
> Nicolas M. Thi�ry "Isil" > 
> http://Nicolas.Thiery.name/ 
>

-- 
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/-/M-0uvAceV3oJ.
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: Permutations... again.

[Anne Schilling]

Hi Andrew and all,

> Does anyone have any /concrete suggestions/ for how we could improve the 
> "development model"? There is definitely room for improvement but short of 
> paying someone I don't have any good suggestions.
> The problem is that what I want implemented is often different to what 
> everyone else wants, but thankfully there is some overlap and so some give 
> and take. Ideas anyone?

I think it would be a good idea to try to integrate patches in the sage-combinat
queue more quickly. This means less rebasing that is necessary, less
frustration trying to commute patches etc. (this past summer we had some
frustration with these issues getting a 15,000 line patch on symmetric functions
into sage). Sometimes it might be possible to achieve this by writing more
incremental patches, but this is not always possible.

Nathann, since the ultimate aim of the patches in the sage-combinat queue is
to get them into sage eventually, I do not think it is a fork. It is
a "playground" for the current code, so that it is easier to share the
code than everyone downloading the individual not-yet-finished patches
from the trac server.

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] Re: Permutations... again.

[Nathann Cohen]

Helloo !!!

> Would you mind taking a break and stop spreading FUD?

Ok, so let's get to work. I created #13742 yesterday and it is waiting for
a review :
http://trac.sagemath.org/sage_trac/ticket/13742

> You are not
> being fair.

I know. You know. Florent knows. I always speak too much.

> I totally know and care about all the crap in the combinat
> code.

Right. This Permutation thing is waiting for a review right now. Then :

1) I will try to upload a patch this very week-end that changes the dfault
behaviour of Poset as mentionned there :

https://groups.google.com/forum/?fromgroups=#!topic/sage-devel/qQzzZEh-JRo

And also (as expected) in the sage-combinat fork of that thread (only Dima
answered there)

https://groups.google.com/forum/?fromgroups=#!topic/sage-combinat-devel/bfWbG54sedM

It will not be backward-compatible, and I will write to Sage-devel-combinat
to warn people about that.

2) I will also try to deal with this *&@#(@%(@#$ piece of code which says
that two Posets may not be equal even if they have the same hasse diagram.
This is *WRONG*, so it has to be changed, Wrong, and dangerous. And bad
code. Two Posets are equal if and only if their hasse diagram are equal. No
cached linear extension involved. Equality in Posets *HAS* to be valid.

> It hurts me everyday. More than you think. There is just a
> bounded amount of manpower and not everything can be tackled at once.

Nothing against lack of manpower, for as long as I see that everybody
honestly tries.

> There is a lot of Sage-Combinat code going into Sage and things *are*
> progressing, including in the cleanup of old code.

Yeah, there I was probably guilty of bad faith, but I am a regular.

> There is also infrastructure work coming in step by step; yes it takes
> time. Sorry, those are not things one can write in an afternoon and
> just post and forget.

Some things can, I assure you. This Permutation thing above, which was my
problem. Or the default Poset (facade) thing,  I do not expect it to take
more than a day. Or the other Poset thing. All those are very bad things
which take less than a day, and most probably less than an afternoon.
Perhaps you think that many bugs you know cannot be fixed as fast as these
but I can only talk for the problems I know, and I expect that those can. I
am totally sure that they are not the only ones.

> Yes we are a community. I am proud of that.

Sage is also a community. Do you feel like joining us ? :-P

> We help each other,

Err... When you have a Graph problem, you know that you can knock on my
door, and so you did several times. What you got the very day or the day
after when the code was not already available, is a track ticket with a
patch waiting for a review.
Like there : http://trac.sagemath.org/sage_trac/ticket/13664
Like there : http://trac.sagemath.org/sage_trac/ticket/12235

I told you about the three problems above. Nothing happened. Please observe
that I fix them myself, because I have to.

> Categories are nothing but abstract classes. You don't need object
> orientation for your applications? Great, that's all fine to me, don't
> use it. But don't complain on people that *need* it and use it.

You are being unfair too. There is quite a gap between Object Oriented
Programming and your Category cathedral. It's not just Object Oriented
Programming, and it is packed with subjective decisions you made. It's not
as straightforward as that.

> The Sage-Combinat model is certainly not perfect, and I am happy
> discussing the imperfections as long as it's not just repeating things
> we all know (e.g. that we are slow on reviewing).

I enumerated 4 points in my previous email. Point 3 is to me the most
important, but I always try to make questions that will be ill-received
look like things you can ignore. I honestly still do not see the point of
Sage-combinat considering its many problems. All 3 others are (methinks)
very legitimate. What do you think of them ? What can be done about that ?

> Now if you want to discuss this further, let's do this face to
> face.

Nicolas, can you tell me that there is ONE thing among those I said in my
email which I have not mentionned to you before ?
I told you that you had forked Sage. I told you that I thought you needed
WAYS to force you to send patches to Sage. I told you that the code was not
documented enough, I even spent days in Cernay WRITING the documentation of
combinat code. I told you about all this way before you read this email.

> But not now. I have 20 hours of teaching to prepare for next
> week.

Happy guy. While I have it easy, living in somebody else's place, and
looking for an appartment in Paris :-P

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 gr

Re: [sage-combinat-devel] Re: state of the queue: 5.4, 5.5.beta0

[Nicolas M. Thiery]

On Fri, Nov 23, 2012 at 03:38:29PM +0100, Nicolas M. Thiery wrote:
> Ok, I'll work now on rebasing my patch for 5.5.rc0. Sorry it's taking
> so long.

Done! Please confirm that it works for you. I am going to launch some
tests now.

Hopefully, there just remains the little issue with Andrew's
patch (which occurred for me both on 5.4 and 5.5.rc0).

Note: to make the rebase easier, I had to backport 715 for Sage
<5.5.beta0. The inconvenient is that this patch triggers the
recompilation of most of the Sage library. So everyone doing regular
development will probably want to switch to 5.5.rc0.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
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: Permutations... again.

[Paul-Olivier Dehaye]

Purkayashta: this would only address (in good or bad) a tiny part of the
development issues, those that have to do with version control.
Paul



On Fri, Nov 23, 2012 at 2:01 PM, P Purkayastha  wrote:

> On 11/23/2012 08:37 PM, Andrew Mathas wrote:
>
>> Does anyone have any /concrete suggestions/ for how we could improve the
>>
>> "development model"? There is definitely room for improvement but short
>> of paying someone I don't have any good suggestions. The problem is that
>> what I want implemented is often different to what everyone else wants,
>> but thankfully there is some overlap and so some give and take. Ideas
>> anyone?
>>
>> Andrew
>>
>
> There is already a move towards a git-based development model. I hope it
> will allow people to fork and experiment in their own branches quickly
> instead of the current method of using queues, trac patches, or "sage
> -clone", etc, which I find is a painful process.
>
> I would say the git model might work better. For instance look at the
> notebook. It is very easy to work with the development branch of any
> person's fork of the notebook. At present, you can even try out out the new
> UI by simply switching the notebook branch to samuela's fork. The switch
> takes about a second once you have the branch in your git. You can quickly
> also change back to the original notebook and resume your usual work with
> that as soon as you are done experimenting. The only hurdle that I see
> right now is the about 5-6 git commands one needs to know before one can
> start working with the development branch(es) of the notebook. Part of the
> next sage-git workshop is to create tools to make this setup (and
> contributing back) easy.
>
>
> --
> 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
> .
>
>

-- 
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: state of the queue: 5.4, 5.5.beta0

[Nicolas M. Thiery]

On Fri, Nov 23, 2012 at 03:21:56PM +0100, Christian Stump wrote:
> I would really appreciate if we could make the queue apply on 5.5.rc0,
> if possible (or has this happened already without me noticing?).

Ok, I'll work now on rebasing my patch for 5.5.rc0. Sorry it's taking
so long.

Btw, Andrew: on 5.4 I get a failure for tableaux-combinatorics-am.patch:

patching file sage/combinat/tableau_tuple.py
Hunk #2 succeeded at 235 with fuzz 1 (offset 1 lines).
Hunk #4 FAILED at 431
Hunk #11 succeeded at 1955 with fuzz 2 (offset 58 lines).
1 out of 22 hunks FAILED -- saving rejects to file 
sage/combinat/tableau_tuple.py.rej

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
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: Permutations... again.

[Volker Braun]

On Friday, November 23, 2012 1:50:08 PM UTC, Nathann Cohen wrote:

> Well. You have the right to like abstracton and generalizations. I prefer 
> to duplicate code to make things independent, and easy to understand. 


Code duplication is a bug, plain and simple. If it doesn't fail outright 
then it is sure to cause somebody else grief in the future. You might think 
its easier to understand, but that is only because you put it there. The 
next person looking at it will be confused why very similar code is 
copy-pasted all over the place. Just say no to code duplication. 

That doesn't mean that you have to go to extremes in generic programming as 
Boost. But you should at least make an effort to understand the genius 
behind many of its modules. In fact, if your day-to-day code looks anything 
like Boost then you are doing something wrong. But if you design a library 
interface then I'd highly recommend it.

I agree with you that there is a lack of documentation of some of the 
abstractions, though. Without documentation, an abstraction is just 
gibberish to most people and make it more difficult to contribute to Sage. 
Like the category stuff. Is there any way to figure out what they do 
without reading the source code? Why are things done the way they are done? 
A tutorial for using them? A tutorial for when and how to write a new 
category?

-- 
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/-/saaQ1_BMI2EJ.
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: Permutations... again.

[Nicolas M. Thiery]

Hi Nathann,

Would you mind taking a break and stop spreading FUD? You are not
being fair. I totally know and care about all the crap in the combinat
code. It hurts me everyday. More than you think. There is just a
bounded amount of manpower and not everything can be tackled at once.
There is a lot of Sage-Combinat code going into Sage and things *are*
progressing, including in the cleanup of old code. Just to cite a few
recent things that got merged recently or are very close to
completion:

- Tableaux cleanups coming in by Andrew
- Cleanup in the combinatorics code by Travis, ...
- Improvements to root systems by Christian, Mark, ...
- Cleanup of Symmetric Functions by Mike, Anne, ...
- Implementation of NonCommutativeSymmetricFunctions by Chris, Franco, ...
- Quivers and cluster algebras by Christian, Gregg, ...
- Category cleanup by Simon King and myself
- Lots of reviews done by Frédéric Chapoton and Hugh Thomas
- Tutorials by many

All of those are fully documented. Thanks everybody for your hard work!

There is also infrastructure work coming in step by step; yes it takes
time. Sorry, those are not things one can write in an afternoon and
just post and forget.

Yes we are a community. I am proud of that. We help each other, and
all contribute our *different* points of view and man power. No
consumer there.

Categories are nothing but abstract classes. You don't need object
orientation for your applications? Great, that's all fine to me, don't
use it. But don't complain on people that *need* it and use it.

The Sage-Combinat model is certainly not perfect, and I am happy
discussing the imperfections as long as it's not just repeating things
we all know (e.g. that we are slow on reviewing).

Now if you want to discuss this further, let's do this face to
face. But not now. I have 20 hours of teaching to prepare for next
week.

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" 
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: state of the queue: 5.4, 5.5.beta0

[Christian Stump]

> Thanks Travis. I just pulled your rebase off the queue and now #12876 is the
> only patch which does not apply for 5.5.rc0.
>
> As before, guarding out the #12876 patches let everything else in the queue
> apply, but sage won't build.

I would really appreciate if we could make the queue apply on 5.5.rc0,
if possible (or has this happened already without me noticing?).

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.

Re: [sage-combinat-devel] Re: Permutations... again.

[Nathann Cohen]

Hellooo !!

> I share your frustrations. I think we all do, to some extent. It would be
> very nice if all of these problems, major an minor, could be fixed but the
> reality is that until some one cares enough about a particular problem
then,
> as you say, it isn't going to happen. I think this is called open-source.

I don't know. People usually pay attention to the code they wrote even much
later. I still write to Robert Miller when I have questions on the graph
backends, and I like to have his advice on Sage things from time to time.
He always answers. But because it seems the combinat/ folder is full of
stuff Mike Hansen wrote quickly, nobody feels responsible of them. That's
also something which is quickly fixed if the classes were to be rewritten.
Somebody would know them totally, and perhaps feel that they owe the
community to make it a good work. I really, really hate to see on the
sage-devel mailing list "is that a bug in a graph function ?", but
unfortunately it happens quite often. I try to answer those things as
quickly as possible with a patch. Besides, by doing that you begin to learn
what users do with Sage, and you can think of those bugs you fixed when you
write some new code.

> The absent or poor documentation is what I like least about sage.

Welcome to the graph world :

http://www.sagemath.org/doc/reference/sage/graphs/base/static_sparse_graph.html
http://www.sagemath.org/doc/reference/sage/graphs/pq_trees.html
http://www.sagemath.org/doc/reference/sage/graphs/graph_decompositions/graph_products.html
http://www.sagemath.org/doc/reference/sage/graphs/convexity_properties.html
http://www.sagemath.org/doc/reference/sage/graphs/distances_all_pairs.html
http://www.sagemath.org/doc/reference/sage/graphs/comparability.html
http://www.sagemath.org/doc/reference/sage/graphs/graph_decompositions/vertex_separation.html

Just to say that Sage contains tools that can let you write a lot of
documentation if you need to.

One other point I really do not like about the combinat model is that,
unfortunately, you all know each other. You talk with each other, you can
explain stuff to each other. And so the reviewer reviews a piece of code
that he already knows how to use.
Another thing I do not like much is that I find the code far, far, far too
much algebraic. I have 2 examples of graph libraries I could not stand to
use because of this exactly.

Boost :
http://www.boost.org/doc/libs/1_52_0/libs/graph/doc/table_of_contents.html
here's their code for breadth first search :
http://www.boost.org/doc/libs/1_52_0/boost/graph/breadth_first_search.hpp

Mascopt (developped in my former lab) :
http://www-sop.inria.fr/mascotte/mascopt/
(I spent 1 day full-time reading the manuals, and I had no idea how to
build a graph)

Well. You have the right to like abstracton and generalizations. I prefer
to duplicate code to make things independent, and easy to understand. But I
do not have much code to duplicate, perhaps you do. But I find your code
much too algebraic by far.
Funnily, several days ago Nicolas Florent and I were talking about Sage.
They wondered whether Python was a good choice of language, and whether it
would remain an important language in the future.

- "It would really be an issue to have to port all of our code to another
language, so much is based on Python..."
- "Do you really use Python at all ? I mean, you wrote categories and it
more or less replaces class inheritance in Python, doesn't it ?"

Finally, I admit that I like to play dumb, and that for a large part I do
not have to play much. But the use of categories have been explained to me
one thousand times, that each time there's something I do not like and have
to accept, and that after all that time I still hate the idea of having to
deal with it.

> It's
> annoying that quite a lot of "basic" things need to be implemented and
that
> others have been done badly. I have fixed the things that I really need,
or
> worked around them. The responsiveness of sage-devel and sage-combinat is
> nice.
>
> I switched to sage because it is the best platform that I found. Sure,
many
> things could be better, but I don't like gap4, magma, malple, mathematica,
> matlab, C, ... In spite of its many warts and problems I do like writing
in
> python and working with sage. Using sage, I have been able to compute
things
> much more quickly and painless than before when I was writing in gap. I'm
> happy with that.
>
> Does anyone have any concrete suggestions for how we could improve the
> "development model"? There is definitely room for improvement but short of
> paying someone I don't have any good suggestions. The problem is that
what I
> want implemented is often different to what everyone else wants, but
> thankfully there is some overlap and so some give and take. Ideas anyone?

The development model of Sage-combinat ? Well, I do not know much about
it... A few (very) practical thoughts :

1) A bugfix patch for something that is in Sage should

[sage-combinat-devel] Re: Permutations... again.

[P Purkayastha]

On 11/23/2012 08:37 PM, Andrew Mathas wrote:

Does anyone have any /concrete suggestions/ for how we could improve the
"development model"? There is definitely room for improvement but short
of paying someone I don't have any good suggestions. The problem is that
what I want implemented is often different to what everyone else wants,
but thankfully there is some overlap and so some give and take. Ideas
anyone?

Andrew


There is already a move towards a git-based development model. I hope it 
will allow people to fork and experiment in their own branches quickly 
instead of the current method of using queues, trac patches, or "sage 
-clone", etc, which I find is a painful process.


I would say the git model might work better. For instance look at the 
notebook. It is very easy to work with the development branch of any 
person's fork of the notebook. At present, you can even try out out the 
new UI by simply switching the notebook branch to samuela's fork. The 
switch takes about a second once you have the branch in your git. You 
can quickly also change back to the original notebook and resume your 
usual work with that as soon as you are done experimenting. The only 
hurdle that I see right now is the about 5-6 git commands one needs to 
know before one can start working with the development branch(es) of the 
notebook. Part of the next sage-git workshop is to create tools to make 
this setup (and contributing back) easy.


--
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: Permutations... again.

[Andrew Mathas]

H Nathan,

I share your frustrations. I think we all do, to some extent. It would be 
very nice if all of these problems, major an minor, could be fixed but the 
reality is that until some one cares enough about a particular problem 
then, as you say, it isn't going to happen. I think this is called 
open-source.

The absent or poor documentation is what I like least about sage. It's 
annoying that quite a lot of "basic" things need to be implemented and that 
others have been done badly. I have fixed the things that I really need, or 
worked around them. The responsiveness of sage-devel and sage-combinat is 
nice.

I switched to sage because it is the best platform that I found. Sure, many 
things could be better, but I don't like gap4, magma, malple, mathematica, 
matlab, C, ... In spite of its many warts and problems I do like writing in 
python and working with sage. Using sage, I have been able to compute 
things much more quickly and painless than before when I was writing in 
gap. I'm happy with that.

Does anyone have any *concrete suggestions* for how we could improve the 
"development model"? There is definitely room for improvement but short of 
paying someone I don't have any good suggestions. The problem is that what 
I want implemented is often different to what everyone else wants, but 
thankfully there is some overlap and so some give and take. Ideas anyone?

Andrew

-- 
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/-/eSgox25xV_cJ.
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: Permutations... again.

[Nathann Cohen]

Nicolas, I know you respect his job very much and I have nothing against
Mike Hansen of course.  But these days I have been using Posets and
Permutations a bit, and with Florent we found several problems already, and
I am pretty sure you know muuuch more of them.

This thing with the permutations. The problem with Facade = False by
default on Posets, see
https://groups.google.com/forum/?fromgroups=#!topic/sage-combinat-devel/bfWbG54sedM

There is also that bug about memory usage, 10 days ago :
https://groups.google.com/forum/?fromgroups=#!topic/sage-combinat-devel/AdErcxGPq4c

And there is also that THE INEQUALITY FOR POSETS IS BROKEN, because of
"some thing you needed to add inside to have your computations go faster"
(Poset inequality is only True if the cached linear extensions coincide),
and "that cannot be easily changed because the code of a lot of people in
Sage-combinat would be too slow otherwise".

And none of these things ever get solved. What I have a hard time accepting
is that you do not feel such things as dangerous, and bad, and the need to
fix them quickly. These bugs have been reported and nobody who uses these
classes everyday feels like fixing them. And the bug stays. Mike's work is
all very nice, but it was 5 years ago. The code should have been rewritten
since just by fixing things, step by step, as the bugs appeared.

I have a very hard time accepting your development model. This
Sage-combinat thing. The first time you told me about it, I think it was at
the CIRM, you told me that "The goal was early integration". Ok, I can see
a point to that (actually I don't, but I accept that you may, and hence I
accept that answer), but look at all the problems it creates :
* To me, Sage-combinat is a *FORK* of Sage. Because you work on
Sage-combinat, and hence do not feel necessary to contribute to Sage,
because if a thing is fixed in Sage-combinat you do not have a problem with
it anymore. It's a fork.
* You have "users", whom I call customers. I call them customers because
you do a crazy amount of work for them (rebasing this damn patch queue)
with the excuse that you cannot expect them to *UPDATE* their version of
Sage by themselves. You told me several times that a patch could not be
written because it would mess up with their code, or with its speed. Now
you said that we cannot switch to GIT unless the Sage-combinat queue can be
transferred to GIT too. Hell !
* You have one thousand patches there that are dying there. Last year I
spent several days during the Sage Days in Cernay just trying to help write
the documentation of one patch. Where is that patch ? Still in the combinat
queue ? Same thing with Florent's patch on SearchForest. This is good code
but I can already see how it goes : he works again on the code, improves
that and that, and even though I tried to help him with the documentation I
do not see the patch being submitted anytime soon. What is actually wrong,
since he can already use it himself in Sage ?

This is a bad developpement model. I mean, I can show two big problems
(broken equality for posets, and this awful Facade thing) that you
explicitely told me cannot be fixed because of the Combinat guys. You
produce patches and do not write the documentation, because you do not have
to, because your development model is "put whatever you want in the
combinat queue, and you don't have to write a clean Sage patch because you
can use it already like that".

That's how I fix bugs in graphs : I write a patch, send it to the TRAC
server, and forget about it until somebody comes to review it. Then I can
totally forget about that bug. How do you propose we do the same with the
constraints of Sage-combinat ? I saw three bugs, and all three have to be
fixed.
No problem with Mike's code. But not fixing bugs that you know exist is
actual bad work.

Some answers to points you raised in your post :

> Granted, the refactoring of all this code is frustratingly long. But
> there are a *lot* of efforts going on and things are progressing, one
> step at a time (thanks everybody for that!). This will eventually get
done.

5 years. Look at it. This was done 5 years ago. It has not been fixed.
Let's be honest : it will NEVER be fixed. Not this way. Not by just waiting
for it to happen.

> And we should *not* remove that code in the meantime, because, as
> crappy as it is, it still serves its purpose in waiting for something
> better.  If you want to add big fat warnings and some sanity checks,
> sure go ahead.

I like to play the dumb guy, and I love stupid methods like this one. And
there is a big advantage to this method : if you remove it and everything
breaks, the code will be replaced in no time. That's for sure, because
everybody needs it. But for as long as you have a bad code, and because you
don't feel the need to rewrite it, nothing happens.

> But please be kind and unobtrusive to those who wrote
> it and those who are working hard to improve it.

Nicolas Honestly... I run code on