Re: [sage-combinat-devel] Sage Days 64

[Paul-Olivier Dehaye]

Dear Anne,

>>> 2^6
4

Sincerely,
Paul


Paul-Olivier Dehaye
SNF Assistant Professor of Mathematics
University of Zurich
http://user.math.uzh.ch/dehaye/contact_info.txt

On Wed, Sep 10, 2014 at 2:42 AM, Anne Schilling 
wrote:

> Dear All!
>
> Dan Bump, Travis Scrimshaw and I are going to organize Sage Days 64 (=2^6
> !!)
> at UC Davis March 17-20, 2015. A preliminary website can be found here
>
> http://wiki.sagemath.org/days64
>
> If you are interested in participating, please sign up on the wiki or
> drop us a line!
>
> Hope to see you there,
>
> Anne, Dan, 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: H2020: Mathematics and Digital Science

[Paul-Olivier Dehaye]

Well, I agree that this should be a priority, but you don't know that it
won't happen. This online discussion is set up by Europe to decide on the
topic of a workshop that will take place on 6/7 November. Once the topics
are decided, the main goal in the workshop itself will be to decide on
funding priorities for the 2016/2017 instruments (i.e. this can be seen
partly as a lobbying event). The process is long, sure, but it is also very
incremental. At the moment it costs almost nothing to participate: open an
account and post. If open source math software makes it, then all you would
have to decide to keep engaged in the process is if attending that workshop
(with like-minded people, presumably) would be of interest to you. From my
understanding this is how semi-industrial projects get started: before
calls are actually issued.
Paul

I copy/paste below the original context for the consultation:

DG CONNECT of the European Commission, more precisely the Unit
e-infrastructures in Directorate Excellence in Science in DG CONNECT, has
launched a “consultation†on mathematics. The aim is to give input for a
workshop on mathematics and for its main focus areas. This Workshop will
probably take place on 6 and/or 7 November. It will in turn feed into the
WP2016-2017 especially in the area of Excellence in Science.

This below is the link to the “consultation†or rather a discussion
forum. The idea is indeed to find first focus for the workshop and the
whole mathematical discussion. As such, mathematics is too wide a topic,
and a workshop on “mathematics†would have the risk of becoming too
generic and too overarching even if focusing on einfrastructures, and end
up in everyone agreeing that mathematics is important and going no further.

We would be very grateful to have wide input from mathematicians and
like-minded people in the “consultation†, and  as such in forming the
actual contents of the workshop. Accordingly, I would like to invite all to
participate in the consultation and to forward the link and information to
colleagues working with, on or for mathematics and ICT. Thanking in advance
– we will come back to the workshop.


Paul-Olivier Dehaye
SNF Assistant Professor of Mathematics
University of Zurich
http://user.math.uzh.ch/dehaye/contact_info.txt


On Wed, Aug 20, 2014 at 12:45 PM, Harald Schilly 
wrote:

>
>
> On Wednesday, August 20, 2014 12:34:58 PM UTC+2, Paul-Olivier Dehaye wrote:
>>
>> This might be of interest to the sage communities
>> https://ec.europa.eu/digital-agenda/en/node/72901/subscribe
>>
>>
> What I would really like them to do is to even more strengthen their bias
> towards "openess". They advocate open data, and in H2020 also open access …
> what's missing is open software: you not only have to publish all your
> code, but it must only depend on open source libraries (if not, explain in
> advance why not). It's not going to  happen, but I can have my wishes ;-)
>
> -- H
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

[sage-combinat-devel] H2020: Mathematics and Digital Science

[Paul-Olivier Dehaye]

This might be of interest to the sage communities
https://ec.europa.eu/digital-agenda/en/node/72901/subscribe

Paul-Olivier Dehaye
SNF Assistant Professor of Mathematics
University of Zurich
http://user.math.uzh.ch/dehaye/contact_info.txt

-- 
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/d/optout.

Re: [sage-combinat-devel] Talk

[Paul-Olivier Dehaye]

bravo!

Paul-Olivier Dehaye
SNF Assistant Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
twitter: massiveteaching
freenode irc: pdehaye


On Thu, Jul 10, 2014 at 11:13 PM, Viviane Pons 
wrote:

> Hi everyone,
>
> I gave a 5 minutes lighting talk yesterday at SciPy on "Experimental pure
> mathematics with sage" and it was quite a success!
>
> You can watch it here:
>
>
> https://www.youtube.com/watch?v=SMyto7WHiNs&list=PLYx7XA2nY5GfuhCvStxgbynFNrxr3VFog
>
> (at 30:20)
>
> I intend to make it a long talk for next PyCon, suggestions are welcome!
>
> Cheers,
>
> Viviane
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-devel] Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

Yes, that is my point. I just mentioned this as a quick way to show a
plain, clear and direct use case. I didn't want to pick a more exciting and
speculative one.
Paul

Paul-Olivier Dehaye
SNF Assistant Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Fri, May 30, 2014 at 6:21 PM, Nicolas M. Thiery  wrote:

> On Thu, May 29, 2014 at 11:28:58PM +0200, Paul-Olivier Dehaye wrote:
> >"""
> >E.g. when a
> >  borderline feature is meaningful in the context of Sage, is useful
> >  for a sister project, but does not yet have a direct use case
> >  within Sage ...
> >"""
> >Correct me if I am wrong, off the top of my head:
> >Assuming "the findstat people" start adding information about which
> maps
> >are bijective, can't one automatically create new tests, testing two
> >methods at once?
> >Assuming "the findstat people" start adding information about the
> ranges
> >of maps, can't one automatically create new tests, testing that the
> output
> >of a method is what it should be? (e.g. no [5,4,2] that is supposed
> to be
> >a Partition but is in fact a list).
>
> I guess we could. I am not sure to see your point though. Is it that a
> potential direct use case within Sage would be to exploit this
> semantic information to do more automatic testing which in turn would
> contribute to make Sage more robust?
>
> 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 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/d/optout.
>

-- 
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/d/optout.

[sage-combinat-devel] Re: Project: add hundreds of contributors to sage

[Paul-Olivier Dehaye]

Just got a Github Education account today for my lab, which led me to look
a bit more at their site. This video is relevant:
https://education.github.com/stories#UCBerkeley

> If extra eyes were all that were necessary, there would be no
long-standing mathematical conjectures.
What is needed is both extra eyes and a community welcoming of new ideas.
That's what the polymath projects do, and they have been quite successful
so far, proving results that had vexed Fields medalists.

Paul


Paul-Olivier Dehaye
SNF Assistant Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Thu, May 29, 2014 at 11:34 AM, Paul-Olivier Dehaye <
paul-olivier.deh...@math.uzh.ch> wrote:

> Thanks for the thoughtful replies. It's a fine line between being critical
> of the idea and dismissive of the students. Please everyone limit
> yourselves to criticizing the idea, as students might come to this thread
> later.
> I don't think one should dismiss the students. Look at the Mathworks
> competition (another thing MATLAB does!), as it is described in Nielsen's
> book "Reinventing Dicovery". There is a history there of microcontributions
> on code leading to optimised code.
> There is also two assumptions in your emails:
> 1) that they will all have just learned python: the course might be just
> the right blend of mathematics and CS so that some participants actually a
> background in python. On top, one can modulate the difficulty progressively
> to make sure to attract some students who actually have a strong python
> background already (in MOOCs, there are always some experts lurking)
> 2) that I would let them choose the topic. Not so. For the specifics of
> how the course will be run, I need to bring the discussion out of the
> mailing list.
>
> As William points out, small contributions are important (example in
> docstring) and the process is currently suboptimal.
> I would add that other small contributions could be important, such as
> semantic information coming from professional mathematicians who have just
> learned utter basics of python, to have a mere sense of how the decorator
> they have just added will affect the method itself. For this, existing
> annotation tools suffice.
>
> Paul
>
> Paul-Olivier Dehaye
> SNF Professor of Mathematics
> University of Zurich
> skype: lokami_lokami (preferred)
> phone: +41 76 407 57 96
> chat: pauloliv...@gmail.com
> twitter: podehaye
> freenode irc: pdehaye
>
>
> On Thu, May 29, 2014 at 3:40 AM, rjf  wrote:
>
>>
>>
>> On Wednesday, May 28, 2014 3:31:08 PM UTC-7, Paul-Olivier Dehaye wrote:
>>>
>>> Again, in the big wave of emails, this one also got misdirected:
>>>
>>> Hi everyone,
>>>
>>> I am looking for people who want to help me, in one way or another, bring
>>> hundreds of new first time contributors to sage. If I do not find enough
>>> partners, I will look for other more suitable python-based projects.
>>>
>>> The idea would be quite simple: teach python programming around some
>>> mathematics (such as combinatorics) and simultaneously produce code that
>>> would be useful for research and worth including in sage. Two catches:
>>> students are given individual problems to work on, and the course is
>>> taught
>>> on Coursera. Motivation for the students would come in various ways:
>>> internships, for instance. Quality of the code would be ensured by
>>> peer-testing the programs.
>>>
>>
>> William Stein has already responded to the major issues regarding the
>> Sage development process, but I would just like to comment on this
>> particular aspect of peer-testing.  Having two or more people who have
>> just learned python and do not know much mathematics "peer review"
>> code does not lead to much of an ensured  level of quality.
>> Certainly there are other clumps of python aggregating code that are not
>> as daunting as Sage.  Numpy and Sympy come to mind,  but I doubt
>> that they would really relish a MOOC's-worth of naive contributions, when
>> it is pretty much guaranteed that a very high percentage would, under
>> careful scrutiny, be duplicative, erroneous, poorly coded, or all three.
>>
>> It's a nice thought to get many hands to write code free.  But
>> impractical,
>> in spite of Eric Raymond's "Cathedral and Bazaar" essay.  "All bugs are
>> shallow
>> with enough eyes"  (or whatever the wording is...)  is perhaps plausible
>> if the system
>> is itself 

Re: [sage-devel] Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

There is definitely frustration on both "sides". My offer for you to come
and talk in Zurich is serious, it's easier to talk in person. We could even
invite you to a seminar to talk about mathematics. Then we go chill out
somewhere and we talk about sage.
Paul

Paul-Olivier Dehaye
SNF Assistant Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Thu, May 29, 2014 at 11:41 PM, Nathann Cohen wrote:

> Yo !
>
> > """
> > I don't even know what I think anymore. With the turn that events take, I
> > think I don't even need to think anymore. I think that I will think what
> you
> > think I think, it is much easier for me.
> > """
> > which is a very open minded attitude
>
>  and a jest, as I am sure you understood. I was answering a post which
> was partly about "what Nathann thinks", and I did not feel that I had
> anything important to contribute.
>
> > Nathann, I understand you don't know now what you think and respect that.
>
> I love knowing that I am respected for such effortless achievements.
>
> > But did you _really_ use to think that the Graph class was yours, in the
> > sense that you had veto rights on it? I am assuming that's the class you
> are
> > referring to.
>
>  I have veto rights on anything that anybody does even when I am not
> looking. Fortunately, nobody is forced to pay attention so it is not a
> problem.
>
> More seriously, this thing is open source, belongs to nobody, and there is
> rarely a month where I do not think "Okay I am tired of all this, I'll just
> stop working on Sage (or research) and do something useful with my life for
> a change" (last occurrence two days ago). Though you have to understand
> that I worked almost daily on this Graph class for the last 3-4 years. When
> I am not angry I care about what happens to it.
>
> Nathann
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

"""
E.g. when a
borderline feature is meaningful in the context of Sage, is useful
for a sister project, but does not yet have a direct use case
within Sage ...
"""
Correct me if I am wrong, off the top of my head:
Assuming "the findstat people" start adding information about which maps
are bijective, can't one automatically create new tests, testing two
methods at once?
Assuming "the findstat people" start adding information about the ranges of
maps, can't one automatically create new tests, testing that the output of
a method is what it should be? (e.g. no [5,4,2] that is supposed to be a
Partition but is in fact a list).
Paul


Paul-Olivier Dehaye
SNF Assistant Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Thu, May 29, 2014 at 11:21 PM, Nicolas M. Thiery <
nicolas.thi...@u-psud.fr> wrote:

> > On Thu, May 29, 2014 at 10:02 PM, Nathann Cohen  >
> > >   I can hear your frustration ... In similar situations, it helped me
> to
> > >   keep in mind that loud people are not always representative. Of
> course
> > >   the difficulty is to fetch the opinion from the others.
> >
> > Ahahahahahahah. Well, only including in Sage code that is useful to "a
> > Sage user" or "other developpers" does not seem that far-fetched. I
> > still do not see what the problem is with that.
> > Err Well, assuming the obvious : that I am the "loud people" you
> > mention.
>
> Sorry, I should have clearly separated the two topics. My point was
> about (1) below.
>
> (1) When a Sage developer believes in his heart that something is the
> right thing to do for Sage, (s)he should not get discouraged by
> loud opposition without first reaching for the opinions of a
> larger pool of developers.
>
> Btw: there are more than one loud people :-) Actually I also put
> myself in there, as the graded algebra with basis discussion from
> the other month shows ...
>
> (2) About ``only including in Sage code that is useful to "a Sage
> user" or "other developpers"''. In principle, yes, sure, I
> agree. Still there can be legitimate complementary point of views
> and discussions about where to put the limit. E.g. when a
> borderline feature is meaningful in the context of Sage, is useful
> for a sister project, but does not yet have a direct use case
> within Sage ...
>
> 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 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-devel] Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

To add on to what Viviane just said, the problem is also in using
vocabulary and words such as "our side" (a constant in Nathann's prose) or
"""
I don't even know what I think anymore. With the turn that events take, I
think I don't even need to think anymore. I think that I will think what
you think I think, it is much easier for me.
"""
which is a very open minded attitude, followed by
"""
Yep. I also defended that "respecting other people's code" also meant "not
adding method to the classes they use if the method is not useful for
them". If it is only for internal stuff, a hidden (beginning with a '_'
works for everybody...). But that was a long time ago and I gave up on
#16403.
"""
(in
https://groups.google.com/d/msg/sage-combinat-devel/QRUXmy6UZVo/ABg8CtDzQukJ)
which looks rather closed minded (but I am not sure I fully understood).

Nathann, I understand you don't know now what you think and respect that.
But did you _really_ use to think that the Graph class was yours, in the
sense that you had veto rights on it? I am assuming that's the class you
are referring to.

Paul



Paul-Olivier Dehaye
SNF Assistant Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Thu, May 29, 2014 at 10:51 PM, Viviane Pons wrote:

> I actually do think it would be a really good thing to have a statfinder
> within sage, and somehow merge findstat code with sage code. It would
> benefit both sage and findstat users. At the end, both FindStat and Sage
> have the same aim: using computers to help us doing research. I understand
> completely that it should have no impact on performance for other people
> (but it is true for every code someone adds...) but I do not understand the
> "it is useful only for FindStat users so it is not useful". Anyway, this
> not going to happen in the near future, I mostly see this as long term
> objective and it is only my opinion.
>
> The short term perspectives is for "us FindStat people" to build a
> FindStat API that would allow query from external websites. It does not
> seem that complicated, it's mostly a question of taking the time to do it.
> Once we have that, we can start thinking of more integration, local
> computation, etc.
>
>
> 2014-05-29 22:35 GMT+02:00 John Cremona :
>
>> On 29 May 2014 21:02, Nathann Cohen  wrote:
>> >> > BUT: this would result in code in Sage that is not useful purely
>> >> > within Sage. And there are people, loud people, that say there should
>> >> > not be such code in Sage.
>>
>> I do not know what is "code in Sage that is not useful purely within
>> Sage".
>>
>> John
>>
>> >>
>> >> I can hear your frustration ... In similar situations, it helped me to
>> >> keep in mind that loud people are not always representative. Of course
>> >> the difficulty is to fetch the opinion from the others.
>> >
>> >
>> > Ahahahahahahah. Well, only including in Sage code that is useful to "a
>> Sage
>> > user" or "other developpers" does not seem that far-fetched. I still do
>> not
>> > see what the problem is with that.
>> >
>> > Err Well, assuming the obvious : that I am the "loud people" you
>> > mention.
>> >
>> > Nathann
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "sage-devel" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to sage-devel+unsubscr...@googlegroups.com.
>> > To post to this group, send email to sage-de...@googlegroups.com.
>> > Visit this group at http://groups.google.com/group/sage-devel.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-devel" group.
>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sage-devel+unsubscr...@googlegroups.com.
>> To post to this group, send email to sage-de...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/sage-devel.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "sage-combinat-devel" group.
> To unsubscribe from this group and stop

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

+1 for subtlety!

Paul-Olivier Dehaye
SNF Assistant Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Thu, May 29, 2014 at 10:15 PM, Nathann Cohen wrote:

> > I might be too, I am not quite sure!
>
> If so, I would be ashamed to steal the spotlights. The place is yours.
>
> Nathann
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

I might be too, I am not quite sure!
Paul

Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Thu, May 29, 2014 at 10:02 PM, Nathann Cohen wrote:

> > BUT: this would result in code in Sage that is not useful purely
>> > within Sage. And there are people, loud people, that say there should
>> > not be such code in Sage.
>>
>> I can hear your frustration ... In similar situations, it helped me to
>> keep in mind that loud people are not always representative. Of course
>> the difficulty is to fetch the opinion from the others.
>>
>
> Ahahahahahahah. Well, only including in Sage code that is useful to "a
> Sage user" or "other developpers" does not seem that far-fetched. I still
> do not see what the problem is with that.
>
> Err Well, assuming the obvious : that I am the "loud people" you
> mention.
>
> Nathann
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

[sage-combinat-devel] Re: Project: add hundreds of contributors to sage

[Paul-Olivier Dehaye]

Thanks for the thoughtful replies. It's a fine line between being critical
of the idea and dismissive of the students. Please everyone limit
yourselves to criticizing the idea, as students might come to this thread
later.
I don't think one should dismiss the students. Look at the Mathworks
competition (another thing MATLAB does!), as it is described in Nielsen's
book "Reinventing Dicovery". There is a history there of microcontributions
on code leading to optimised code.
There is also two assumptions in your emails:
1) that they will all have just learned python: the course might be just
the right blend of mathematics and CS so that some participants actually a
background in python. On top, one can modulate the difficulty progressively
to make sure to attract some students who actually have a strong python
background already (in MOOCs, there are always some experts lurking)
2) that I would let them choose the topic. Not so. For the specifics of how
the course will be run, I need to bring the discussion out of the mailing
list.

As William points out, small contributions are important (example in
docstring) and the process is currently suboptimal.
I would add that other small contributions could be important, such as
semantic information coming from professional mathematicians who have just
learned utter basics of python, to have a mere sense of how the decorator
they have just added will affect the method itself. For this, existing
annotation tools suffice.

Paul

Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Thu, May 29, 2014 at 3:40 AM, rjf  wrote:

>
>
> On Wednesday, May 28, 2014 3:31:08 PM UTC-7, Paul-Olivier Dehaye wrote:
>>
>> Again, in the big wave of emails, this one also got misdirected:
>>
>> Hi everyone,
>>
>> I am looking for people who want to help me, in one way or another, bring
>> hundreds of new first time contributors to sage. If I do not find enough
>> partners, I will look for other more suitable python-based projects.
>>
>> The idea would be quite simple: teach python programming around some
>> mathematics (such as combinatorics) and simultaneously produce code that
>> would be useful for research and worth including in sage. Two catches:
>> students are given individual problems to work on, and the course is
>> taught
>> on Coursera. Motivation for the students would come in various ways:
>> internships, for instance. Quality of the code would be ensured by
>> peer-testing the programs.
>>
>
> William Stein has already responded to the major issues regarding the
> Sage development process, but I would just like to comment on this
> particular aspect of peer-testing.  Having two or more people who have
> just learned python and do not know much mathematics "peer review"
> code does not lead to much of an ensured  level of quality.
> Certainly there are other clumps of python aggregating code that are not
> as daunting as Sage.  Numpy and Sympy come to mind,  but I doubt
> that they would really relish a MOOC's-worth of naive contributions, when
> it is pretty much guaranteed that a very high percentage would, under
> careful scrutiny, be duplicative, erroneous, poorly coded, or all three.
>
> It's a nice thought to get many hands to write code free.  But impractical,
> in spite of Eric Raymond's "Cathedral and Bazaar" essay.  "All bugs are
> shallow
> with enough eyes"  (or whatever the wording is...)  is perhaps plausible
> if the system
> is itself shallow (like linux).
> Where I differ with Raymond is I think there are not enough eyes on the
> planet to make some
> bugs shallow in a "deep" system-- one that does (say) sophisticated
> symbolic mathematics.
> If extra eyes were all that were necessary, there would be no
> long-standing mathematical
> conjectures.
>
>
>
>
>> If you do not know what Coursera or MOOCs are, you are welcome to take my
>> upcoming course
>> https://class.coursera.org/massiveteaching-001
>>
>> If you are interested to play with a MOOC platform yourself, you might
>> want
>> first to watch the videostream of the 2pm-3pm slot of this conference I am
>> co-organising on Tuesday:
>> tinyurl.com/openedx-zurich
>> as it will help you assess the technical challenges.
>>
>> I am looking at a start date for the course of around October-November,
>> and
>> to bring the discussion off the mailing list (to private) so as to keep an
>> element of surprise for the students.
>>
>> Let me know!
>>
>> Paul
>>
>> Paul-

Re: [sage-combinat-devel] Diversity to foster sage development

[Paul-Olivier Dehaye]

Out of my confused state after a long day:
I think I still want sage to be a " free open source alternative ", and its
primary audience to be typical users of the Ma's. But the Ma's have indeed
evolved since 2005. Maybe it might be worth, as a start, listing how they
have changed? The goal of the exercise would not be to copycat what they
do, but maybe to understand how the Ma's pipelines work now.
Paul

Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Thu, May 29, 2014 at 12:36 AM, William Stein  wrote:

> On Wed, May 28, 2014 at 3:29 PM, Paul-Olivier Dehaye
>  wrote:
> > In the big wave of emails exchanged today, I sent this one, by accident
> to
> > the wrong mailing list. I recopy it below:
> >
> > When I went to pycon, the most important thing I learned is the
> importance
> > of a diverse community for the development of python. This I learned from
> > the top, the board of the Python Software Foundation (cf. Lindberg's
> > keynote at pycon, for instance), and saw in action absolutely everywhere.
> >
> > This diversity is to be understood in a very broad sense:
> > - diversity of origins,
> > - diversity of genders,
> > - diversity of lifestyles,
> > - diversity of professional activities,
> > - ...
> >
> > I can egocentrically agree with the PSF on the fourth: the fact that
> python
> > is tied to so many different fields, ranging from professional software
> > development world to all kinds of scientific disciplines, is a major
> > selling point for many people. This was the case for me (and William),
> > coming from a world of special purpose mathematical software. Relying on
> a
> > mature language with a diverse ecosystem encourages a wider array of
> > contribution to sage. I will posit that a similar motivator was present
> for
> > many of us who come with previous experience in other languages.
> >
> > If your software community is not inclusive, you will reject individual
> > contributions that might be very interesting (and remain unaware of it),
> > and that pattern will lead to larger collaborations having a hard time
> > working at the periphery of the core project. This will decrease the
> chance
> > of the core project recruiting new contributors. And we are talking about
> > highly qualified contributions here, contributions that the sage project
> > really does not want to end in Magma first. For instance, pick the LMFDB
> or
> > findstat. How much of their code is written tiptoeing around sage itself,
> > and if you make an objective assessment should fit better in sage than in
> > their project? Bear in mind that the software was developed itself
> already
> > tiptoeing around sage's core community (which might be unfair, because a
> > community's tone is often defined by just a few individuals who speak
> > louder).
> >
> > You might ask how origin, genders, lifestyles come in play here. Well,
> > being inclusive starts simply by being curteous and making people feel at
> > ease, and in some particular circumstances being "explicit is better than
> > implicit". It might very well be that a queer person finds the python
> > community very welcoming (based on objective facts such that one out of
> > five tracks at pycon was aimed at promoting diversity in the community,
> or
> > the diversity of the speakers), that she wants to contribute back, so
> much
> > so that she decides to organize a python education summit, where
> educators
> > of students of all backgrounds and ages can share tips on how to build a
> > python pipeline together, one that takes anyone between the age of 5 to
> the
> > age of whatever and turns them into a competent enough programmer that
> the
> > community is better off from it. Somehow it all works for the better,
> > because you have to trust individuals that if they like a project they
> will
> > contribute to it in a positive way, with their own creativity.
> >
> > This pipeline exists, and is actively fostered by the Python Software
> > Foundation as one of the most important assets of the python ecosystem.
> > Contrast the shortsightedness of the academic community wrt the leaky
> > pipeline for instance, with the attitude of the PSF described here. There
> > is no comparison.
> >
> > At the same time, my reflections since pycon have led me to understand
> that
> > it would make sense for things to develop the way they have so far. The
>

[sage-combinat-devel] Project: add hundreds of contributors to sage

[Paul-Olivier Dehaye]

Again, in the big wave of emails, this one also got misdirected:

Hi everyone,

I am looking for people who want to help me, in one way or another, bring
hundreds of new first time contributors to sage. If I do not find enough
partners, I will look for other more suitable python-based projects.

The idea would be quite simple: teach python programming around some
mathematics (such as combinatorics) and simultaneously produce code that
would be useful for research and worth including in sage. Two catches:
students are given individual problems to work on, and the course is taught
on Coursera. Motivation for the students would come in various ways:
internships, for instance. Quality of the code would be ensured by
peer-testing the programs.

If you do not know what Coursera or MOOCs are, you are welcome to take my
upcoming course
https://class.coursera.org/massiveteaching-001

If you are interested to play with a MOOC platform yourself, you might want
first to watch the videostream of the 2pm-3pm slot of this conference I am
co-organising on Tuesday:
tinyurl.com/openedx-zurich
as it will help you assess the technical challenges.

I am looking at a start date for the course of around October-November, and
to bring the discussion off the mailing list (to private) so as to keep an
element of surprise for the students.

Let me know!

Paul

Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye

-- 
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/d/optout.

[sage-combinat-devel] Diversity to foster sage development

[Paul-Olivier Dehaye]

ge CAS software companies. Look at all
the outreach efforts that have "Wolfram" in their name. I am not saying
that the sage core community should develop a copy of the whole Wolfram
ecosystem. What I am advocating is to understand that beyond sage there is
a wider ecosystem of people who are devoted to goals around sage (LMFDB,
sage-combinat, findstat, sagemathcloud, the failed sage-explorer,...),
possibly different from yours but that active mutual cooperation would be
beneficial. While 90% of the code of these projects will not belong to
sage, it is important that their extension points do sit in the code and
are thought through, because these extension points welcome creativity and
other innovators to build cool stuff on top of sage, and make it easier for
the core contributors to help them too, with epsilon additional effort.

Finally, for the specific context of how successful mathematical
communities work together, I would advise anyone to read papers by Ursula
Martin and her coauthors.


Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

I think an argument that this function is badly named is very sensible.
Maybe a better name would be "to_component_sizes". Why not just try
changing the name, and see how much work that is for the findstat group to
adapt. It might be that this does not want to be named, after all, and that
simply an unnamed method needs to be registered.

Do you feel that you own the class "Graph"? And get to decide what is
interesting and what is not relating to Graphs? If so, then indeed there is
a problem. What bothers you particularly? To see those methods in the code?
To see it appear when you press ? Clarifying that part would help
making everyone happy.

Paul


On Wed, May 28, 2014 at 9:52 PM, Nathann Cohen wrote:

> Yo !
>
> > Currently that ticket's description is in complete
> > contradiction to what you seem to describe on the mailing list (which
> seems
> > more sensible to me). In particular the title of the ticket is "Rename"
> > while the last line says "remove".
>
> Not my doing. When I posted my last comment on this ticket I set it to
> "positive_review" and "wontfix" because I gave up. I cannot do anything
> against a reviewer like you.
> Afterwards Ralf changed some stuff, then you set the ticket to
> needs_review, then it was set to needs_work by somebody else. Honestly it
> is not my ticket anymore, do what you want with it.
>
> About the difference you see between my ticket, which said "remove the
> function" and what I said here in my previous post :
> I had not noticed before that having a hidden function was actually a nice
> middle-ground. You can create functions "for semantics only" if it is
> useful, but this is an "internal mechanism" of Sage. If you need a function
> which transforms a Graph into a partition of integer to this end it is
> good, and you can name it Graph._to_partition if you like, but
> Graph.to_partition means that the function is unclear and not something
> users should see. And even if a better name is to be found, I would still
> claim that this function is really not useful to users (though it may be
> useful for the databases you want to build), and as such has nothing to do
> in the (already quite crowded) list of graph functions.
>
> So, yeah. Basically, I had not noticed that having a hidden function with
> a decorator on it (named to_partition if needed) was a good middle ground.
>
> > As long as this is the case, Nathann's arguments are incoherent and
> > contradictory, and any conversation on the list will turn in circles.
> >
> > My summary assessment so far is that Nathann is wrong, the
> implementation by
> > findstat of their ideas is poor, and the burden is on all of us to
> improve
> > it, particularly those who care the most. That's the way sage development
> > works, as far as I understand it. Maybe I will be swayed by good
> arguments
> > from Nathann, who has opened the ticket. I am genuinely keeping an open
> mind
> > about implementation. I want him to improve what's there, not remove, if
> he
> > cares enough.
>
> Whatever.
>
> Nathann
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

At some point we will need a summary, or to use something better than
mailing lists to discuss this.
Paul

Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Wed, May 28, 2014 at 9:46 PM, Paul-Olivier Dehaye <
paul-olivier.deh...@math.uzh.ch> wrote:

> >  - Nathann is arguing that no empty methods/classes should be present.
> I think he is, and add Vincent too (cf. previous email of his).
>
> Absolutely noone wants unefficient code. If there is a clear way to
> improve, let's do it. But burden is on all of us.
>
> To be clear, I want to have this semantic information in the code.
>
> There are many reasons for this, here is one more: it provides an
> intermediate step for a person joining sage between a typo fix and
> implementing their first function, welcoming microcontributions. I think
> decorators would be very suitable for this, but am open to alternate
> suggestions.
>
> > Would this be a short-term solution?
> Sure!
>
> Paul
>
>
>
>
>
> Paul-Olivier Dehaye
> SNF Professor of Mathematics
> University of Zurich
> skype: lokami_lokami (preferred)
> phone: +41 76 407 57 96
> chat: pauloliv...@gmail.com
> twitter: podehaye
> freenode irc: pdehaye
>
>
> On Wed, May 28, 2014 at 8:47 PM, Simon King wrote:
>
>> Hi Paul,
>>
>> On 2014-05-28, Paul-Olivier Dehaye 
>> wrote:
>> > Two comments:
>> >  - Nathann is arguing that no empty methods/classes should be present.
>>
>> Is he? Sorry, then this is a point where Nathann and I do not agree. I
>> find abstract methods useful. I thought that his main point was: Don't
>> be intrusive! Do not make code of some people slower just because other
>> people care about the mathematical properties of some methods. And from
>> my perspective, the discussion is (or should be) only about the
>> question: How to care about the mathematical properties without slowing
>> down other peoples code.
>>
>> >  - They are not building a database. They are putting tags in the code
>> that
>> > allow them at runtime to build something that amounts to a database.
>> It's
>> > not that different to the category framework in some way, which is
>> encoding
>> > a lot of data via code constructions
>>
>> There was in fact some discussion at #10963 about the question whether it
>> is
>> a good idea that the new category-with-axiom framework encodes a
>> fully-grown
>> would-be-database (by this, I mean something that amounts to a database)
>> by
>> purely local data and naming conventions.
>>
>> I'd say: If they are putting tags in the code then they *do* create a
>> (would-be-)database, whether they want it or not.
>>
>> > I am not arguing that what findstat does with a decorator is the best. A
>> > flagged decorator that does nothing most of the time is better than what
>> > they do. But a full-on database is, as a short term solution, heading in
>> > the wrong direction.
>>
>> Do I understand correctly: You would not like that the
>> @combinatorial_map decorator constructs a database at startup time? I
>> think that's a valid concern.
>>
>> We could try to be clever and introduce an environment variable (or
>> commandline argument) such that @combinatorial_map creates a database
>> when this variable is set, and otherwise does nothing at all.
>>
>> Hence, people who care about the implicit would-be-database encoded in
>> the flags could obtain them by explicit request, and all other people
>> would not be affected at all.
>>
>> Would this be a short-term solution? Also from Nathann's perspective?
>>
>> 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/d/optout.
>>
>
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

>  - Nathann is arguing that no empty methods/classes should be present.
I think he is, and add Vincent too (cf. previous email of his).

Absolutely noone wants unefficient code. If there is a clear way to
improve, let's do it. But burden is on all of us.

To be clear, I want to have this semantic information in the code.

There are many reasons for this, here is one more: it provides an
intermediate step for a person joining sage between a typo fix and
implementing their first function, welcoming microcontributions. I think
decorators would be very suitable for this, but am open to alternate
suggestions.

> Would this be a short-term solution?
Sure!

Paul





Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Wed, May 28, 2014 at 8:47 PM, Simon King  wrote:

> Hi Paul,
>
> On 2014-05-28, Paul-Olivier Dehaye 
> wrote:
> > Two comments:
> >  - Nathann is arguing that no empty methods/classes should be present.
>
> Is he? Sorry, then this is a point where Nathann and I do not agree. I
> find abstract methods useful. I thought that his main point was: Don't
> be intrusive! Do not make code of some people slower just because other
> people care about the mathematical properties of some methods. And from
> my perspective, the discussion is (or should be) only about the
> question: How to care about the mathematical properties without slowing
> down other peoples code.
>
> >  - They are not building a database. They are putting tags in the code
> that
> > allow them at runtime to build something that amounts to a database. It's
> > not that different to the category framework in some way, which is
> encoding
> > a lot of data via code constructions
>
> There was in fact some discussion at #10963 about the question whether it
> is
> a good idea that the new category-with-axiom framework encodes a
> fully-grown
> would-be-database (by this, I mean something that amounts to a database) by
> purely local data and naming conventions.
>
> I'd say: If they are putting tags in the code then they *do* create a
> (would-be-)database, whether they want it or not.
>
> > I am not arguing that what findstat does with a decorator is the best. A
> > flagged decorator that does nothing most of the time is better than what
> > they do. But a full-on database is, as a short term solution, heading in
> > the wrong direction.
>
> Do I understand correctly: You would not like that the
> @combinatorial_map decorator constructs a database at startup time? I
> think that's a valid concern.
>
> We could try to be clever and introduce an environment variable (or
> commandline argument) such that @combinatorial_map creates a database
> when this variable is set, and otherwise does nothing at all.
>
> Hence, people who care about the implicit would-be-database encoded in
> the flags could obtain them by explicit request, and all other people
> would not be affected at all.
>
> Would this be a short-term solution? Also from Nathann's perspective?
>
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

@Nathann, Simon:

There is certainly a lot of misunderstandings between all of us. Both ways.
The discussion was started because of a suggestion, turned into a ticket
written by Nathann. Currently that ticket's description is in complete
contradiction to what you seem to describe on the mailing list (which seems
more sensible to me). In particular the title of the ticket is "Rename"
while the last line says "remove".

As long as this is the case, Nathann's arguments are incoherent and
contradictory, and any conversation on the list will turn in circles.

My summary assessment so far is that Nathann is wrong, the implementation
by findstat of their ideas is poor, and the burden is on all of us to
improve it, particularly those who care the most. That's the way sage
development works, as far as I understand it. Maybe I will be swayed by
good arguments from Nathann, who has opened the ticket. I am genuinely
keeping an open mind about implementation. I want him to improve what's
there, not remove, if he cares enough.

Paul


Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Wed, May 28, 2014 at 7:00 PM, Nathann Cohen wrote:

> Yo !
>
> > I agree 100% with your summary, Simon, except that
> > 1) Nathann will have to say himself whether he agrees or not;
>
> I think that the first time I said it was on the 20/6/2013 (one year ago):
>
> https://groups.google.com/d/msg/sage-devel/SnPfidRM9j8/u7f4X-cLlrsJ
> Quote : "Well, just returning the function as it is while registering the
> decorator's information somewhere seems to be nice. The decorator could
> even add some information to the docstring so that this information would
> automatically appear in the doc !"
>
> Then, I repeated it (same day one year ago)
> https://groups.google.com/d/msg/sage-devel/SnPfidRM9j8/4LbWLMBf-2kJ
>
> I added yesterday a link toward the link above :
> https://groups.google.com/d/msg/sage-devel/QRUXmy6UZVo/wiEpg-eCnYAJ
>
> Which was right after mentionning this idea again :
> https://groups.google.com/d/msg/sage-devel/QRUXmy6UZVo/BJ0WMYjmKJ0J
>
> I mean...
> I don't know
> Yeah... I am pretty sure that I did my job and that I mentionned the
> idea. What more can I do ?
>
> Nathann
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

Hi Vincent

The wikipedia definition of flaming has the words "hostile" and
"insulting". I have certainly been hostile towards Nathann, and have
explicitly explained to him early on why he was wrong and why I was being
hostile. It is part of academic discourse to have heated discussions,
because we are always exploring new ideas. I was hoping this would have put
some sense into him and made sure to hold my ground, rather than letting
the issue drop as I have done in previous discussions. His reactions have
only confirmed that I was on the right track to deal with him: he has never
asked for references, doesn't seem to have looked at those I pointed out,
and eventually insulted me. This is completely unprofessional behaviour. I
even tried to offer to discuss this in private to prevent him further
harming himself. So in summary, I have been hostile and he was both hostile
and insulting.

If you feel that I have been insulting somewhere, PLEASE point me to where,
I will look and immediately apologise if I agree with you.

I will concede that I was waiting for the right moment to jump in on the
mailing list, and that this was planned. Maybe some might be shocked at
this, but again it fits in a larger context that spans at least a couple
years. Again, that's a fair tactic for academics.

This is concerning my attitude towards Nathann. Towards you, I very much
hope I wasn't insulting or hostile (but it is hard to pin down Nathann's
arguments, it is a moving target, so you might have felt associated to some
of the hostility). Your attitude has only been constructive, and in fact
early on I suggested we keep the positivity to your thread. Let me
blanket-apologise if I have insulted or been hostile to you. That was
absolutely not my intent, quite the opposite.

Of course, it is unpleasant for everyone, I am also sorry for that. But
sometimes people need to be put in their place.

Now back to the "content".

I am asking Nathann's opinion because I don't want to go through the same
 again and again.

And, reading your 2) opinion, you disagree with Simon (but there I am
reading in an email he sent after yours).

Paul

Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Wed, May 28, 2014 at 6:56 PM, Vincent Delecroix <
20100.delecr...@gmail.com> wrote:

> Hi Paul,
>
> 2014-05-28 17:42 UTC+02:00, Paul-Olivier Dehaye
> :
> > I agree 100% with your summary, Simon, except that
> > 1) Nathann will have to say himself whether he agrees or not;
>
> Please at some point stop the flame.
>
> > 2) A decision should be made whether it is valid to introduce lots of
> empty
> > methods and classes simply for the semantic decorators that will be
> added.
>
> It is not. Could you give an example of what you are thinking about ?
> In my mind it would be seomthing like the natural injection ZZ ->
> QQ... but this is already there
> {{{
> sage: QQ.convert_map_from(ZZ)
> Natural morphism:
>   From: Integer Ring
>   To:   Rational Field
> }}}
> So there is no need to create an empty method .as_rational() on each
> integer. If you want a trivial function in your database then
> implement it as a Morphism. Or better as Simon said: put in the
> database what is needed to actually build the Morphism.
>
> Vincent
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

I agree 100% with your summary, Simon, except that
1) Nathann will have to say himself whether he agrees or not;
2) A decision should be made whether it is valid to introduce lots of empty
methods and classes simply for the semantic decorators that will be added.

Paul


Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Wed, May 28, 2014 at 5:32 PM, Simon King  wrote:

> Hi Paul,
>
> On 2014-05-28, Paul-Olivier Dehaye 
> wrote:
> > Christian's point is key. The absolute hardest problem to solve is where
> to
> > anchor semantic information so that others can contribute to it easily,
> > ...
> > Right now, by lack of a better place, it is put in sage.
>
> I think you miss the point of what Nathann and I try to say.
>
> I think Nathann agrees that it is a reasonable idea to have a
> @combinatorial_map
> decorator in front of a method (I do agree), provided that it gives useful
> information to some people (this is the case now), and provided that it
> does not have a negative impact for people who don't use this
> information---and currently it *does* have a negative impact, because of
> a slow-down in potentially time-critical methods.
>
> Last attempt before leaving office:
> - Currently we have a lose-lose situation: When people put
>   @combinatorial_map, then it has a negative impact to some other
>   people (the slow-down), and it is difficult to use the added information
>   for those who want to do proper queries.
> - We should better have a win-win situation: When people put
>   @combinatorial_map, then it should not change the method (to not
>   slow-down stuff), and the added information should be accessible to
>   queries in a reasonable way.
>
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

Two comments:
 - Nathann is arguing that no empty methods/classes should be present.
Which means to me that he doesn t see the value of semantic information in
itself
 - They are not building a database. They are putting tags in the code that
allow them at runtime to build something that amounts to a database. It's
not that different to the category framework in some way, which is encoding
a lot of data via code constructions (partially redundant work: cf
http://nforum.mathforge.org/discussion/2490/what-would-you-want-from-a-higher-categorical-database/#Item_0).
In any case, the way findstat does things, they have the potential to
construct a database. The point is that they allow me to reuse their work
to easily build my own database on top, that does something different.

I am not arguing that what findstat does with a decorator is the best. A
flagged decorator that does nothing most of the time is better than what
they do. But a full-on database is, as a short term solution, heading in
the wrong direction.
Paul

Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Wed, May 28, 2014 at 5:23 PM, Simon King  wrote:

> Hi Christian,
>
> On 2014-05-28, Christian Stump  wrote:
> > But how am I then convincing
> > someone knowing that information to add that information there?
>
> Ask him/her to put @combinatorial_map in front of the method in
> question. In other words, there should be no need to change the interface
> for those who contribute combinatorial maps. What should change is how this
> contribution is processed. It should not be the case that, as a result,
> the overhead of calling a method increases!
>
> What I (an Nathann?) am trying to convince y'all: @combinatorial_map
> should not wrap a method into some class instance that serves as a proxy
> to the method and holds additional information purely locally. Instead,
> @combinatorial_map should communicate with a (local) database before
> returning the method *unwrapped*. And then, there should additionally
> be tools to use the local database together with a global one.
>
>
> > What I
> > like about a local system (preferably accompanying the code of the
> > very method) is that it makes it easy for the person having
> > information about a specific map to provide that information.
>
> To give you a drastic picture: Imagine you work for a company and want
> to keep track who is your customer. You suggest to attach a little tag
> to each customer, stating that (s)he is "happy customer of FooBar ltd.". It
> will then be very easy to test if a given person is your customer: Just
> look for the tag. And when you want to have a list of your customers in
> a given town: Just do an exhaustive search in that twon and check each
> person's tag!
>
> But I somehow feel that having a database keeping track of your
> customers would be better. And I do believe that tagging a method as
> "combinatorial map" locally is the same as tagging your customers
> locally. So, the picture applies.
>
> > Of course, that information must be organized to be searchable
> > properly. But I don't see a problem there beside conventional namings.
>
> Hang on. Do you suggest to implicitly create a database that relies on
> naming schemes??
>
> I think one can not deny: What y'all do with the @combinatorial_map *is*
> in fact creating a database---at least implicitly---, whether you want
> it or not. But explicitly is better than implicitly, and one should not
> re-invent the wheel. So...
>
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

Christian's point is key. The absolute hardest problem to solve is where to
anchor semantic information so that others can contribute to it easily,
because his project requires lots of microcontributions (cf. Nielsen's
Reinventing Discovery)
Right now, by lack of a better place, it is put in sage. According to me,
this is a sensible short term solution, step 1 if you want. Step 2 is that
the LMFDB starts to do the same thing putting semantic information on empty
classes and methods. Step 3 is that we find a better way, armed with two
use cases. I don't think we are ready to go to step 3 yet.
Paul

Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Wed, May 28, 2014 at 4:37 PM, Christian Stump
wrote:

> > Ceterum censeo: Please do not put too much semantic into an attribute of
> > the map. It will be a burden for the map, will cost memory, and will be
> > difficult to search.
>
> I would personally really like to get semantic information about maps
> implemented in Sage. This starts with automated concatenating maps,
> and does not even end with information about a map in the Journal of
> Applied Nonsense. I am sure you have reasons to vote for a centralized
> system where to store such information. But how am I then convincing
> someone knowing that information to add that information there? What I
> like about a local system (preferably accompanying the code of the
> very method) is that it makes it easy for the person having
> information about a specific map to provide that information.
>
> Of course, that information must be organized to be searchable
> properly. But I don't see a problem there beside conventional namings.
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

Vincent, I did read your email, which is very good. Thank you for posting.
Unfortunately it is too focused for my taste. I would like to solve the
generic problem of how to put in semantic information in sage first. Many
might say let's solve one problem first, but in my mind it is already three
times that this problem is appearing:
 - LMFDB
 - findstat
 - category framework
That's why people who were at Edinburgh were invited.

I am looking for a generic solution, and to help with this I have started
writing a document that is read only here:
https://etherpad.mozilla.org/ep/pad/view/ro.Gzkl7YR-2gG/latest
I am not writing this document at this exact moment, because I have a
pressing deadline until Sunday. I am willing to devote much more time for
this then. This is not an empty comment, in some ways my pressing deadline
of Sunday is because I am already working on this. My timing is slightly
affected, because in the back of my head I knew I just had to wait for the
next flare up of this discussion on the list to get another discussion
started, but this time backed up with concrete elements.
Anyone who would like to help me add constructive material to the document
is welcome to do so, just ask me for the link.

@Christian: a generic, better, query engine might be build outside of
findstat if the findstat group is too focused on their particular use case.
Believe me, findstat is as far as I can tell baby case compared to LMFDB.
But it has the merits of trying a more viable approach in my mind.
I certainly don't want to develop anything without explicitly telling
findstat about it.

Paul


Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Wed, May 28, 2014 at 11:54 AM, Vincent Delecroix <
20100.delecr...@gmail.com> wrote:

> Hi Christian,
>
> 2014-05-28 11:32 UTC+02:00, Christian Stump :
> >> It seems that actually nobody read my initial post on that thread... so
> >> let me repeat
> >
> > I did -- but didn't really have any qualified contribution...
> >
> >> But the semantic has to be implemented at the level of maps not at the
> >> level of methods.
> >
> > could you explain what you mean there (maybe using your example of the
> > number of descents of a permutation).
>
> A method ( = a Python function) is not a Sage Map ( = a Python object
> that model a mathematical function). I would like first to convert the
>  method into a map
> {{{
> from sage.categories.map import Map
> class NumberOfDescents(Map):
> def __init__(self):
> Map.__init__(Permutations(), NonNegativeIntegers())
>
> def _call_(self, p):
> return Integer(p.number_of_descents())
> }}}
> The above example is already non-trivial since it specifies a domain
> and a codomain (which is different from the parent of the image of an
> element):
> {{{
> sage: nod = NumberOfDescents()
> sage: p = Permutation([3,2,1])
> sage: nod(p)
> 3
> sage: nod(p).parent() is NN
> False
> }}}
> The second step would be to think how to add semantic to the map. Part
> of is already managed by the axioms/categories (for example a Morphism
> between GradedSets preserve the grading). But there is nothing for
> injectivity/surjectivity or more subtle properties.
>
> It would make more sense to register actual maps as above.
>
> Vincent
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

>
> --> It will not be possible (say within the next two years, except the
> unlikely event that I will a lottery without participating, and then
> spend some money to hire a professional programmer) to only query the
> statistics data, and do the computations within your own Sage.


Just to make this statement more precise: it will not be possible within
the next two years if Mmarco relies on your availability for this (there is
no blame in that statement, it's just a clarification that others might be
willing to work on this problem).
Paul

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: redesign combinatorial statistics

[Paul-Olivier Dehaye]

Hi Mmarco,
This is a functionality many of us would want too. The question that is
unclear is how to implement it in the best way. What Nathann refers to as
"some kind of protocol to transfer the combinatorial objects" is a very
hard problem. Fortunately, many people are starting to realise that this is
a desired functionality and constructively try to find solutions. Depending
on your background, you might be able to directly help, for instance by
annotating some of the functions in the sage code (a very easy thing to do,
for which you need only a web browser. This is a tiny step above editing
documentation).
People are actively working on this problem
Paul

Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Wed, May 28, 2014 at 10:01 AM, Nathann Cohen wrote:

> > Would it be possible to include the findstat functionality in sage?
>
> It is possible to write the code, and desirable. As the Sage is
> open-source, you are also welcome to give it a try if you need the feature.
> Sage already queries the OEIS, though for FindStat you will probably have
> to design some kind of protocol to transfer the combinatorial objects with
> the website's owners. I am told that you can contact them at
> i...@findstat.org.
>
> Nathann
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] combinatorial statistics

[Paul-Olivier Dehaye]

Since you ask, here is a thread where you have insulted me repeatedly:
http://trac.sagemath.org/ticket/16403
Others might think I have asked for it, but that's a different question,
and we can have that debate too if you want. But if we are going to have
that debate, I would ask that you first send me all links you think are
relevant, and that you accept that I send you all links that I find
relevant (which might be research papers on the topic of lone individuals'
net negative contributions to open source software development, despite
producing lots of code. For instance that would include background
reading/video watching relevant to the diversity thread). I would also ask
that we both spend the time that is needed to actually read through those
links and then set a date for the debate to start, and a place that the
debate is held.
This way everyone can make sure to prepare their own popcorn and know of
where to watch.
Paul

Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Wed, May 28, 2014 at 9:57 AM, Nathann Cohen wrote:

> Yo !
>
>
> > I find it quite difficult now to follow this thread, I see the answer to
> some emails that are not even in the thread...
>
> This is because it was sent to both sage-devel and sage-combinat. After a
> while somebody anwers to only one group and mess follows.
>
>
> > Anyway, I just want to answer to this specific sentence of Nathan: "This
> is only technical issues, nothing more. But I hate that it takes one year
> to see it fixed."
> >
> > Well, Nathan, you just have to live with it! See, we're all working on a
> global project depending on lots of people, we all have to wait. The fact
> that you hate / love something has no impact on my time line whatsoever.
>
> This is very very easy on you Don't you feel any responsibility at all
> for what you put into Sage ? We had a conversation one year ago about ways
> to fix that, one of which seems to suit you as you said on sage-devel just
> yesterday. And when several persons tell you that your design has a fault,
> and a way to solve it, you answer them with a "Just live with it ! The fact
> that you love/hate it has no impact on my time line whatsoever" ?
>
>
> > And you should understand that you won't make things faster by a)
> insulting people (as you did last year) and b) giving orders (as you just
> did in this very thread).
>
> I assume that what you call giving orders is this :
>
>
> "Our discussion about this is almost 1 year old. If you do not know how to
> clean this code this month, please remove it."
>
> You will have to provide the link yourself if you want to claim that I
> insult people. I don't claim that it never happens, but I am very
> interested in the context.
>
> Nathann
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: [sage-devel] redesign combinatorial statistics

[Paul-Olivier Dehaye]

If this is agreeable to the findstat project, how would this fare if
tomorrow me or my students:
 - start adding semantic decorators to existing classes (for instance, for
groups, adding information in the groupprops database, or from categories
adding information from the database of categories at the nLab)
 - start adding essentially empty classes and functions in sage that are
there only so I can add the empty decorators (for instance, LMFDB)

I understand I could do this as a separate git branch, but the point is
that this is meant to build on other people adding decorators, because it
is easy and convenient to them and they want to help my research project,
while at the same time
"hey-you-never-know-how-those-semantic-annotations-might-prove-useful=so=why-not-have-it-in-sage-even-if-it-supports-just-one-guy"

I am looking for a consistent workflow to support my work and that of my
students.

Paul

Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Wed, May 28, 2014 at 1:28 AM, Nathann Cohen wrote:

> > Let's not mix everything here. In FindStat, we do use a database for
> > statistics (not maps) but that's not what we're talking about here. We're
> > just talking about flagging some object methods as maps with some
> semantic
> > information.
>
> Indeed. You agreed to only talk about the aspects of this decorator which
> are of interest to Sage.
>
>
> > my only question is what "storing the info" means. I understand Nathan is
> > suggestiong I just put it in some database object somewhere, and then my
> > permutation object would just ask this object whenever it needs to give
> the
> > list of maps. Am I right here?
>
> Let us say that when the combinatorial_map decorator is called on a
> function f with some parameters, it does the following
>
> from sage.combinat.combinatorial_map import my_dictionary_database
> my_dictionary_database[f] = list_of_parameters_or_anything_you_like
> return f
>
> With a design like that, any semantic information is still available if
> you ever need it, and the function is left unchanged.
>
> Nathann
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: [sage-devel] redesign combinatorial statistics

[Paul-Olivier Dehaye]

I agree with you, but there are (at least) two questions left hanging:
1) is the database transient? i.e. repopulated once as the code is run?
2) nathann is arguing on the feature-length trac ticket that we are writing
together that empty methods have no place in sage if they only exist for
the decorator:
http://trac.sagemath.org/ticket/16403
The same arguments were made (by him and others) in Edinburgh, and indeed
miss the point of ABCs (made in the trac ticket) and the category framework
(not made in the trac ticket, because I only want to kick one can of worms
at a time)

Paul


Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Wed, May 28, 2014 at 12:51 AM, Simon King  wrote:

> Hi Paul,
>
> On 2014-05-27, Paul-Olivier Dehaye 
> wrote:
> > For anyone involved in findstat, there are several layers of complexity.
> > This is my assessment from outside the findstat collaboration:
> >  - they also deal with Mathematica code
> >  - they also deal with user-generated information that is not code
>
> You just provided two arguments for having an external database :)
>
> >  - they also develop some of the code and would thus 1) prefer to
> maintain
> > one rather than two separate objects (code and database)
>
> That's no valid argument. Currently, they simply put a decorator in front
> of a
> method. In future, they'll simply put a decorator in front of a method.
>
> The important difference is that now the decorator is replacing a proper
> method by an instance of some class, which is an intrusive way to encode
> information that is supposed to be retrieved by a function that is hidden
> somewhere. But in future the decorator will be writing to some database
> with
> a standard database engine, without replacing the method by something else.
>
> > 2) like to easily
> > and flexibly be able to develop the code as they intend to use it (i.e.
> > equipped with everything, cf. monkey patching)
>
> Again, this seems unrelated to the question of what the decorator should
> do.
>
> >  - some of the information they want is added/could easily be added by
> > others in sage code
>
> Again, adding information is now and shall in future be possible by putting
> a decorator in front of methods.
>
>
> >  - just like the LMFDB, the database term is a misnomer. They want their
> > thing to be data and code.
>
> So, why don't they focus on their data and code? Why do they spend their
> time
> with an ad-hoc implementation of a mock-database in an intrusive way? Do
> not re-invent the wheel, and try to use the right tool for a job!
>
> Let me try to re-formulate it:
> - There should be a database, locally stored in SAGE_SHARE, but perhaps
>   even able to talk with some remote database. This database would also
>   be able to deal with external information, from Mathematica or other
>   sources.
> - The @combinatorial_map decorator will be one (the easiest?) way to
>   register stuff in the database.
> - The user should in future have additional possibilities to register
> stuff and
>   do queries, namely by a proper database interface.
>
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: [sage-devel] redesign combinatorial statistics

[Paul-Olivier Dehaye]

For anyone involved in findstat, there are several layers of complexity.
This is my assessment from outside the findstat collaboration:
 - they also deal with Mathematica code
 - they also deal with user-generated information that is not code
 - they also develop some of the code and would thus 1) prefer to maintain
one rather than two separate objects (code and database) 2) like to easily
and flexibly be able to develop the code as they intend to use it (i.e.
equipped with everything, cf. monkey patching)
 - some of the information they want is added/could easily be added by
others in sage code
 - just like the LMFDB, the database term is a misnomer. They want their
thing to be data and code. The code is partly their data, either directly
(class dependencies) or indirectly (the code is run to produce the data).

Paul


Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Wed, May 28, 2014 at 12:13 AM, Simon King  wrote:

> Hi Viviane,
>
> On 2014-05-27, Viviane Pons  wrote:
> > The way it works: the decorator replaces the tagged methods by instances
> of
> > combinatorial map class, the functions only checks which methods are
> indeed
> > instances of this class.
>
> And, if I understand correctly, it is this kind of things that makes
> Nathann ask for removal of the decorator.
>
> What you *want* to do is create a database that handles requests of the
> type "what combinatorial maps are provided by a class C?", or perhaps even
> better "what combinatorial maps are provided by a sub-category S of
> Sets().Finite()?". This could very well be a (SQLAlchemy?) database that is
> stored somewhere, perhaps even in a remote location.
>
> But what you *do* is to encode this database via the *type* of methods.
> The information is not put into an external database, but the
> information is stored *implicitly* by changing Sage code.
>
> I agree with Nathann: This is intrusive! And when your decorator
> replaces methods by "instances of some class" then certainly the
> overhead of calling these methods will increase. Applying your decorator
> to a frequently (recursively?) used method may result in a slow-down, as
> it seems.
>
> Even when trying to take your perspective, I still don't understand why
> you might want the decorator to work in that way.
> Certainly a proper database (relying on a dedicated database engine) is
> faster and easier to search and thus more useful for you than an ad-hoc
> function that ultimately relies on listing attributes and determining
> their types.
>
> So, what is the rationale for *not* using a database for your database of
> combinatorial maps?
>
> > It is partly the information you need even so I'm not sure it's a good
> way
> > to have it.
>
> I see no reason how this could be a good way to have it.
>
> > And also, this function is hidden somewhere and not accessible
> > from the object or the parent itself.
>
> "Hidden somewhere" is bad for a user interface.
>
> > About Nathan's suggestion to have a flag, I don't know if it's such a
> good
> > idea. The idea is to provide this semantic information to any user of
> Sage
> > not machines.
>
> It seems to me that you are argueing *against* the current decorator.
> Calling a function that is hidden somewhere and relies on introspection
> (listing attributes, type check) is for machines. A user of Sage should
> have a database with a proper interface.
>
> > The way I see this, *because* of the FindStat use case, the
> > combinatorial_map decorator has been introduced and many Sage developers
> > have been devoted time into adding semantic information into sage
> methods.
> > Of course, we could remove this all together, but this would be a great
> > loss for Sage as this semantic information is useful for users. And
> Here, I
> > speak as a combinatorist person working with these objects every day.
> >
> > So, our concern should be: how to make this information easily available
> to
> > users and how could we store this without impacting efficiency of the
> > program.
>
> Do not store information by a decorator that changes code. Migrate it to
> a proper database, that may be stored in SAGE_SHARE. The decorator
> should write information into the database (or perhaps even pull
> information from it?) and, when done, simply return the unaltered
> method. In that way, it would not be intrusive, and the database would
> provide a not-so-hidden single point of entry.
>
> Best regards,
> Simon
>
>
> --
> 

Re: [sage-combinat-devel] Re: [sage-devel] redesign combinatorial statistics

[Paul-Olivier Dehaye]

An even better way would be for them to offer to maintain the database as
the findstat project, for them to implement a wrapper around that database
in sage, and for something like sage-explorer (developed at Edinburgh) to
do all the let's-build-a-web-service part.
There would be good symbiosis with the LMFDB project (*).

This is indeed a good solution as a first step. The only obstacle was, and
is still (?) to manage to explain to others what it is that they are trying
to do, and why they are trying to do it that way and not some other clever
quick and dirty way. This takes time, effort, energy. Much more useful
would be to get quick help in making it happen the right way right away.

Paul

(*) Not quite. But the needs of LMFDB and findstat really do align.



Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Wed, May 28, 2014 at 12:01 AM, Nathann Cohen wrote:

> >  Yes I've thought of that.
>
> Yet I was the first to publish ! One year ago ... :-P
>
> https://groups.google.com/d/msg/sage-devel/SnPfidRM9j8/4LbWLMBf-2kJ
>
> > I'm trying to find the best way of doing it. The decorator seems the
> best way to flag. Before returning the orignal function, I could store the
> "map" itself. But I would like to create the map objects only if needed,
> and this I'm not yet sure how to do.
>
> I don't get it... What if combinatorial map just copies the list of
> all its parameters AND the function into a database stored in some
> module ? You have absolutely no other work to do, and you would only
> create the map objects when somebody tries to ask anything about the
> content of the database, don't you ?
>
> Nathann
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: [sage-devel] redesign combinatorial statistics

[Paul-Olivier Dehaye]

>
> > The way I see this, *because* of the FindStat use case, the
> > combinatorial_map decorator has been introduced and many Sage developers
> > have been devoted time into adding semantic information into sage
> methods.
> > Of course, we could remove this all together, but this would be a great
> loss
> > for Sage as this semantic information is useful for users. And Here, I
> speak
> > as a combinatorist person working with these objects every day.
> >
> > So, our concern should be: how to make this information easily available
> to
> > users and how could we store this without impacting efficiency of the
> > program.
>
> Dead right ! Is there any reason why gathering this semantic information
> requires this decorator to wrap the function in a combinatorial map ? Can't
> the information be gathered wherever we need it *without* modifying the
> actual function ? You could do whatever you need with a decorator that,
> when applied to a function f with some flags, stores a copy of this
> function f and works with the flags while returning the original function
> f, can't you ?
>
> This would make it less intrustive, and actually not intrusive at all !
>
>
Yes, this is a solution that I have repeated to Viviane in Montreal. The
objection to that solution (while we were in Edinburgh) was that it would
quickly make sense to them to add a bunch of empty classes and functions
then.  Since, the transition to git has made part of that workflow better
for the findstat people.

Paul

-- 
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/d/optout.

Re: [sage-combinat-devel] combinatorial statistics

[Paul-Olivier Dehaye]

You asked how you failed me. Well, I know for a fact that your behaviour on
the list has put off people from contributing to sage. Certainly me, and
others who could have contributed indirectly to my research projects. So
that's how you have failed me, since you ask. But that's something I have
tolerated for a couple years now. The reason for my email is different: if
your attitude persists, it is likely to derail what I am trying to do now
along the same lines, when it is actually starting.

One option is to truly explain to you what it is that I am trying to do. At
this point, you are approximately 3 PhD thesis, 7-8 or so research papers
and a good 15 talks (but they are recorded) behind in terms of reading, if
you want the background material. Yet you send me to yet another thread
that I have already read (and participated in). I am pretty sure this is
not the right way for you to proceed.

Also, your ticket's description is a hodgepodge of one precise
("Graph.to_partition is very badly named") and two large grievances ("only
there for findstat", "find_stat, a project distinct from Sage"). I have not
made up my mind on the precise, but I know I disagree with the two large
grievances, and am more informed than you there.

I like Vincent's approach better than either of ours. Why don't we both
change tone and try to contribute constructively in "his" thread? We can
keep the negativity here if you need to interact that way with someone, and
bring the positive to that other thread.

Paul
PS: Francoise == Francoise Genova, the astronomer who was invited in
Edinburgh.


Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Tue, May 27, 2014 at 6:53 PM, Nathann Cohen wrote:

> Hello !
>
>
> > Due to the unfortunate absence of professional programmers to write and
> review our code
>
> Come on, that is our job.
>
>
> > and of mature professional mathematicians to establish clear strategic
> decisions for sage, we should actually as a research community be welcoming
> of diverse (already-coded) ideas, as long as they are not disruptive to
> other people's research objectives (the burden should be to prove that they
> disrupt).
>
> We are grown ups. If we think at some point that something should be
> undone, the discussion is on whether it should be undone. Not on whether we
> are allowed to undo things. We deprecate functions at every release, and
> that's healthy.
>
>
> > And even if there were, the burden should be for anyone to _improve_
> code that is considered useful by them, not remove.
>
> I said "remove" because waiting for one year to do something and still say
> "I will do it later" is not a good sign. Then, I remember saying in one
> long email that everything in FindStat seemed very cool and useful, but
> that we had no reason to host their code if it is not useful in Sage.
>
> Then, if it is useful in Sage, I believe that it should be made
> non-intrusive, i.e. the decorator should return the very function it
> received and not leave anything in between.
>
> This is only technical issues, nothing more. But I hate that it takes one
> year to see it fixed.
>
>
> > In light of this, please reflect on the amount of mathematics you know
> yourself.
>
> I just read your email, and so before you begin your long enumeration let
> me agree with you : I am an idiot, and I know nothing.
>
> I just smiled when I read your "do you know anything about categories",
> because funnily I am reviewing #16405 right now and wrote a couple of
> category tickets recently.
>
>
> > One thing is sure: that you feel qualified to comment on it).
>
> And clearly I am wrong. Do me a favor, read this and tell me why it is
> made invalid by the obvious fact that I don't understand anything about
> categories :
>
>
> https://groups.google.com/d/msg/sage-combinat-devel/hupt_5776j0/KtbiHpTKXrUJ
>
>
> > It might be that individuals feel that they understand what findstat is
> doing but are failing to understand the broader context, which might
> explain why projects like findstat, LMFDB or even sage-combinat have
> unnecessarily complicated relationships with the sage core itself, and why
> some of my contributions end up in the LMFDB code and not sage itself.
>
> Some individuals like me are bound to miss stuff forever, accept it, the
> world is filled with us idiots.
>
> Okay let's stop this game : all I have against FindStat is the useless
> methods they add (like .to_partition) and the intrusive decorator. Nothing
> else.
>
> > Also, have

Re: [sage-combinat-devel] combinatorial statistics

[Paul-Olivier Dehaye]

>
> Well, a positive review in Sage is just two persons agreeing together.
>

Maybe you nailed exactly where the problem is. The problem might very well
be that the person that ends up agreeing on the ticket review at the end is
the only one that stuck around. I think that is a strong possibility. Also
part of the problem is that everyone else either:
 - thinks they should be doing research instead (which is shortsighted and
toxic to really bring sage to another level, in my view);
 - doesn't want to argue because they find it very unpleasant.
(these two are of course not mutually exclusive)

Due to the unfortunate absence of professional programmers to write and
review our code and of mature professional mathematicians to establish
clear strategic decisions for sage, we should actually as a research
community be welcoming of diverse (already-coded) ideas, as long as they
are not disruptive to other people's research objectives (the burden should
be to prove that they disrupt). And even if there were, the burden should
be for anyone to _improve_ code that is considered useful by them, not
remove. This is because we have to be mindful that we are building
mathematics software, and that as a consequence no individual (even a
mathematician) will ever be able to comprehend the whole complexity that is
being integrated into the software. Yet we want to provide as consistent of
an experience as possible to cover various use cases. Fortunately, we can
inform ourselves, learn what others are doing, take classes, go to
conferences, and build up joint research projects with other disciplines.

In light of this, please reflect on the amount of mathematics you know
yourself. Do you know about L-functions? Have you tried to learn about them
in Edinburgh or when I went to Paris to explain it to Nicolas and Florent?
Do you know about category theory and what Nicolas is trying to do? (you
have said several times explicitly on the list that you were not
interested, but it is not clear to me that you understand it. One thing is
sure: that you feel qualified to comment on it).

It might be that individuals feel that they understand what findstat is
doing but are failing to understand the broader context, which might
explain why projects like findstat, LMFDB or even sage-combinat have
unnecessarily complicated relationships with the sage core itself, and why
some of my contributions end up in the LMFDB code and not sage itself.

Also, have you talked to Francoise and the Logilab people at the Edinburgh
workshop, people who are professional developing software in the sciences
to handle research results? Do you know about semantic web technologies and
things like that, especially as it is being applied to mathematics?

Anyways, even if you don't know about all those things, don't worry: it is
actually possible, for someone with an open mind, to learn those things or
at least a sufficiently general picture.

Paul



> Perhaps I could just as a friend of mine who agrees that find_start
> should be totally remved from Sage and let him give a positive review
> to my ticket ?
>
> That's why we discuss stuff, and that's why you should feel
> responsible when people are against what you implement.
>
> > The way I remember, nothing was really agreed at the end of this endless
> discussion last year. If you want to open a ticket to remove
> graph.to_partition, just do so.
>
> http://trac.sagemath.org/ticket/16403
>
> Nathann
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] combinatorial statistics

[Paul-Olivier Dehaye]

I would be happy to review any ticket in this direction.
Paul

Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Tue, May 27, 2014 at 5:54 PM, Christian Stump
wrote:

> > well, there was a decorator for statistics before the move to gitI
> have code that used it.
>
> sorry, Martin, that we removed it again!
>
> But you see that Nathann keeps arguing it is not useful to people (I
> am not going to participate in that discussion -- I want to do math
> and I don't kill my time *again* in such a discussion), so I am not
> going to put it back in. But feel free to use it locally, you can
> either just take the old code from an old version of Sage, or I can
> send you instructions of how to do it.
>
> Cheers, Christian
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] combinatorial statistics

[Paul-Olivier Dehaye]

Hi Nathann,
I have added myself as a reviewer for your ticket. The link you posted
includes a long discussion, which I am unable to read today or tomorrow. I
will review it by Sunday.
Paul

Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Tue, May 27, 2014 at 11:58 AM, Nathann Cohen wrote:

> Yo !
>
>
> > I agree, something should have been done a year ago.
>
> Cool !
>
>
> > But If you think it should be removed and not improved, please do it
> yourself.
>
> If think that "If this thing, which was debated one year ago, is not to be
> fixed SOON, then we should get rid of it". We are already hosting code
> which is only useful to a couple of persons and not to Sage, we definitely
> should not host it forever if they abandon it !
>
>
> > Please open and implement a ticket for that, I will review it.
>
> I wrote the following ticket to remove Graph.to_partition.
>
> http://trac.sagemath.org/ticket/16403
>
> Nathann
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] combinatorial statistics

[Paul-Olivier Dehaye]

I agree, something should have been done a year ago. But If you think it
should be removed and not improved, please do it yourself. Please open and
implement a ticket for that, I will review it.
Paul

Paul-Olivier Dehaye
SNF Professor of Mathematics
University of Zurich
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com
twitter: podehaye
freenode irc: pdehaye


On Tue, May 27, 2014 at 11:39 AM, Nathann Cohen wrote:

> Just so you know, I intend to "fix" the decorator at some point to reduce
>> whatever impact it could have (I learned a bit a more about decorator while
>> at PyCon).
>>
>
> Our discussion about this is almost 1 year old. If you do not know how to
> clean this code this month, please remove it.
>
> Also, if I remember correctly we had agreed that Graph.to_partition was to
> be removed anyway as its meaning was totally unclear. Please open and
> implement a ticket for that, I will review it. This should have been done
> one year ago, yet nothing happened since.
>
> Nathann
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] PyCon report

[Paul-Olivier Dehaye]

Thank you Viviane for this. I was there too and can only second what you
are saying and pile on. I include the lmfdb and sage-devel mailing lists as
your compilation is very relevant to many people in those teams as well.
Obviously, many in the sage-devel lists know high level python, but I
suspect less understand and expect (I didn't) that once you have a
conference with 2000+ people working on such a versatile language, the
biggest value is in meeting people (I have watched exactly 1 of the talks
Vivian listed, because the "hallway track" was even more interesting...).
You can watch videos home, but you would still be missing 80% of the
conference! And there are so many other types of events than talks!
I feel, like many, that we are on the cusp of a revolution of the way
science is done, thanks to python being the lingua franca of computational
science. Many groups (OpenScience, OpenEdx open data, IPython notebook,...)
are there at pycon to assist scientists make this a reality. The
mathematical community will certainly benefit from those generic tools, but
we still need software engineering help for our domain specific problems.
The help is there, we just don't come and ask for it: those domain specific
problems are generally interesting to others, and sometimes match problems
from completely different areas. Example: New Relic [1] uses the wrapt
library [2] to do monitoring to the ms of response times of websites etc,
by instrumenting their clients' code. I understood the problems the author
was solving in [3], because those were obstacles already encountered in the
context of sage/lmfdb development. I don't need to understand his solution
very deeply, but can have some trust in his library because it powers a
company worth USD 1b...
I hope to see many of you in Montreal again for PyCon2015!
Paul

 [1] http://en.wikipedia.org/wiki/New_Relic
 [2] https://pypi.python.org/pypi/wrapt
 [3] http://pyvideo.org/video/2617/advanced-methods-for-creat


Paul-Olivier Dehaye
skype: lokami_lokami (preferred)
phone: +41 76 407 57 96
chat: pauloliv...@gmail.com



On Tue, Apr 15, 2014 at 9:21 PM, Viviane Pons  wrote:

> Hi guys,
>
> so I'm still at PyCon 2014 Montreal for the sprint time. But I find it is
> the right time to give you some kind of report of my time here. Quick
> hints: it was one of the most useful, greatest conference I have ever been,
> and also, it was HUGE. There were around 2000 people (of which I knew 2...)
> and I can tell you, it brings the "break room" to an all other level... I
> met tons of new people everyday, it was exhausting and awesome!
>
> All the talks and Pycon tutorials are filmed and are now public.
>
> You can see here the list of talks :
> https://us.pycon.org/2014/schedule/talks/
> And here the videos: http://pyvideo.org/category/50/pycon-us-2014
>
> I have selected "a few" ones, some I attended, some I didn't, that I
> thought could be interesting for all of you guys. You'll find the links at
> the end of the email.
>
> But first, let me tell you quickly what I learned here...
>
> --- As a Python programmer --
>
> Well, just go through the "technical" videos that I selected and you'll
> see that it's worth going from a technical point of view... Any advanced
> question you have about the language, there is somebody here who can
> answer...
>
>  As a Open source developer -
>
> Actually, I haven't finished with this one, cause the sprints are
> happening right now and I intend to have a look around. But let's just say
> there are a bunch of people working on lots of different kind of open
> source projects and more generally lots of people thinking and discussing
> the open source philosophy.
>
>  As a scientist --
>
> There were lots of scientists here and I found it very interesting to go
> out of my own science circle to see what was happening out there. The talks
> are aimed for a large audience and are definitely easier to follow than
> most of the FPSAC ones, even so they relate to physics, biology and other
> cool stuff. Also, I got to talk about my research, and Sage, and maths, and
> combinatorics to people who didn't know about it and were really curious
> about it!
>
>  As a teacher --
>
> I am not teaching right now but I might be soon (hopefully?). There are
> lots of people here dealing with "teaching computer science" and especially
> python and trying to think of the best way to bring this knowledge to all
> kind of students. I also met students (girl students!), like undergrads
> attending the conference. I actually intend to advertise this conference
> (and its European sister EuroPython) to my future students, especially
> because they c

Re: [sage-combinat-devel] Applying for a European H2020 grant?

[Paul-Olivier Dehaye]

That's more or less it. Almost everyone knows this, but for information a
nontrivial percentage of the grant is anyways meant to handle
administration costs. All the information I was bringing in is that some
percentage of that percentage can be used to pay for the grant writer
retroactively (but maybe that's well known as well, it's just that the more
senior people around me who heard that as well were surprised).
I don't know if something is wrong with that. Potentially (as far as I
understand) Nicolas' proposal would be a request for at least EUR 2M, so a
lot of people on temporary positions can be hired and do interesting
research. The total to be distributed is EUR 42M. In my mind it does make
some sense for Europe to try to make sure each case is well-presented, not
just from a scientific point of view. They want to evaluate other aspects
like sustainability of the effort, for instance, or fit in the European
industrial landscape. We as mathematicians might have a harder time making
our case, even if it is true. Those grant writers know how to frame those
answers for specific combinations of calls and applications. I guess it is
a skill. Maybe I am just naive.
Anyways, if you don't like it, feel free to stay out of it.
Paul
PS: I have heard even more crazy... Preemptive lobbying before the call is
even put out. This means companies, generally in partnerships with more
technical universities, pay lobbyists in Brussels to make sure the call
matches exactly the coalition they have already formed. Basically they rig
the game. I can picture how that system started, from a pressing need of a
particular industry, but I can also easily picture how it could be abused...



On Sun, Mar 16, 2014 at 11:03 PM, Nathann Cohen wrote:

> AHAHAHAHAHAHAHAHAHAAHAHAHAHAHAH.
>
> So let me get this right : the plan to ask the CNRS some money in order to
> help you ask the Europe even MORE money, and it is assumed that a
> percentage of the bigger grant will go to a guy whose full-time job is to
> ask for money ?
>
> If there is something wrong in the world of research, I can't see it.
>
> Nathann
>
> On Sunday, March 16, 2014 10:18:12 PM UTC+1, Paul-Olivier Dehaye wrote:
>
>> I am completely inexperienced with this, but:
>>  - I have heard people around me say that with this type of grant support
>> for preparation of a grant, professional grant writers should be hired.
>> They help write the not-so-scientific portion of the grant.
>>  - I have heard  first hand from a "Principal Administrator of a unit in
>> DG CONNECT"  that these writers do make a difference.
>>  - I have also heard that some of those grant writers work like tort
>> lawyers, and get paid only if the grant is funded. They then get paid some
>> percentage of the administration budget of the grant, and that this is
>> allowed.
>> I can ask for more details if you would like.
>> Paul
>>
>>
>> On Sun, Mar 16, 2014 at 11:44 AM, Nicolas M. Thiery > > wrote:
>>
>>> Dear colleagues,
>>>
>>> At the occasion of a presentation of the European H2020 call for
>>> grants, I started discussing opportunities for Sage with Eugénia
>>> Shadlova (in charge of European projects at Université Paris-Sud) and
>>> Jean-Pierre Caminade (research infrastructure mission in the french
>>> research ministry). From those discussions, it seems a good bet could
>>> be the call EINFRA-9: e-Infrastructure for Virtual Research
>>> Environment.  The time line would be a submission in January 2015,
>>> with funding starting 8 month after the submission.
>>>
>>> So now is a good time to start thinking about it. This in particular
>>> since the French CNRS INS2I institute is offering support (up to 5000
>>> euros) for preparing such proposals, with an application deadline on
>>> the 21st (this Friday!). This money could be used e.g. to organize a
>>> Sage-Days this year geared toward this grant (and real work too!).
>>>
>>> European H2020 calls concern countries in Europe as well as associated
>>> countries and third countries as listed on [1]. Just to mention a
>>> couple where I can think of Sage developers and users from the top of
>>> my head, this includes e.g. Switzerland, Israel, Senegal, or South
>>> Africa.
>>>
>>> If you would tentatively be interested in joining as a participant,
>>> PI, or even better lead PI, please get in touch with me at any time,
>>> specifying:
>>>
>>> - Name, e-mail
>>> - trac & github account if you have them
>>> - Status, institute (I can derive that from the main page of
>>>   trac.s

Re: [sage-combinat-devel] Applying for a European H2020 grant?

[Paul-Olivier Dehaye]

Hi all,
I would be very happy to cover the front of dissemination of
knowledge/teaching/MOOCs. Of course, this is secondary in a call on
research infrastructure, but it is still important to teach other
researchers how to use the tools we build, or to assist them in teaching
their students, etc.
I will wait to see where the "meat" of the proposal goes before
contributing references to teaching everywhere.
I am afraid that this year it is best for someone in Switzerland to stay on
the sidelines.
Paul


On Sun, Mar 16, 2014 at 11:44 AM, Nicolas M. Thiery <
nicolas.thi...@u-psud.fr> wrote:

> Dear colleagues,
>
> At the occasion of a presentation of the European H2020 call for
> grants, I started discussing opportunities for Sage with Eugénia
> Shadlova (in charge of European projects at Université Paris-Sud) and
> Jean-Pierre Caminade (research infrastructure mission in the french
> research ministry). From those discussions, it seems a good bet could
> be the call EINFRA-9: e-Infrastructure for Virtual Research
> Environment.  The time line would be a submission in January 2015,
> with funding starting 8 month after the submission.
>
> So now is a good time to start thinking about it. This in particular
> since the French CNRS INS2I institute is offering support (up to 5000
> euros) for preparing such proposals, with an application deadline on
> the 21st (this Friday!). This money could be used e.g. to organize a
> Sage-Days this year geared toward this grant (and real work too!).
>
> European H2020 calls concern countries in Europe as well as associated
> countries and third countries as listed on [1]. Just to mention a
> couple where I can think of Sage developers and users from the top of
> my head, this includes e.g. Switzerland, Israel, Senegal, or South
> Africa.
>
> If you would tentatively be interested in joining as a participant,
> PI, or even better lead PI, please get in touch with me at any time,
> specifying:
>
> - Name, e-mail
> - trac & github account if you have them
> - Status, institute (I can derive that from the main page of
>   trac.sagemath.org if the information there is up to date)
>
> I have setup a git project for this would-be proposal [2]. A mailing
> list is coming too. I will add all the participants there so that they
> can start editing the information.
>
> The draft of project grew up from previous attempts at the scale of
> Sage-Combinat in France; there remains traces which should of course
> be cleared. Also other grant opportunities c/should be explored!
> (e.g. Paul-Olivier mentioned COST networks). And again: if anyone
> feels like taking on / sharing the lead, please!!!
>
> Please forward this to whoever might be interested.
>
> Cheers,
> Nicolas
>
> [1]
> http://ec.europa.eu/research/participants/docs/h2020-funding-guide/cross-cutting-issues/international-cooperation_en.htm
> [2] https://github.com/nthiery/sagemath-grant-europe/
>
> --
> 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 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Applying for a European H2020 grant?

[Paul-Olivier Dehaye]

I am completely inexperienced with this, but:
 - I have heard people around me say that with this type of grant support
for preparation of a grant, professional grant writers should be hired.
They help write the not-so-scientific portion of the grant.
 - I have heard  first hand from a "Principal Administrator of a unit in DG
CONNECT"  that these writers do make a difference.
 - I have also heard that some of those grant writers work like tort
lawyers, and get paid only if the grant is funded. They then get paid some
percentage of the administration budget of the grant, and that this is
allowed.
I can ask for more details if you would like.
Paul


On Sun, Mar 16, 2014 at 11:44 AM, Nicolas M. Thiery <
nicolas.thi...@u-psud.fr> wrote:

> Dear colleagues,
>
> At the occasion of a presentation of the European H2020 call for
> grants, I started discussing opportunities for Sage with Eugénia
> Shadlova (in charge of European projects at Université Paris-Sud) and
> Jean-Pierre Caminade (research infrastructure mission in the french
> research ministry). From those discussions, it seems a good bet could
> be the call EINFRA-9: e-Infrastructure for Virtual Research
> Environment.  The time line would be a submission in January 2015,
> with funding starting 8 month after the submission.
>
> So now is a good time to start thinking about it. This in particular
> since the French CNRS INS2I institute is offering support (up to 5000
> euros) for preparing such proposals, with an application deadline on
> the 21st (this Friday!). This money could be used e.g. to organize a
> Sage-Days this year geared toward this grant (and real work too!).
>
> European H2020 calls concern countries in Europe as well as associated
> countries and third countries as listed on [1]. Just to mention a
> couple where I can think of Sage developers and users from the top of
> my head, this includes e.g. Switzerland, Israel, Senegal, or South
> Africa.
>
> If you would tentatively be interested in joining as a participant,
> PI, or even better lead PI, please get in touch with me at any time,
> specifying:
>
> - Name, e-mail
> - trac & github account if you have them
> - Status, institute (I can derive that from the main page of
>   trac.sagemath.org if the information there is up to date)
>
> I have setup a git project for this would-be proposal [2]. A mailing
> list is coming too. I will add all the participants there so that they
> can start editing the information.
>
> The draft of project grew up from previous attempts at the scale of
> Sage-Combinat in France; there remains traces which should of course
> be cleared. Also other grant opportunities c/should be explored!
> (e.g. Paul-Olivier mentioned COST networks). And again: if anyone
> feels like taking on / sharing the lead, please!!!
>
> Please forward this to whoever might be interested.
>
> Cheers,
> Nicolas
>
> [1]
> http://ec.europa.eu/research/participants/docs/h2020-funding-guide/cross-cutting-issues/international-cooperation_en.htm
> [2] https://github.com/nthiery/sagemath-grant-europe/
>
> --
> 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 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: [sage-devel] Re: Call for vote about ticket #10963: axioms and more functorial constructions

[Paul-Olivier Dehaye]

Thanks for the very thoughtful and encouraging comments. A big hurdle to
starting any actual work on this has always been to see how well received
the category framework would be.

Florian is also struggling with  some issues of canonicity of the
definitions, so your insights might be helpful to him. His issues have more
to do with presentation though, while yours has to do with dynamic
resolution (but it might be that a canonical presentation could be based on
your resolution).

In any case, I do not want to distract the thread away from the topic of
Nicolas' ticket, and the fact that he has implemented something that works
beyond a prototype, unlike any of us.

Paul






On Wed, Mar 12, 2014 at 8:28 AM, Simon King  wrote:

> Hi Paul, hi Mark,
>
> On 2014-03-12, Mark Shimozono  wrote:
> >> Instead, I would advocate using a declarative domain specific language
> built for semi-formalizing
> >> mathematics
> >
> > The appeal of this paradigm is evident. It addresses
> > a fundamentally important issue: how to structure the development
> process to
> > encourage the code to reflect the mathematics in the most transparent
> fashion.
> >
> > Alas, it appears that this is a fair distance from being implemented
> > in python, and many important details need to be worked out.
>
> This could actually relate to another suggestion that I made on the
> ticket, and like to mention here.
>
> A substantial part of Nicolas' approach deals with the problem
> of finding the correct class which Cs().SomeAxiom() will be an instance
> of. For instance, mathematical results imply that
> Rings().Division().Finite() should be an instance of the FiniteFields
> class (resp. Fields.Finite---actually I like nested classes and find
> them rather easy to understand and transparent).
>
> All the logic---including the mathematical reasoning---is *implicit* in the
> code, by chosing names and by setting some attributes. But in the end of
> the day, we have a machinery that returns classes. Hence, what we in
> fact have is (close to) a metaclass.
>
> This metaclass must be fairly intelligent, as it implements mathematical
> results (main example: Wedderburn's theorem). Part of my criticism of
> Nicolas' approach is that the mathematical reasoning somehow happens in
> the cloud: There is no single spot that does the reasoning *explicitly*,
> but it is a dynamical process that seemingly does the right thing, but
> only *implicitly*.
>
> As I have demonstrated (as a proof-of-concept), the required mathematical
> reasoning can be done by computations in the "boolean polynomial ring"
> (which is implemented in Sage).
>
> Hence, one could think of implementing a metaclass for category classes,
> that acts as a database and knows
>  - where existing category classes can be found (such as: "the FiniteFields
>class is in sage.categories.finite_fields"),
>  - when and how the category class has to be created dynamically,
>  - what structure is needed to apply an axiom (for applying the
>"Distributive" axiom, one needs that the category in question both is
>a sub-category of multiplicative and additive magmas),
>  - how to find a "normalised" set of axioms that define a category.
>Really, the fact that ring*division*finite is the same as
>ring*division*commutative*finite boils down to normal form
>computations in a boolean polynomial ring.
>
> And again, I have to admit that it isn't close to being implemented.
> Thus, I'd prefer to have something that already works, which is Nicolas'
> implementation.
>
> > In the meantime, we all need a version of sage to work with...
>
> +1
>
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] Re: [sage-devel] Re: Call for vote about ticket #10963: axioms and more functorial constructions

[Paul-Olivier Dehaye]

I am confused about what to do.

Everyone seems to be assuming that one of Volker's or Nicolas' approaches
must be right. It might very well be that both approaches are suboptimal
compared to a third. Still, Nicolas' has the merit to be implemented.

Let me explain:
I support Nicolas' initiative and do very much think this is a feature we
want in sage.
I have concerns with Nicolas' nested classes approach but recognize that it
has the merit of being the only one implemented (and used already!).
My opinion is that all the objective criteria for a patch have been passed
(except for some regression on legacy code, which does not seem to be the
core of Volker's objections) and that only fairly subjective concerns are
left (paraphrase: "it's confusing to a python developer to have nested
classes!").
I also have concerns with Volker's approach.
I have my own alternative approach to suggest.
I am not willing to devote the time to implement my own alternative (just
like Volker is not willing to implement his).
I am willing to review any patch submitted by Volker and suggest
improvements (these are likely to require substantial work on his part).
I am *definitely* not trying to be obstructionist but am afraid that in
this case the review process for patches is unclearly defined, and just
aping the behaviour of others by me would lead to total stalemate.

At this stage I better outline my own solution so as to open it to more
criticism from everyone (more fun!). As I see it, both Nicolas' and
Volker's suggestions have the shortcoming that they require a one-time
decision now of how to make purely mathematical information fit into
python's syntax (object for an axiom versus nested classes). This also
prevents any further reuse (short of python introspection of live objects
or static analysis of the code) of this formalised-as-code purely
mathematical information into any other system, be it the LMFDB, the
combinatorial statistics finder, the atlas of categories, another CAS or
any other mathematicians' collaborative efforts. Instead, I would advocate
using a declarative domain specific language built for semi-formalizing
mathematics. Such a language was developed as part of a PhD thesis (Florian
Rabe), and is called MMT. It tries to precisely address the needs of a
community of mathematicians trying to formalise some part of mathematics.
In fact (and very importantly) you don't need to formalise from the ground
up. You can just formalise parts of math (i.e. "a finite group has order a
prime power", even though you never defined what a group was). This is
meant to be used collaboratively, and in fact meant to be used for the
whole math community at once in a distributed fashion. You should think of
it as "OpenMath (re)done right". One could argue that this would require
sage developers to know two languages (python and MMT), but that would only
be true for those who want to implement a truly new category. In fact, if
this MMT takes off (and sage might have a role in that), it would allow
reuse across use cases, and we would conceivably benefit from the work of
others, for instance a database of categories developed by others:
http://nforum.mathforge.org/discussion/1754/
Now in my "solution", this declarative language still has to be translated
into python code. Of course at that stage mathematicians' interaction and
python code have been decoupled, so it would be a pure question of
optimisation whether Nicolas or Volker's solution is better. This question
would have an entirely objective answer based purely on efficiency.

Paul
PS: Florian has visited me in Zurich 6 months ago, and is receptive to the
idea of using his system as a basis to generate code, even if it was not
his original intent.


On Tue, Mar 11, 2014 at 10:23 PM, Volker Braun wrote:

> On Tuesday, March 11, 2014 8:42:04 PM UTC, Nathann Cohen wrote:
>>
>> If you want to get this ticket inside of Sage there is an easy way :
>> review it.
>
>
> +1
>
> also would save me a lot of time
>
>
>  --
> 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/d/optout.
>

-- 
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/d/optout.

Re: [sage-combinat-devel] combinatorial map decorators

[Paul-Olivier Dehaye]

Hi,

After your discussion, can you please report on your decision (and what led
you to it)?

Thanks,

Paul


On Wed, Jun 19, 2013 at 6:59 PM, Nicolas M. Thiery  wrote:

> Hi Christian, Nathann, Chris, Viviane, ...
>
> Given that the topic is nontrivial -- if not controversial -- and
> given that most of the protagonists are in the same town, I'd
> recommend that we use this perfect occasion to have a brainstorm about
> it here, say tomorrow. Christian: any chances for you to join by
> Skype?
>
> Cheers,
> Nicolas
>
> PS: Christian: best wishes for a quick recovery!
> PS: Nathann: I got your e-mail!
>
> --
> 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 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.
>
>
>

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

Re: [sage-combinat-devel] problems with dot2tex

[Paul-Olivier Dehaye]

By the way, it should be pyparsing 1.5?.x and not 2.x as  that's only in
python 3.
Paul


On Wed, May 15, 2013 at 6:32 PM, Anne Schilling wrote:

> Hi!
>
> Oh, this is really terrible since we are constantly using the dot2tex
> option
> to view pictures!
>
> I created a ticket
>
> http://trac.sagemath.org/sage_trac/ticket/14594
>
> Best,
>
> Anne
>
> On 5/14/13 5:49 PM, Nicolas M. Thiery wrote:
> >   Dear Sage-Combinat developers, dear Nathann,
> >
> > On Tue, May 14, 2013 at 05:29:35PM -0700, Anne Schilling wrote:
> >> Travis noticed that with sage-5.10.beta2, even if dot2tex is installed,
> sage
> >> does not notice that it is installed. I seem to have the same problem
> >>
> >> sage: B = CrystalOfTableaux(['A',2],shape=[1])
> >> sage: view(B)
> >> dot2tex not available.  Install after running 'sage -sh'
> >>
> >> Any idea why?
> >
> > Shoot, this is annoying:
> >
> > sage: import dot2tex
> > ...
> > ImportError: No module named pyparsing
> >
> > dot2tex indeed needs pyparsing. And pyparsing used to ship with
> > matplotlib, but apparently the new version of matplotlib does not
> > include it anymore. So one need to install it somehow.
> >
> > Note: as noted by Nathann a while ago on sage-devel, Networkx uses
> > pyparsing as well in a couple places; so it probably will have a
> > similar issue.
> >
> > Any volunteer to take on this task, or at least create a ticket?
> >
> > 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 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

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: teaming up with LMFDB

[Paul-Olivier Dehaye]

Look at the table at
http://www.lmfdb.org/Character/Dirichlet/?modulus=&conductor=51&order=
It's certainly not perfect yet, but it goes in the right direction.
It has many features: individually clickable entries in the table,
expandable explanations for the column headers, sortable columns, and
partial fetching from the database (if you click on the bottom grey
arrow, you get the next 10 entries).
Paul

On Fri, Oct 19, 2012 at 9:35 AM, Nicolas M. Thiery
 wrote:
> On Thu, Oct 18, 2012 at 07:25:49PM -0700, Andrew Mathas wrote:
>> At some point I am going to start putting (graded) decomposition matrices 
>> into
>> sage and when this happens it would be very nice if there was a good 
>> graphical
>> way of viewing these matrices as they get very large very quickly which makes
>> them hard to read on a "flat" screen. Being able to scroll through the 
>> entries
>> of these polynomial/integer matrices (especially while keeping the row and/or
>> column labels in view), resort the rows and columns, change between different
>> labelings, restrict to blocks, and extract associated data such as the
>> dimensions of the irreducibles from the graphical interface would be very
>> handy.
>
> Hmm, views on big tables. This sounds definitely useful!
>
> It should be fairly straightforward to implement with something like
> the Larch Environment. For a web interface, we could hope to reuse
> some online spreadsheet implementation.
>
> Could you create a ticket?
> 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.
>

-- 
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: Workshop in Edinburgh: "Online databases: from L-functions to combinatorics"

[Paul-Olivier Dehaye]

There are many issues that could/should/will be addressed.

The main one is how to get easily from the kind of files that a math
researcher would keep (some compressed version of the data that would
make sense to a couple people if lucky) to something like
"www.lmfdb.org".  In addition, one possibility that is not visible to
outsiders of the lmfdb project is "How do I query this data from my
sage command-line?".  It is sort of possible to do that at the moment,
if you have some knowledge of the lmfdb code ( at
http://code.google.com/p/lmfdb/ ), but it s only sometimes possible,
not really easy or consistent yet.

If a clear, efficient and standardized path is offered that allows to
do all that, it will help in many other situations (for an individual
serving their own data, or retrieving data, or adding data to existing
database, etc).

Paul


On Thu, Aug 9, 2012 at 12:23 AM, Volker Braun  wrote:
> Thanks now I can see where this is going. By "online service" I meant
> something that can be queried in code, not where I can manually fill in
> forms and then copy&paste the output.
>
>
> On Wednesday, August 8, 2012 6:02:12 PM UTC-4, Rob Beezer wrote:
>>
>> On Wednesday, August 8, 2012 8:28:03 AM UTC-5, Volker Braun wrote:
>>>
>>> So it would be nice to have a online service to hook into if you just
>>> want to look up something.
>>
>>
>> See http://www.lmfdb.org/
>
> --
> 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/-/tD65nydws64J.
>
> 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.

[sage-combinat-devel] Workshop in Edinburgh: "Online databases: from L-functions to combinatorics"

[Paul-Olivier Dehaye]

The American Institute of Mathematics and the International Center for
Mathematical Sciences are sponsoring a workshop on

"Online databases: from L-functions to combinatorics" (co-organized by
Nicolas M. Thiery and me)

This workshop will take place in Edinburgh, Scotland, from January 21
to January 25, 2013.

Space and funding is available for a few more participants. Anyone
with experience in one or more of the relevant topics is strongly
encouraged to apply (design of core features of sage, mathematical
databases, L-functions, sage-combinat,...)

More information is available at:
http://aimath.org/ARCC/workshops/onlinedata.html

Paul-Olivier Dehaye
ETH Zurich / University of Zurich

-- 
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] Slow generation of partitions with constraints

[Paul-Olivier Dehaye]

I don't think the following is normal (under 4.8):

sage: timeit("tmp = Partitions(25,min_length=2).count()")
5 loops, best of 3: 1.59 s per loop

sage: timeit("tmp = len([x for x in Partitions(25) if len(x)>=2])")
25 loops, best of 3: 12.6 ms per loop

(The slowdown seems to be in integer_list.rightmost_pivot doing lots of 
comparisons involving the infinity module)

I remember reading that the partition-generating code should be reworked, 
can someone tell me the status of that? 

Thanks!

Paul

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

[Paul-Olivier Dehaye]

Hi Rishi,
It is a bug, I saw it reported on trac.sagemath.org previously, but
can't find it anymore.
Paul

On Wed, Feb 15, 2012 at 6:46 PM, r Rishikesh  wrote:
> In sage, the following succeeds.
>
> sage: Partition([2,0,1])
>
>
> I would expect this not to succeed. Is this a bug or there is a reason
> for this construction to work.
>
> Rishi
>
> --
> 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: AIM workshop proposal: opinion

[Paul-Olivier Dehaye]

> "(with quality ranging from poor to excellent: wikipedia, PlanetMath
> [3], WolframjAlpha [5])."
> I get the sense you might be saying that Wikipedia is poor quality and
> Wolphram|Alpha is excellent.
Certainly not! Corrected.

> * "Interaction with the data then tends to be very limited:"   One
> thing about OEIS is that a lot of the "interaction" is via people
> contributing new information, and a *lot* of that happens with OEIS,
> right?  This was a big argument for why it should be truly free
> (rather than their initial "5% only" rule).
Not familiar with this story.
As far as I know, if you can't do "custom searches" with OEIS. You
have to download the whole thing and program your own for that.
For instance, if you know the value of your sequence at primes only,
you don't want to fill the sequence with 0s at non-primes and hope
superseeker (by email) will identify that submission as
A010051*something. If you messed up your submission, wait another
hour...

> * "At some point, the associated algorithms have been reimplemented in
> Mathematica, into the package KnotTheory`"    Just curious -- was that
> funded, or done by Wolfram, or?
I don't know who funded it, but judging from
http://katlas.org/wiki/Setup
Dror Bar-Natan had significant influence if he didn't do it himself.

> * Regarding the human genome being "relatively small", just say how
> big it is (in megabytes).  I think it's pretty tiny, if I remember
> right.  And it has a "good" copyright (I think).   Just saying it is
> possible for one person to "hold it", still allows for the possibility
> that it is 20 terabytes (say).  I wonder how many terabytes I can
> hold... I have some 6TB backup disks for sage.math, and I could hold a
> few at once :-)
For everyone's information, the FASTA file looks like it is 1.5Gb.
It's also as heavy as a bookcase
http://en.wikipedia.org/wiki/File:Wellcome_genome_bookcase.png
Maybe I can barely hold one copy.

> * Top of page 3, describing what you propose to do: this is perhaps
> the most important part of the proposal feels a bit unclear and murky
> to me, so could be made a bit clearer (maybe structure it into 3
> paragraphs).  Also, you might say that this is a plan, but you are
> flexible about changing anything if there are sufficiently compelling
> arguments for design at the workshop.    Also, it would be really good
> if you could get feedback on this proposal from Jon Bober and Harald
> Schilly, since your proposal could potentially be read as: "we looked
> at what they did, and it wasn't very good, so we are going to rewrite
> it from scratch using Object Oriented Programming!"   (I know I'm
> exaggerating here...)
Yes, ok.

> I really, really hope this gets funded.
Thanks

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

-- 
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] AIM workshop proposal: opinion

[Paul-Olivier Dehaye]

I made the changes suggested so far. Keep them coming.
@Christian: You are right on the comment about Sage and Sage-Combinat.
Paul

On Tue, Nov 1, 2011 at 2:20 PM, Christian Stump
 wrote:
>> I am about to submit a workshop proposal to the American Institute of
>> Mathematics. The deadline is today, Nov. 1st (fortunately, US time).
>> The current title of the proposal is "Sage and databases: L-functions
>> and combinatorial objects".
>
> Thanks for mentioning findstat.org! Could you probably change it to
> www.findstat.org (and if you want, you could also provide a reference
> like the one for sloane: C. Berg, F. Saliola, and C. Stump, The
> Combinatorial Statistic Finder. http://www.findstat.org).
>
> I also see on p.3 l. -1 sage and sage-combinat. If I remember right,
> Sage and Sage-Combiant are preferred (is that right, Nicolas?).
>
> All the best for the proposal, 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.
>
>

-- 
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] AIM workshop proposal: opinion

[Paul-Olivier Dehaye]

Dear all,
I am about to submit a workshop proposal to the American Institute of
Mathematics. The deadline is today, Nov. 1st (fortunately, US time).
The current title of the proposal is "Sage and databases: L-functions
and combinatorial objects".
You can see the pdf at
http://combinat.sagemath.org/misc/raw-file/eae7d2865a9e/grants/2011-11-01-AIM-workshop/aim.pdf
(and can access the source via the sage-combinat repo -> misc -> grants ).
Comments more than welcome!
Paul

-- 
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] Multiple databases and sage

[Paul-Olivier Dehaye]

Dear all,

I am currently participating in a sage-based project that aims to
integrate a lot of number theory databases (some of you know it, or
are even participating!).  Some of the goals of the project are to
display, search across or perform further computations on archived
objects that come from very different sources. The variety of sources
can be due to human factors (more than one person has data, or people
have overlapping but not identical interest), historical reasons (a
legacy table has since been expanded but should be kept for
compatibility reasons), and most importantly mathematical reasons (the
archived objects can be computed using very different constructions
that current mathematical results do not know how to unify, but all
these objects should really be looked at through the same lens
sometimes).

I expect these to be very common problems when trying to integrate
mathematical data from various sources into sage, regardless of the
area of mathematics.

Does this sound familiar to anyone?

Some participants of the sage-combinat project are pushing for the
concept of "Categories" (<> mathematical categories) as a way to
exploit object-oriented programming to its fullest and organize code
in a flexible and efficient way. "Categories" are then used to
incorporate purely mathematical information (of the type "a Field is a
Ring"), that Python can also understand and use to build a whole class
hierarchy.

I think that similarly the problems I have described in the first
paragraph could be partly solved from a new concept of
"MathematicalDatabases", as a way to exploit object-oriented
programming to its fullest and organize _data_ in a flexible and
efficient way.

Any thoughts on that?

Thanks

Paul

-- 
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] core and quotient...

[Paul-Olivier Dehaye]

I would be interested to add existing code to such a class, especially
things related to abaci and 0-1 sequences. Also a fast iterator over
cores would be nice, but I am quite sure the implementation I have
could be much improved.
Paul


On Sun, Jul 24, 2011 at 1:16 AM, Anne Schilling  wrote:
>        Hi All!
>
> What is the status on a class for cores? Does that exist by now?
>
> I would like to have some new methods in Partitions such as
> is_core and from_core_to_k_bounded which goes from k+1 cores
> to k-bounded partitions.
>
> Currently one can do
>
>    sage: la = Partition([4,3,3,3,2,2,1])
>    sage: kappa = la.k_skew(4); kappa
>    [[12, 8, 5, 5, 2, 2, 1], [8, 5, 2, 2]]
>
>    sage: kappa.row_lengths()
>    [4, 3, 3, 3, 2, 2, 1]
>
> but as far as I can see there is no inverse yet for k_skew
> if only kappa[0] is specified.
>
> Best,
>
> Anne
>
> On 4/9/11 11:11 AM, Florent Hivert wrote:
>>
>>       Hi there,
>>
>> Currently the methods core and quotient returns respectively a list and a
>> list
>> of list. Does anyone object on having them return a partition and a tuple
>> of
>> partition ?
>>
>> sage: Partition([7,7,5,3,3,3,1]).core(3)
>> [1, 1]
>> sage: type(Partition([7,7,5,3,3,3,1]).core(3))
>> 
>>
>> sage:  sage: Partition([7,7,5,3,3,3,1]).quotient(3)
>> [[2], [1], [2, 2, 2]]
>> sage:  type(Partition([7,7,5,3,3,3,1]).quotient(3)[0])
>> 
>>
>> In the long term, there could be a particular class for cores (there is
>> already a prototype in the k-tableaux patch). But on the contrary of what
>> is
>> in this patch, I've rather have this class inherits from partitions. Any
>> comments ?
>>
>> 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.
>
>

-- 
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: Multipartitions and Multitableau

[Paul-Olivier Dehaye]

I don't care much about names either...
In your 1., you say "An element of  Multipartition() will be
CombinatorialClass-es which wrap lists of Partition_class()" do you
mean tuples, maybe? It is pedantic,  but relevant in light of #11414.
One should just decide on which is more useful to have in the end.
Paul


On Thu, Jun 2, 2011 at 4:17 PM, Andrew Mathas  wrote:
>
>
>> PartitionTuples is actually used, in some of my programs and now one
>> time in patch #11412, and further in patch #11414 (submitted day
>> before yesterday).
>
> Hi Paul,
>
> Currently it is just a suggestion to rename PartitionTuples as
> Multipartions. Whether or not this actually happens depends on how
> everyone feels about it. Personally, I prefer Multipartition but I can
> live with PartitionTuples :)
>
>> If one wants to give all partitions of given weight, but indexed
>> through their core and quotient, it makes sense to use PartitionTuples
>> to index the quotients.
>
> Yes, I do this too in quite a bit of my (gap) code. My motivation for
> working on this is that I need more functionality for multipartitions
> than is currently available. Essentially, I want to extend a lot of
> the symmetric group combinatorics for partitions to the class of
> Multipartitions/PartitionTuples. Current functionality shouldn't be
> lost  and, if anything, it will become easier as there will be more
> methods available and new classes for individual multipartitions which
> are element classes for the existing classes for sets of
> multipartitions. Whether or not the name is changed I'll have to make
> sure that my changes don't break existing code, including your
> patches. And then my code will only be accepted if its reviewers think
> it's an improvement:)
>
>> A note on deprec(i)ation: is there a formal description somewhere of
>> that process?
>
> I just looked and found:
> http://www.sagemath.org/doc/reference/sage/misc/misc.html#sage.misc.misc.deprecated_function_alias
> There is some discussion about the depreciation policy in sage-devel.
> To summarise, functions should only be depreciated if there is general
> agreement; backward compatibility should be maintained unless there
> are good reasons not to; depreciated code should carry a warning of
> teir empending depreciation for at least one year before it is
> removed.
>
> Andrew
>
> --
> 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] Multipartitions and Multitableau

[Paul-Olivier Dehaye]

Hi all
PartitionTuples is actually used, in some of my programs and now one
time in patch #11412, and further in patch #11414 (submitted day
before yesterday).
If one wants to give all partitions of given weight, but indexed
through their core and quotient, it makes sense to use PartitionTuples
to index the quotients.
A note on deprec(i)ation: is there a formal description somewhere of
that process?
Paul

On Thu, Jun 2, 2011 at 3:53 AM, Paul Bryan  wrote:
> Hi Andrew. I began implementing a MultiPartitions class based on Partitions
> but other things took over. This Trac
> ticket http://trac.sagemath.org/sage_trac/ticket/10630 has the relevant
> patch. You may find this cuts out some of your work. I also had ideas for
> cleaning up Partitions but never quite got there either and so the
> multipartitions code I wrote may also need some modifications in line with
> your cleanup. I also was not at all interested in writing optimised code to
> begin with and the code needs much attention in that direction. Correctness
> first I always say!
> My main interest was in multi symmetric polynomials and functions for which
> I have some code, but not a lot.
> Since at least one other person is interested in multi partitions at least,
> I may be able to find some time to collaborate on this work. Could you
> (either on list of privately) share some of your thoughts/work so far?
> Also, is there still interest in multi-symmetric functions? I can certainly
> provide what I have so far and may find some time to work on the code again
> if there's interest.
> Cheers,
> Paul.
>
> On 2 June 2011 10:49, Andrew Mathas  wrote:
>>
>> Dear All,
>>
>> I need to implement multipartitions and (standard) (multi)tableaux so
>> I am in the process of writing the relevant classes. While doing this
>> I have been testing Jason's tableaux patch and discovering a lot of
>> debris in partition.py which I'm cleaning up.
>>
>> Please let me know what you think of the following.
>>
>> 1. PartitionTuples() appears to be unused. The term "multipartition"
>> and is compatible with SkewMultipartition, so I propose depreciating
>> (or deprecating for my American friends:) these classes and creating
>> Multipartitions classes, which are parents, whose elements will belong
>> to the class Multipartition(). An element of  Multipartition() will be
>> CombinatorialClass-es which wrap lists of Partition_class().
>>
>> 2.. Given the lack of enthusiasm to my previous suggestion of
>> overloading Tableau(),  StandardTableau() as the entry point for
>> constructing different tableaux classes I am now creating new classes
>> of Multitableaux() in multitableau.py. These tableaux will be wrapped
>> lists of tableau.
>>
>> 3. Depreciate the following functions/classes in partition.py:
>>    deprecation('"partitions_set()" is deprecated. Use the
>> SetPartitions(S,k) instead')
>>    deprecation('"number_of_partitions_set()" is deprecated. Use the
>> SetPartitions(S,k).cardinality() instead')
>>    deprecation('"number_of_partitions()" is deprecated. Use the
>> Partitions(n).cardinality() or Compositions(n,k).cardinality()
>> instead')
>>    deprecation('"partitions()" is deprecated. Use the iterator from
>> Partitions() instead')
>>    deprecation('"ordered_partitions()" is deprecated. Use the
>> Compositions() instead')
>>    deprecation('"number_of_ordered_partitions()" is deprecated. Use
>> the Compositions().cardinality() instead')
>>    deprecation('"partitions_greatest()" is deprecated. Use
>> PartitionsGreatestLE(n,k).list() instead')
>>    deprecation('"partitions_greatest_eq()" is deprecated. Use
>> PartitionsGreatestEQ(n,k).list() instead')
>>    deprecation('"partitions_tuples()" is deprecated. Use
>> Multipartitions(n,k).list() instead')
>>    deprecation('"number_of__partition_tulpes()" is deprecated. Use
>> Multipartitions(n,k).cardinality() instead')
>>    deprecation('"power_partition()" is deprecated. Use
>> Partition(pi).power(k) instead')
>>
>> 4. Remove all of the code in partition.py that was depreciated in
>> 2009.
>>
>> My plan is post these changes as two patches, one cleaning up the
>> partition.py code and creating multipartitions and the other creating
>> multitableaux. Alternatively, I could do this as three patches: create
>> multipartitions, clean up partitions and then implement multitableaux.
>>
>> Please let me know what you think of these.
>>
>> Finally, an unrelated question:  does sage have nice class for
>> wrapping tables, or labelled matrices? As far as I can see it doesn't.
>> The labelled tables that I am thinking specifically are for wrapping
>> decomposition matrices, or formal characters but they could be used
>> equally well for character tables, multiplication tables and so on.
>> Thomas Breuer and Frank Lübeck  have a very nice interface
>> "browse" (see http://www.math.rwth-aachen.de/~Browse/) for doing this
>> inside Gap4. A similar object in sage would be nice...
>>
>> Cheers,
>> Andrew
>>
>> --
>> You received t

[sage-combinat-devel] Frobenius coordinates vs. beta numbers

[Paul-Olivier Dehaye]

Hi all,
I have added a few basic functionalities tied to Frobenius coordinates/
beta numbers of partitions. (trac 10724). Those two concepts are the
same, but there was some placeholder doc that already used the name
"beta numbers" so I kept that, despite the other one sounding better
to me. Florent now tells me he also prefers "Frobenius coordinates".
Which one do you prefer?
I suggest "Frobenius coordinates".
Paul

-- 
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] schensted insertion

[Paul-Olivier Dehaye]

consider also the code in
sage: Permutation([6,2,3,1,7,5,4]).robinson_schensted()
which performs insertions (and more). Mike Hansen added it, it bisects
per row, and is thus be much faster for large partitions.

in any case there should really be a function called T.bump()!

paul


On Sat, Mar 6, 2010 at 3:07 PM, Pedro Sanchez  wrote:
>
>
> On Sat, Mar 6, 2010 at 11:08 AM, bump  wrote:
>>
>> Tableau method contains two methods, bump and schensted_insert.
>>
>> I think these are equivalent. That is, I was unable to find case where
>> T.bump(i) and T.schensted_insert(i) produced different output.
>>
>> Am I missing something?
>>
>> Dan
>>
>> --
>> 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-de...@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.
>>
>
> T.schensted_insert() allows for both left or right insertion  (that is, row
> bumping or column bumping)
>
> T.schensted_insert() is a wrapper as its code shows:
>
>    if left:
>     return self._left_schensted_insert(i)
>     else:
>     return self._right_schensted_insert(i)
>
>
> On the other hand "bump" only codes row-bumping (right insertion) so "bump"
> is less useful.
>
> I compared
> T.bump() code with T._right_schensted_insert()
> and yes, it seems both do the same, although in different ways
>
> --
> 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-de...@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-de...@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: long time spent by _repr_

[Paul-Olivier Dehaye]

ok, that makes a bit more sense as to why it happens. but there ought
to be indeed a better solution...

On Sep 7, 10:41 am, "Nicolas M. Thiery" 
wrote:
> On Sat, Sep 05, 2009 at 11:02:21AM -0700, Paul-Olivier Dehaye wrote:
> > I don't know enough python to tell for sure, but this looks suspicious
> > to me. The printout below shows that a lot of time is spent on
> > JoinCategory._repr_ (1 underscore) in categories.py and
> > SymmetricFunctionAlgebra_classical.__repr__ (2 underscores), and I don
> > t understand why it should be that way. Is it normal? (it seems to get
> > worse with Big going bigger too)
>
> Thanks for the report.
>
> Each time a tensor([a,b]) is calculated, it has, for example, to
> retrieve the parent of the result from those of a and b. This is
> cached, and looking up this cache involves computing a hash value.
>
> My bet is that this comes from the default implementation of the
> hashing function for SageObject, which is to compute a hash of the
> string representation of the object. That's not very safe and is *slow*.
>
> I have been meaning for a while to use 'id' instead has default
> implementation for __hash__ for objects with unique representation.
>
> Thoughts anyone?
>
> Should we go for it? Or at least cache the hash function?
>
> That this repr thing appears for categories rather than parents is
> further suspicious. There might be another missing cache somewhere in
> the tensor product code. I'll keep this in mind next time I play
> around with this!
>
> 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
-~--~~~~--~~--~--~---

[sage-combinat-devel] long time spent by _repr_

[Paul-Olivier Dehaye]

I don't know enough python to tell for sure, but this looks suspicious
to me. The printout below shows that a lot of time is spent on
JoinCategory._repr_ (1 underscore) in categories.py and
SymmetricFunctionAlgebra_classical.__repr__ (2 underscores), and I don
t understand why it should be that way. Is it normal? (it seems to get
worse with Big going bigger too)
Paul

S = SymmetricFunctions(QQ)
s = S.s()
p = S.p()
pp = tensor([p,p])

Big = 5

z = sum(sum(sum( tensor((   p(h[nu]),p(h[mu]) )) for mu in
partitions_list(i))   for nu in partitions_list(i)) for i in (1..Big))

%prun tmp = sum(z**i for i in range(Big-1))

  2324784   17.5430.000   22.4370.000 category_types.py:227
(_repr_)
  3985344   14.4390.000   48.2280.000 category.py:1246
()
  1328448   14.1320.000   15.4350.000 classical.py:331
(__repr__)
  2159265   10.2320.000   10.2320.000 free_module.py:31
(__init__)
  66767429.6880.0009.6880.000 combinat.py:1202
(__hash__)
   8305529.6440.000   10.1350.000
{sage.structure.sage_object.have_same_parent}
664492/18.8680.000  330.003  330.003 {sum}
332379/37.5990.000  329.769  109.923 modules_with_basis.py:587
(__call__)
... a lot of other things ...

--~--~-~--~~~---~--~~
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: symmetric functions over more than one alphabet?

[Paul-Olivier Dehaye]

well, not my research, but close. here is the doctest that should pass
(modulo typos...):

sage: S = SymmetricFunctions(QQ)
sage: s = S.s()
sage: p = S.p()
sage: pp = tensor([p,p])

sage: t. = PowerSeriesRing(pp,default_prec=5)
( WARNING: this will not work on sage-combinat the the moment, as pp
is not recognized as commutative, even after applying the patch I
wrote earlier in this thread. on my local sage, I have removed checks
when building up the power series to check that this is indeed
commutative (since pp is), but that's certainly not the right thing to
do in the long run. I can't patch sage myself without pointers from
others, since this involves the tensor and categories extensions,
which people are, as far as I understand, concurrently working on. )

sage: K = sum(pp(sum(tensor(( s[lambda],s[lambda]  ))  for
lambda in partitions_list(i)) * T^i for i in (1..4)) # The Cauchy
kernel
( WARNING: this won t work for two reasons...
* lambda is not a good word to use (OK, this is me, it just took
me so long to realize where the problem was...)
* as described earlier in this thread and in Nicolas' separate
post, this won't give the right result because of module conversions.
there is a workaround:
K = sum(sum(tensor(( p(s[lambda]),p(s[lambda])  ))  for
lambda in partitions_list(i)) * T^i for i in (1..4))
  but I think it should work as first written too. )

sage: logK = log(K)
( WARNING: this won't work because log is not implemented for general
power series. funny thing, exp works...)

sage: logK - sum(1/i* tensor(( p[i],p[i]   )) * T^i for i in
(1..4))
O(T^5)# if i didn't mess up...

The power series is there to test the Cauchy identity up to a certain
degree only.
The reason I want to do similar things this without using actual
variables is because of course the complexity grows extremely fast...
To compute K up to exponent T^i, you need all partitions of weight up
to i and thus at least i variables (Note: it seems hopeless anyway to
use such basic code in Sage, as it is very slow in handling
expressions like this )

Paul

On Sep 4, 10:19 am, "Nicolas M. Thiery" 
wrote:
>         Salut!
>
> On Wed, Sep 02, 2009 at 02:40:38PM -0700, Paul-Olivier Dehaye wrote:
> > for all that's worth, that won't do for what i am trying. the point is
> > to have the generality of alphabets.
>
> Ah, now this is interesting. What exactly do you mean by "generality"
> of alphabets? What would be very helpful would be a fake Sage session
> demonstrating the features you would need (without worrying about the
> syntactical details which we can figure out later).
>
>
>
> > There is some structure for my computation (matching degrees of the
> > polynomials over the two alphabets, which I was hoping to exploit with
> > the PowerSeriesRing idea). In any case, it's more symmetric and gives
> > a better presentation, so I am happier with this.
>
> > There are bugs however, as this will demonstrate:
>
> > S = SymmetricFunctions(QQ)
> > s = S.s()
> > p = S.p()
> > ss = tensor([s,s])
> > pp = tensor([p,p])
>
> > a = tensor((s[5],s[5]))
> > pp(a)
>
> > The answer given,
> > p[[5]] # p[[5]]
> > is not correct
>
> Yup. When I said "in the longer run, there will be support for mixed
> coercions", I also included those coercions :-)
>
> But yes, this should at least complain that the conversion is not
> (yet) possible instead of returning a mathematically wrong result!
>
> Thanks for pointing out this example which finishes to convince me
> that the current very tolerant conversions provided by
> CombinatorialFreeModule are *harmful*. See upcoming e-mail.
>
> 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
-~--~~~~--~~--~--~---

[sage-combinat-devel] Re: symmetric functions over more than one alphabet?

[Paul-Olivier Dehaye]

> > There are (at least) two bugs here:
> > (1) sB is not in CommutativeRings()
> > I'll fix this right now.
> > (2) PowerSeriesRing should use
> >         base_ring in CommutativeRings()
> >    rather than
> >         isinstance(base_ring, commutative_ring.CommutativeRing):
> > Would you be fine writing and handling a patch for this?
> OK

I have uploaded a patch on the combinat patch server. It includes a
doctest of a power series version of a Newton identity. I didn t
replace
isinstance(base_ring, commutative_ring.CommutativeRing)
by
base_ring in CommutativeRings()
but rather put an "or" (was afraid to screw up things for other rings)
paul
--~--~-~--~~~---~--~~
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: symmetric functions over more than one alphabet?

[Paul-Olivier Dehaye]

merci pour la reponse :)
more below, inline.

> 
> Things are different if you are fine working with fully expanded
> expressions.
for all that's worth, that won't do for what i am trying. the point is
to have the generality of alphabets.

> 
> > Is there any better way to do this?
>
> An alternative way is to work over the tensor product of two copies of
> the ring of symmetric functions:
>
> sage: S = SymmetricFunctions(QQ)
> sage: s= S.s()
>
> sage: tensor([s, s])
> Symmetric Function Algebra over Rational Field, Schur symmetric functions 
> as basis # Symmetric Function Algebra over Rational Field, Schur symmetric 
> functions as basis
>
> sage: x = tensor((s[1], s[2,1])) + 2* tensor((s[2,1], s[3]))
> sage: x
> s[[1]] # s[[2, 1]] + 2*s[[2, 1]] # s[[3]]
>
> sage: x * x
> s[[1, 1]] # s[[2, 2, 1, 1]] + ...
>
> Now, is this better?
>
>  - From an efficiency point of view, this should be similar, unless
>the manipulated symmetric functions have some specific structure;
>the only difference is how the coefficients are collected together.
>
>  + It is more symmetric

There is some structure for my computation (matching degrees of the
polynomials over the two alphabets, which I was hoping to exploit with
the PowerSeriesRing idea). In any case, it's more symmetric and gives
a better presentation, so I am happier with this.

There are bugs however, as this will demonstrate:

S = SymmetricFunctions(QQ)
s = S.s()
p = S.p()
ss = tensor([s,s])
pp = tensor([p,p])

a = tensor((s[5],s[5]))
pp(a)

The answer given,
p[[5]] # p[[5]]
is not correct (but once sage has what it thinks is pp(a), it s a
proper element of pp(a) and it does the computations with it well)

> 
> There are (at least) two bugs here:
>
> (1) sB is not in CommutativeRings()
>
> I'll fix this right now.
>
> (2) PowerSeriesRing should use
>
> base_ring in CommutativeRings()
>
>rather than
>
> isinstance(base_ring, commutative_ring.CommutativeRing):
>
> Would you be fine writing and handling a patch for this?
OK
Paul


On Sep 2, 4:03 pm, "Nicolas M. Thiery" 
wrote:
>         Salut!
>
> On Tue, Sep 01, 2009 at 09:41:11AM -0700, Paul-Olivier Dehaye wrote:
> > I am trying to do computations with symmetric functions over different
> > alphabets.
>
> > This seems to have been part of the SFA package, itself part of the mu-
> > EC package, itself considered a deprecated part of the MuPAD-combinat
> > package... 
> > (seehttp://mupad-combinat.sourceforge.net/doc/en/index/referenceManual.html
> > ). Is it still in Sage via this chain?
>
> Good job tracing that back :-)
>
> But no, this feature did not survive the migration. The main thing is
> that we haven't yet a good idea of what the design should be. In most
> applications, users will want to manipulate unexpanded symbolic
> expressions involving a mix of functions from several alphabets. And
> we plainly don't have good experience in symbolic computations!
>
> Things are different if you are fine working with fully expanded
> expressions.
>
> > Sage currently has a roundabout way to do this, but it's not so
> > pretty, requires all kinds of coercions and is probably slower than it
> > needs to be:
>
> > sA = SFASchur(QQ)
> > sB = SFASchur(sA)
>
> > x = sum(sB(1/i)*sB(sA([i]))*sB([i]) for i in (1..5))
>
> > pA = SFAPower(QQ)
> > pB = SFAPower(pA)
>
> > pB(x)
>
> > Is there any better way to do this?
>
> An alternative way is to work over the tensor product of two copies of
> the ring of symmetric functions:
>
>     sage: S = SymmetricFunctions(QQ)
>     sage: s= S.s()
>
>     sage: tensor([s, s])
>     Symmetric Function Algebra over Rational Field, Schur symmetric functions 
> as basis # Symmetric Function Algebra over Rational Field, Schur symmetric 
> functions as basis
>
>     sage: x = tensor((s[1], s[2,1])) + 2* tensor((s[2,1], s[3]))
>     sage: x
>     s[[1]] # s[[2, 1]] + 2*s[[2, 1]] # s[[3]]
>
>     sage: x * x
>     s[[1, 1]] # s[[2, 2, 1, 1]] + ...
>
> Now, is this better?
>
>  - From an efficiency point of view, this should be similar, unless
>    the manipulated symmetric functions have some specific structure;
>    the only difference is how the coefficients are collected together.
>
>  + It is more symmetric
>
>  + accessing coefficients should be easier when there are lots of
>    alphabets (n-fold tensor product). The support for tensor products
>    in Sage is still limited though. In the longer run, there will be
>    support for mixed coercions (say you want the result 

[sage-combinat-devel] Re: problem installing sage-combinat from sage 4.1.1 on Mac OS 10.4

[Paul-Olivier Dehaye]

> > I followed the instructions from
> >http://wiki.sagemath.org/combinat/Installation
> > and ran into a problem (see below for the dump) when installing the
> > patches on top of a mint 4.1.1. The folder that is looked after
> > doesn't exist (actually, not even /Users/Shared/sage , my install
> > folder is /Applications/sage , as per the instructions online) . I
> > fixed it by adding a symbolic link, but this is not the right
> > solution.
>
> > I don't really see what this has to do with combinat, but since I got
> > the error in installing the combinat patches, I guess it should be
> > reported here.
>
> Thanks for the report! Did you install Sage from binaries or from
> source?  In case it is from binaries, could you try to install it
> (say under /Applications/sage-source) from source to see if anything
> similar pops up?

I had installed from the binaries.
[ 3 hours later... : ] When installing 4.1.1 from source and then
upgrading to combinat, I don t have the problem.


> Oh, btw: symmetric functions (and actually all algebras) are currently
> broken on 4.1.1 due to a missguarded patch. That will be fixed in an
> hour or two.
yes, i had noticed :)

paul






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

[sage-combinat-devel] problem installing sage-combinat from sage 4.1.1 on Mac OS 10.4

[Paul-Olivier Dehaye]

I followed the instructions from
http://wiki.sagemath.org/combinat/Installation
and ran into a problem (see below for the dump) when installing the
patches on top of a mint 4.1.1. The folder that is looked after
doesn't exist (actually, not even /Users/Shared/sage , my install
folder is /Applications/sage , as per the instructions online) . I
fixed it by adding a symbolic link, but this is not the right
solution.

I don't really see what this has to do with combinat, but since I got
the error in installing the combinat patches, I guess it should be
reported here.

Paul
PS: in case that changes anything, I am running
prompt:~ user$ gcc -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: /var/tmp/gcc/gcc-5370~2/src/configure --disable-
checking -enable-werror --prefix=/usr --mandir=/share/man --enable-
languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/
$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/
lib --build=powerpc-apple-darwin8 --with-arch=nocona --with-
tune=generic --program-prefix= --host=i686-apple-darwin8 --target=i686-
apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5370)
prompt:~ user$



building 'sage.plot.plot3d.parametric_surface' extension
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-
prototypes -I/Applications/sage/local//include -I/Applications/sage/
local//include/csage -I/Applications/sage/devel//sage/sage/ext -I/
Applications/sage/local/include/python2.6 -c sage/plot/plot3d/
parametric_surface.c -o build/temp.macosx-10.3-i386-2.6/sage/plot/
plot3d/parametric_surface.o -w
gcc -L/Users/Shared/sage/sage-4.1.1/local/lib -bundle -undefined
dynamic_lookup build/temp.macosx-10.3-i386-2.6/sage/plot/plot3d/
parametric_surface.o -L/Applications/sage/local//lib -lcsage -lstdc++ -
lntl -o build/lib.macosx-10.3-i386-2.6/sage/plot/plot3d/
parametric_surface.so
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning -L: directory
name (/Users/Shared/sage/sage-4.1.1/local/lib) does not exist
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning can't open
dynamic library: /Users/Shared/sage/sage-4.1.1/local/lib/libgmp.
3.dylib referenced from: /Applications/sage/local//lib/libcsage.dylib
(checking for undefined symbols may be affected) (No such file or
directory, errno = 2)
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning can't open
dynamic library: libpari-gmp.dylib referenced from: /Applications/sage/
local//lib/libcsage.dylib (checking for undefined symbols may be
affected) (No such file or directory, errno = 2)
building 'sage.ext.interpreters.wrapper_rdf' extension
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-
prototypes -I/Applications/sage/local//include -I/Applications/sage/
local//include/csage -I/Applications/sage/devel//sage/sage/ext -I/
Applications/sage/local/include/python2.6 -c sage/ext/interpreters/
wrapper_rdf.c -o build/temp.macosx-10.3-i386-2.6/sage/ext/interpreters/
wrapper_rdf.o -w
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-
prototypes -I/Applications/sage/local//include -I/Applications/sage/
local//include/csage -I/Applications/sage/devel//sage/sage/ext -I/
Applications/sage/local/include/python2.6 -c sage/ext/interpreters/
interp_rdf.c -o build/temp.macosx-10.3-i386-2.6/sage/ext/interpreters/
interp_rdf.o -w
gcc -L/Users/Shared/sage/sage-4.1.1/local/lib -bundle -undefined
dynamic_lookup build/temp.macosx-10.3-i386-2.6/sage/ext/interpreters/
wrapper_rdf.o build/temp.macosx-10.3-i386-2.6/sage/ext/interpreters/
interp_rdf.o -L/Applications/sage/local//lib -lcsage -lgsl -lstdc++ -
lntl -o build/lib.macosx-10.3-i386-2.6/sage/ext/interpreters/
wrapper_rdf.so
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning -L: directory
name (/Users/Shared/sage/sage-4.1.1/local/lib) does not exist
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning can't open
dynamic library: /Users/Shared/sage/sage-4.1.1/local/lib/libgmp.
3.dylib referenced from: /Applications/sage/local//lib/libcsage.dylib
(checking for undefined symbols may be affected) (No such file or
directory, errno = 2)
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning can't open
dynamic library: libpari-gmp.dylib referenced from: /Applications/sage/
local//lib/libcsage.dylib (checking for undefined symbols may be
affected) (No such file or directory, errno = 2)
building 'sage.ext.interpreters.wrapper_cdf' extension
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-
prototypes -I/Applications/sage/local//include -I/Applications/sage/
local//include/csage -I/Applications/sage/devel//sage/sage/ext -I/
Applications/sage/local/include/python2.6 -c sage/ext/interpreters/
wrapper_cdf.c -o build/temp.macosx-10.3-i386-2.6/sage/ext/interpreters/
wrapper_cdf.o -w
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-
prototypes -I/Applications/sage/local//include -I/Applications/sage/
local//include/csage -I/Applications/sage/devel//sage/sage/ext -I/
Applications/sage/

[sage-combinat-devel] symmetric functions over more than one alphabet?

[Paul-Olivier Dehaye]

Hi all

I am trying to do computations with symmetric functions over different
alphabets.

This seems to have been part of the SFA package, itself part of the mu-
EC package, itself considered a deprecated part of the MuPAD-combinat
package... (see 
http://mupad-combinat.sourceforge.net/doc/en/index/referenceManual.html
). Is it still in Sage via this chain?

Sage currently has a roundabout way to do this, but it's not so
pretty, requires all kinds of coercions and is probably slower than it
needs to be:

sA = SFASchur(QQ)
sB = SFASchur(sA)

x = sum(sB(1/i)*sB(sA([i]))*sB([i]) for i in (1..5))

pA = SFAPower(QQ)
pB = SFAPower(pA)

pB(x)

Is there any better way to do this?

In addition, I really want to do my computations in a power series
ring over the commutative ring of (Schur, whatever) symmetric
functions in 2 alphabets. The extra variable t would let me keep track
of the weight of the degrees of the polynomials involved, since for
each term of my computation the degrees are the same in the two
alphabets. So I tried something like this:

T. = PowerSeriesRing(sB,default_prec=5)
but Sage (4.1.combinat and 4.1.1 on the server) complains:
TypeError: base_ring must be a commutative ring

Is there a way to circumvent that? Any help greatly appreciated!

Thank you

Paul

PS: It might also be good to edit
http://wiki.sagemath.org/combinat/Installation
since this is a natural place you end up at when you want to install
combinat, and it s confusing with that title...
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---