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 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
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
Sorry Nathann, I don't take orders.
If you want to open tickets, just do so. I don't think a ticket removing
the map decorator all together would be positively reviewed right now. If
you really want to know my time frame, I *intend* to work on this decorator
to make it better this summer. If
Sorry Nathann, I don't take orders.
No but you should feel responsible for the mess you add to Sage.
If you want to open tickets, just do so. I don't think a ticket removing the
map decorator all together would be positively reviewed right now. If you
really want to know my time frame, I
thanks for the fast reply -- but I need statistics, not maps. I..e, I'd
like to have a list of all methods applying to permutations that return a
number...
I don't think there is anything like that for statistics, maybe the sign
that we do need more semantic into Sage?
Is it correct
Am Dienstag, 27. Mai 2014 12:10:22 UTC+2 schrieb Viviane Pons:
thanks for the fast reply -- but I need statistics, not maps. I..e, I'd
like to have a list of all methods applying to permutations that return a
number...
I don't think there is anything like that for statistics, maybe
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
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,
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.
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
Hello everyone,
I like what statistics try to do but I do not like the way it works.
Please tell me where I am wrong and where I am right. I can provide
some proof of concepts as soon as most of you agreed on the design.
Please: critics are welcome.
I think that there are two disjoint tasks:
-
Besides: is it possible to run a more exhaustive FindStat search? If I
understand correctly, FindStat limits itself to 3 maps, right?
No -- you can change the 3 into a 5 at most. And the at most is just a
limit to not run for too long, so if you are willing to wait
overnight, we can also do 6
One use case for statistics which comes to my mind immediately is to
provide
answers to
Just to make sure : I *NEVER* said that statistics on combinatorial objects
were useless, did I ? My objections are related to the code that is
included in Sage, and how it is written.
Besides: is it possible to run a more exhaustive FindStat search? If
I understand correctly, FindStat limits itself to 3 maps, right?
No -- you can change the 3 into a 5 at most. And the at most is just a
limit to not run for too long, so if you are willing to wait
overnight, we can
Hello !!!
I must say that I'd love to see the findstat search engine as part of sage.
I would love it too. Querying the findstat database from within Sage
is clearly a good thing.
Nathann
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
Am Dienstag, 27. Mai 2014 20:56:58 UTC+2 schrieb Nathann Cohen:
Hello !!!
I must say that I'd love to see the findstat search engine as part of
sage.
I would love it too. Querying the findstat database from within Sage
is clearly a good thing.
But only half of the story.
Martin
Another question: I would like to search for a statistic (on permutations,
but the question applies in general) that satisfies addtitional structural
constraints (eg., it should be invariant under conjugation with the long
cycle). Is such a search also possible?
The obvious solution is to
Yes! So, if I want to perform such a query, I should send the code
generating the statistic to you, right?
How urgent is it? -- I could try and see if the server explodes if I
increase the 5 to a 7. That way, you can keep playing there.
--
You received this message because you are
How urgent is it? -- I could try and see if the server explodes if I
increase the 5 to a 7. That way, you can keep playing there.
I'll try with 5 first! The reason I did not notice is that you don't get
to choose if you hit search for distribution when looking at an entry in
the
I guess this is getting slightly off topic now, so I'll continue in
private, unless someone objects...
For anything related to FindStat, you can write to i...@findstat.org :)
Many thanks,
Martin
--
You received this message because you are subscribed to the Google Groups
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,
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 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
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
Hi Viviane,
On 2014-05-27, Viviane Pons vivianep...@gmail.com 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
Hi Nathann,
On 2014-05-27, Nathann Cohen nathann.co...@gmail.com wrote:
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
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)
Hi Paul,
On 2014-05-27, Paul-Olivier Dehaye paul-olivier.deh...@math.uzh.ch wrote:
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*
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.
If we were to use a sage database for those maps (I've never used
Hi Paul,
On 2014-05-27, Paul-Olivier Dehaye paul-olivier.deh...@math.uzh.ch 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
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
Hi Viviane,
On 2014-05-27, Viviane Pons vivianep...@gmail.com wrote:
What I have in mind (and I think what Nathan had in mind) is
def map_decorator(f, args):
# storing the info
return f
Yes, exactly! Currently, storing the info means wrap f, encode the
information by
the colour of
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
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
35 matches
Mail list logo
