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
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
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
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
On 29 May 2014 21:02, Nathann Cohen nathann.co...@gmail.com 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
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
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
Hi Travis,
I agree with you and I think it was already suggested by Simon that
the maps should not be built on startup. On the other hand, the maps
that we want to register might not all come from a method.
I created ticket #16408 and drafted a working implementation in
Just to clarify, i wasn't thinking on sage sending a query to findstat, but
performing the search locally (i.e. having findstat software included in
Sage).
I don't know how findstat is implemented, so i don't know how wise that
aproach would be. Does findstat relly on a big database that is
On Thu, May 29, 2014 at 10:14:20AM +0200, Vincent Delecroix wrote:
I agree with you and I think it was already suggested by Simon that
the maps should not be built on startup. On the other hand, the maps
that we want to register might not all come from a method.
I created ticket #16408 and
Does findstat relly on a big database that is enhanced with the new queries?
Or does it compute every query from scratch?
I start with answering here since this the crucial point.
We want to use Sage in FindStat only in the background, a user
interacting with FindStat (by searching for
Hi,
On Thu, May 29, 2014 at 12:29:45PM +0200, Christian Stump wrote:
We want to use Sage in FindStat only in the background, a user
interacting with FindStat (by searching for statistics, or by
contributing statistics) should not see what's happening in the
background.
As a developper and
On Thu, May 29, 2014 at 12:29:45PM +0200, Christian Stump 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
On Thu, May 29, 2014 at 11:42:40AM +0200, Nicolas M. Thiery wrote:
Here is the description of http://trac.sagemath.org/ticket/16410,
which potentially needs review:
--
From the discussions of (TODO: add refs to the
Yoo !!
Nathann, Christian, Viviane, ... do you mind briefly stating on the
ticket whether this sounds like a reasonable step forward?
Well... I don't have much to add there I think... Besides, for
political reasons, you will understand that I cannot review this
ticket :-P
For me what
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
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
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-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
On 29 May 2014 21:02, Nathann Cohen nathann.co...@gmail.com 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
+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
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
On Thu, May 29, 2014 at 10:02 PM, Nathann Cohen nathann.co...@gmail.com
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.
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
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
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
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
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.
An excellent idea for all such
But there is a real technical disagreement here too.
There is no such thing. One of Paul-Olivier's last posts was about how he
thought we agreed 100% together and wanted me to say it. It is part of our
couple therapy.
https://groups.google.com/d/msg/sage-combinat-devel/QRUXmy6UZVo/hfPQfkVzT8MJ
I think we all agree on this idea now (that the decorator should not wrap
the method), so there is no point in keeping the argument.
Still, I have asked a few questions on which I'd like you guys opinions:
- what's the best way to store this information? Nathan and Simon mentioned
database,
Hi Vivianne,
2014-05-28 19:32 UTC+02:00, Viviane Pons vivianep...@gmail.com:
I think we all agree on this idea now (that the decorator should not wrap
the method), so there is no point in keeping the argument.
Still, I have asked a few questions on which I'd like you guys opinions:
- what's
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
Would it be possible to include the findstat functionality in sage? That is,
i have a bunch of pairs (permutation, number), then call the function
findtsta on them, and get a list of possible ways that the numbers can me
computed from the permutations. All inside sage, without need to go to
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
-- 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
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).
It is not a problem -- it's the
It seems that actually nobody read my initial post on that thread...
so let me repeat
There are two disjoint tasks:
- add semantic to Map and Morphism (Sage)
- gather the list of meaningful maps (Sage/FindStat)
First of all, most of us agree that we need more semantic at the level
of maps.
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
Hi Christian,
2014-05-28 11:32 UTC+02:00, Christian Stump christian.st...@gmail.com:
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
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
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.
Thanks for the clarification! I
Vincent I had read your post but I hadn't understood that you wanted
something like this. This Map class seems a really good idea to me, it
looks like our combinatorial map class that we use to wrap the methods but
improved.
After this discussion, the way I would see things would be:
* having a
Hi!
On Wed, May 28, 2014 at 11:54:22AM +0200, Vincent Delecroix wrote:
Hi Christian,
2014-05-28 11:32 UTC+02:00, Christian Stump christian.st...@gmail.com:
It seems that actually nobody read my initial post on that thread... so
let me repeat
I did -- but didn't really have any
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
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.
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
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
Hi Paul,
2014-05-28 17:42 UTC+02:00, Paul-Olivier Dehaye
paul-olivier.deh...@math.uzh.ch:
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
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
I think we all agree on this idea now (that the decorator should not wrap
the method), so there is no point in keeping the argument.
Still, I have asked a few questions on which I'd like you guys opinions:
- what's the best way to store this information? Nathan and Simon mentioned
database,
Hi Vivianne,
2014-05-28 19:32 UTC+02:00, Viviane Pons vivianep...@gmail.com:
I think we all agree on this idea now (that the decorator should not wrap
the method), so there is no point in keeping the argument.
Still, I have asked a few questions on which I'd like you guys opinions:
- what's
Hello !!!
Is he? Sorry, then this is a point where Nathann and I do not agree.
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.
find abstract methods
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
@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
- 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
On Wednesday, May 28, 2014 10:51:10 AM UTC-7, vdelecroix wrote:
For me, it would makes sense on parents directly
{{{
sage: Permutations().known_maps_to(Partitions())
[...]
}}}
And in the methods known_maps_to and known_maps_from there should be
pointer on how to feed the database
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:
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
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
58 matches
Mail list logo
