On Monday, September 8, 2014 6:32:33 PM UTC+1, Nils Bruin wrote:
There is an advantage to a decorator on python-level: If you're happy to
configure sage_citation_enabled at start-up (which means it would have to
be a command line option or an environment variable), you can make it
On Tuesday, September 9, 2014 5:48:59 AM UTC-7, Volker Braun wrote:
But that doesn't work at the C level, you either compile something in or
not. So you can't apply it to the (presumably) speed-critical c(p)def
functions, only to plain Python functions
True
where overhead wasn't much of
On Tuesday, September 9, 2014 4:44:33 PM UTC+1, Nils Bruin wrote:
In python, looking up a global flag is going to be relatively slow,
because, if addressed by its proper name, it involves checking several
__dict__s
Which is why it needs to be a cdef bool as I wrote earlier.
sage: sage:
On Tuesday, September 9, 2014 8:55:04 AM UTC-7, Volker Braun wrote:
On Tuesday, September 9, 2014 4:44:33 PM UTC+1, Nils Bruin wrote:
In python, looking up a global flag is going to be relatively slow,
because, if addressed by its proper name, it involves checking several
__dict__s
Thank you Bill for your input. You made me think of some aspects that will
be important. Still, let us first focus on getting some citation management
into Sage, and then work on it. As for Volker's question on what the goal
is: First step, and I think we agree that this desirable: Get third
On Monday, September 8, 2014 9:47:51 AM UTC+1, Martin Raum wrote:
For Python, because there is no inlining, I thought of a little hack. To
trigger citations call
sage.citation.cite(bib.libsingular)
Now, if citation is enabled, then cite = _cite(*bibs), and if not then cite
= def
On Sunday, September 7, 2014 9:24:48 AM UTC-7, Volker Braun wrote:
If you want to cite inside a decision tree then you can't do that with a
decorator. Instead of *also* having a function call syntax, we should then
*only* have function call syntax. Nothing good ever came out of having two
I really believe on general principles that if at all possible, something
like this should be zero penalty.
Burcin, I obviously don't think you are trying to slow Sage down. I'm sure
you know I always appreciate your efforts.
It sounds like this won't actually affect flint all that much, as
That also seems like a true option, in particular, because of the zero
penalty. Do you have an idea how to handle the problem that not citation
can be decided at function level (hence using decorators)?
Am Montag, 8. September 2014 19:32:33 UTC+2 schrieb Nils Bruin:
On Sunday, September 7,
On Sun, Sep 7, 2014 at 7:57 AM, Burcin Erocal bur...@erocal.org wrote:
On Sat, 6 Sep 2014 11:52:33 -0700 (PDT)
Bill Hart goodwillh...@googlemail.com wrote:
On Saturday, 6 September 2014 20:34:56 UTC+2, Robert Bradshaw wrote:
Note that Cython supports cProfile these days:
On Sat, 6 Sep 2014 11:52:33 -0700 (PDT)
Bill Hart goodwillh...@googlemail.com wrote:
On Saturday, 6 September 2014 20:34:56 UTC+2, Robert Bradshaw wrote:
Note that Cython supports cProfile these days:
http://docs.cython.org/src/tutorial/profiling_tutorial.html
However, that won't help
If you want to cite inside a decision tree then you can't do that with a
decorator. Instead of *also* having a function call syntax, we should then
*only* have function call syntax. Nothing good ever came out of having two
ways of achieving the same outcome. The other reason for why function
I'm also uncomfortable with sprinkling explicit citation management calls
everywhere. There are many many places that use external shared library
code. Apart from the potential slowdown and difficulty in maintaining the
code: You never going to get all of them. The source code for calling a
I don't have any concrete suggestions, but have some random personal
thoughts on the matter.
* I personally don't mind Pari being cited if flint actually performs a
computation. What I mean is, I'm not sure how important it is to look all
the way down the decision tree to see which package
On additional technical point.
The profiling approach need not slow Sage down.
The same approach is used in another project I'm aware of (not for citation
though). It takes samples at regular points during the computation, figures
out which function is currently being called and tallies the
On Saturday, September 6, 2014 5:44:57 PM UTC+1, Bill Hart wrote:
It takes samples at regular points during the computation
Thats the aforementioned http://trac.sagemath.org/ticket/16777. See that
ticket for technical obstacles of that approach.
--
You received this message because you are
Note that Cython supports cProfile these days:
http://docs.cython.org/src/tutorial/profiling_tutorial.html However,
that won't help too much as the real missing pieces are the calls from
Cython into the various C libraries.
I'm also -1 to an approach that slows down all of Sage to track this
The code for the profiler in the project I mentioned seems to have been
custom written for the project. You can see it here:
https://github.com/JuliaLang/julia/blob/master/src/profile.c
and here:
https://github.com/JuliaLang/julia/blob/master/base/profile.jl
There looks to be fairly good
On Saturday, 6 September 2014 20:34:56 UTC+2, Robert Bradshaw wrote:
Note that Cython supports cProfile these days:
http://docs.cython.org/src/tutorial/profiling_tutorial.html However,
that won't help too much as the real missing pieces are the calls from
Cython into the various C
19 matches
Mail list logo
