Just adding a link to a track ticket that is relevant:
http://trac.sagemath.org/ticket/16403
On Monday, July 8, 2013 12:23:21 PM UTC+2, vdelecroix wrote:
Hi,
I do like the project find_stat but do not like the way it intends to do
it. In that sense, I mostly agree with Nathann objections.
Hi,
I do like the project find_stat but do not like the way it intends to do
it. In that sense, I mostly agree with Nathann objections.
Following Thierry, why combinatorial maps are not implemented as morphisms
between two proper parents ? We could add some semantic to morphisms
Hi,
i first want to say that i love you all, i am not deeply involved in
sage-graphs nor sage-combinat, nor representing any community. Just my
two cents about this thread and the related tickets.
- I disagree that this thread reached a consensus.
- I disagree that functionalities in Sage can
On Friday, June 21, 2013 10:43:13 PM UTC+2, Dima Pasechnik wrote:
I think a decorator like this makes the code unreadable, and if it can
be avoided then it should be avoided.
+1
My opinion is very close to the one of Dima in this thread. I believe we
should avoid to spread such decorator in
Hell !
I don't agree on the
situation for Poset, identifying a (finite) poset with its Hasse
diagram is very natural, so to_directed_graph seems to be very
natural to me.
What could possibly be wrong with the existing Poset.hasse_diagram() method
?
Where do I find this
What could possibly be wrong with the existing Poset.hasse_diagram()
method ?
Nothing.
Well. It's a bit hard to grep the conversions that can be obtained from
the constructors, though :-P
All I wanted to show is that we didn't invent the to_??? methods which
you call unusual Sage
Hellooo !
but I do think that this .to_partition() and .to_graph() are not valuable
to Sage
My impression is that you only care because it is your graph code.
I think that I would have said the same if you had patched any other class,
but I look closely at what happens to graphs in Sage,
Helloo Christian.
I was thinking of our find_stat battle from one week ago, and I
wondered if you could answer the questions I raised in my answer to
your post. In particular (but not only) about the methods added to
Graph and Poset ?...
Thanks,
Nathann
On 20 June 2013 18:19, Nathann Cohen
Hi Nathan --
I was thinking of our find_stat battle from one week ago, and I
wondered if you could answer the questions I raised in my answer to
your post. In particular (but not only) about the methods added to
Graph and Poset ?...
Given the level of shrillness to which you certainly
Hello !
I keep voting for having the methods added to Graphs and to Posets. I
just looked again at the list of methods for graphs, and there are 280
of them. For me (and some others, whichever reason we might have)
these two methods are useful for our mathematics research and that
makes it
Dear all,
Let me try to draw a consensus (in fact I believe it's already there),
so that we can ignore the irrelevant historical details of the
discussion and move forward toward what we can do to improve the
situation.
Here are a couple statements that might be agreed upon by everybody:
On Wednesday, June 26, 2013 10:19:52 AM UTC-4, Christian Stump wrote:
or replacing the almost 50 is_??? by
has_property(???), including antisymmetric which should rather be
is_antisymmetric
I think this is a terrible pattern. There is nothing wrong with having lots
of methods, Python
Let me try to draw a consensus (in fact I believe it's already there),
The day I learn how to say things like that with a straight face I will
enter politics :-P
(1) Per se, adding semantic information to Sage is a good thing (e.g.
+1
(1') It's interesting to explore what can possibly be
If I had a method like that to code and if I were unable to find a good
name for it, I just wouldn't include it. Because this function can be
written in three lines, so it's not very bad if it is not already written.
sizes = {}
for cc in g.connected_components():
sizes[len(cc)] =
Thanks Nicolas for clearing up the discussion! in general, I agree
with your statements, though
to (5): I do still find the overhead here negligible, so I am not
volunteering in the very near future.
to (6) and as well to Nathann's similar complaint: agreed, what about
I think this is a terrible pattern. There is nothing wrong with having
lots of methods, Python works just fine. Whereas a monolithic
has_property(foo) method is difficult to write, document, and maintain
precisely because it goes against the OOP spirit---its a procedural design
On 2013-06-22, Volker Braun vbraun.n...@gmail.com wrote:
--=_Part_5_26369588.1371859450149
Content-Type: text/plain; charset=ISO-8859-1
http://www.python.org/dev/peps/pep-0318/
On Friday, June 21, 2013 1:43:13 PM UTC-7, Dima Pasechnik wrote:
Why does one even need a decorator in
One could add a special keyword argument to disable the wrapping in
CombinatorialMap and just use the decorator to add it to the registry. Its
a viable optimization. But I don't see a need for that unless there is any
need for it.
So, let me sum it up, and correct me if I am wrong
I did read the source before posting on the subject, and your message makes
no sense in that context.
* Decorators have their place.
* A non-decorator way to add maps to the database should be added
eventually.
* Premature optimizations are bad.
--
You received this message because
On Fri, Jun 21, 2013 at 09:48:32AM +0200, Nathann Cohen wrote:
And yet my preacher tells me that God's cosmic plan makes sense. This guy's
crazy.
On Fri, Jun 21, 2013 at 08:05:36AM -0700, Volker Braun wrote:
I did read the source before posting on the subject, and your message makes
no sense
On 2013-06-20, Volker Braun vbraun.n...@gmail.com wrote:
--=_Part_2218_21876941.1371741153226
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, June 20, 2013 12:17:48 AM UTC-7, Simon King wrote:
And this should really not be done on the level of the method being
registered.
http://www.python.org/dev/peps/pep-0318/
On Friday, June 21, 2013 1:43:13 PM UTC-7, Dima Pasechnik wrote:
Why does one even need a decorator in Simon's proposal?
http://www.python.org/dev/peps/pep-0318/
I think a decorator like this makes the code unreadable, and if it can
be avoided then
Helloo !
1) Does this really slow things down in any significant way, or could a
universal implementation of it in many objects do so? (Where significant
might have different tolerances for different people.)
I don't think that it currently does slow anything down very much, but what
I
Hello !
First of all, before ranting about speed someone should measure the slow
down. If I remember correctly, we already did it once with Christian and
the
slow down was less than 10% which is in my opinion perfectly acceptable.
If an
error was made, it is that we didn't keep any trace of
It certainly will change Sage positively completely independently from
find_stat. We definitely need to tag combinatorial maps to know for
example
whether they are injective surjective of bijective..
You do, and I said in a previous email that something like that could be
achieved by
Hi!
On 2013-06-20, Nathann Cohen nathann.co...@gmail.com wrote:
And I can also add to this comment that you can actually implement this
feature using decorators at no cost, because you can do this without
changing the function at all. If you want a decorator that does that
On 2013-06-19, Nathann Cohen nathann.co...@gmail.com wrote:
--20cf301ee7a5191d5204df850b33
Content-Type: text/plain; charset=ISO-8859-1
Hello everybody !
I just noticed in today's release the presence of two tickets that I had
missed while they were being reviewed, and I really
On 2013-06-20, Simon King simon.k...@uni-jena.de wrote:
Hi!
On 2013-06-20, Nathann Cohen nathann.co...@gmail.com wrote:
And I can also add to this comment that you can actually implement this
feature using decorators at no cost, because you can do this without
changing the function at all.
First of all, before ranting about speed someone should measure the slow
down. If I remember correctly, we already did it once with Christian and
the
slow down was less than 10% which is in my opinion perfectly acceptable.
If an
error was made, it is that we didn't keep any trace of
On Thursday, June 20, 2013 12:17:48 AM UTC-7, Simon King wrote:
And this should really not be done on the level of the method being
registered. There should be a database of useful combinatorial maps, and
the decorator should do nothing more than adding a method to this
database.
But
On Thursday, June 20, 2013 7:37:07 AM UTC-7, Stefan wrote:
Nathann's complaint about the out-of-control growth of methods of the
Graph object is a very valid issue
I think we talked about that a few months ago. One should first evaluate
whether all / most methods really make sense for all
On Wednesday, June 19, 2013 11:20:39 PM UTC-7, Nathann Cohen wrote:
sage: from sage.combinat.combinatorial_map import combinatorial_map
sage: class C:
: @combinatorial_map
: def a(self,x):
: return x+1
Thats not a benchmark, thats masturbating
Thats not a benchmark, thats masturbating over the call overhead.
Volker, could you please read aloud the sentence which followed
immediately this example of code ?
That's a 3x in a non-existing case, which make it almost negligible
for any application, and that is not even my point. WHY should
On Thursday, June 20, 2013 8:33:47 AM UTC-7, Nathann Cohen wrote:
WHY should this
thing be implemented like that when there are non-intrusive ways to
make find_stat work ?
Please propose a mechanism that
* Only occupies a single line of code
* Outside of the method body, so it is
Dear all,
Thanks Nathann for starting the discussion (though I sometimes think that
being a little less aggressive wouldn't hurt).
Let me start with what the positive sides of a combinatorial_map decorator
are for us (and I think several of the combinat people do agree here):
- we obtain a
Having said that, the gals and guys responsible for #14734 and #14732 are
at
Sagedays 49 now, go and buy them the necessary amount of beer to have
all this sorted out :-)
Or other beverage as appropriate :) The shrillness level has gotten a
little higher than really necessary,
On Thursday, June 20, 2013 5:59:55 PM UTC+2, kcrisman wrote:
Or other beverage as appropriate :) The shrillness level has gotten a
little higher than really necessary, certainly than customary on this list.
Does your comment apply in particular to my last post? I certainly did not
want to
Hellooo !!
Thanks Nathann for starting the discussion (though I sometimes think that
being a little less aggressive wouldn't hurt).
Yes, sorry about that. But it takes a lifetime to get people to admit the
most elementary things. I mean, my first message contained two lines
Hello !
Please propose a mechanism that
* Only occupies a single line of code
I propose that we immediately strip Sage's sources of all its `\n`
* Outside of the method body, so it is separated from the actual
implementation
I propose that we shuffle the lines of each file, and keep it
Or other beverage as appropriate :) The shrillness level has gotten a
little higher than really necessary, certainly than customary on this list.
Does your comment apply in particular to my last post? I certainly did
not want to be shrill - sorry if that was your impression when reading
On Thursday, June 20, 2013 9:34:48 AM UTC-7, Nathann Cohen wrote:
More seriously, wouldn't changing the decorator to something that
registers the method and not change it do the trick
There decorator performs two functions currently:
1) label the method as a combinatorial map
2) transform
Volker Braun wrote:
Right now there is not really anything, thats a question of
what the find_stat roadmap is.
But I don't see a need for that unless there
is any need for it.
+1
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are
kcrisman wrote:
The shrillness level has gotten a
little higher than really necessary, certainly than customary on this list.
We haven't seen illustrations of the effect of the @bushy_tail
decorators yet... :P
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You
What exactly is your objection?
* Is the to_partition() method too obscure that nobody / too few people
have a use for it?
* Is the decorator overhead (which is just a constant factor, that is, the
same complexity) too much?
* Do you object, in principle, to anything that uses more than the
Hellooo !
What exactly is your objection?
Mainly, that the addition of a code in Sage could be justified by saying
that it is needed by a third-party software, even though it has no use in
Sage. That's my main objection.
* Is the to_partition() method too obscure that nobody / too few
On Wednesday, June 19, 2013 12:37:03 PM UTC-7, Nathann Cohen wrote:
What exactly is your objection?
Mainly, that the addition of a code in Sage could be justified by saying
that it is needed by a third-party software, even though it has no use in
Sage. That's my main objection.
If that
If that is the case then why are you writing a rambling page-long post
about
speed penalty of decorators?
_
Volker, did you fail to notice that an email can make several points at
once ? I mean, how come you reduced my 1000 lines to one sentence saying
something that I never claimed ?
On Wednesday, June 19, 2013 1:25:22 PM UTC-7, Nathann Cohen wrote:
But I am pretty sure that my point was mostly that decorators are not
adapted in this situation, and that it can apparently be rewritten more
efficiently.
Everything can be rewritten more efficiently, just at a cost in code
Everything can be rewritten more efficiently, just at a cost in code size /
maintainability and human effort. Much like Python itself, decorators are a
way to make code smaller and easier to read for humans, at a certain
performance penalty. Don't optimize for speed until profiling showed that
I confess that I did not understand Nathan's objection, not being
familiar with find_stat or the kind of decorator used in that added
function. But I myself have added functions to Sage to help a
separate project which uses Sage, namely the lmfdb (see
http://www.lmfdb.org/).The cost to Sage
Indeed, the whole reason many of us do any work on Sage is to help our
research projects. The principle of helping Sage to help our individual
mathematical pursuits is actually what makes it consistently stronger as a
system.
Find Stat is a great tool for the community, and I think there are
Having read this (and the tickets), I guess I have three questions.
1) Does this really slow things down in any significant way, or could a
universal implementation of it in many objects do so? (Where significant
might have different tolerances for different people.)
2) Does the change to
On Wednesday, June 19, 2013 1:57:11 PM UTC-7, Nathann Cohen wrote:
I am glad to know that there is a general-purpose rule to tell me that
I should refrain from thinking.
Au contraire, I'm trying to encourage you to think. And the most important
rule about building fast software is to find
On Wed, Jun 19, 2013 at 03:02:27PM -0700, kcrisman wrote:
Having read this (and the tickets), I guess I have three questions.
1) Does this really slow things down in any significant way, or could a
universal implementation of it in many objects do so? (Where significant
might have different
On Wednesday, June 19, 2013 6:35:42 PM UTC-4, fhivert wrote:
On Wed, Jun 19, 2013 at 03:02:27PM -0700, kcrisman wrote:
Having read this (and the tickets), I guess I have three questions.
1) Does this really slow things down in any significant way, or could a
universal
I agree with Nathan's comments: if the find_stat decorators are adding
significant overhead then they need to be looked at.
As Volker said, however, before we start this conversation we should
profile them to find out what the cost is (unlike Floent I would not find a
10% slow-down
On 6/19/13 10:20 AM, Nathann Cohen wrote:
But then whenever some addition must be made to find_stat's
combinatorial maps there must be a corresponding Sage function, and I
think that adding functions to Sage just because find_stat needs them is
really going too far.
As a hypothetical, what if
On Jun 19, 12:37 pm, Nathann Cohen nathann.co...@gmail.com wrote:
If I see a code that does unnecessary computations and if there is a way to
improve it, I try to make this improvement.
Sorry, could not resist remembering lines from you patch on #13747
like
(e for e in level)
later replaced
58 matches
Mail list logo
