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 part
packages tracked. I personally also would like to track usage of major Sage
components, so there is no penalty for developing within Sage instead as a
library.
I like how Volker thinks about the citation calls. Decorators are perhaps
really not optimal compared to function calls. In Cython, due to inlining,
the if (sage_citation_management_enabled) {} is truly the fastest thing.
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 _cite_pass(*bibs): pass. bib.libsingular is a function, which we do
not call in the citation statement, but only in _cite(*bibs). I think in
Python, you can't do better than empty calls and I really want to avoid
letting the user spell out the if statement - Citatation management should
be easy.
To summerize: Would it be feasible to replace decorators by function calls,
exploit Cython inlining and the above Python trick to make citations, if
deactivated, consume as little resources as possible? Then sprinkle the
citation calls in Sage, however, keep functionality in, say, a module
sage.citation?
Am Sonntag, 7. September 2014 18:24:48 UTC+2 schrieb Volker Braun:
>
> 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 call
> syntax is better is that, in Cython code, this can then be a C macro or
> inline function, avoiding an unnecessary stack frame. The citation tracking
> code can then be inside an
>
> if (unlikely(sage_citation_enabled)) {}
>
> which will be essentially for free due to branch prediction. I think 5%
> slowdown mentioned in
> http://sage-citation.blogspot.de/2011/08/awful-benchmarks.html is not
> desirable.
>
> Also, I don't really like the syntax
>
> @cites(citable_items.libsingular, citable_items.foo, citable_items.bar)
>
> how about staying a bit closer to LaTeX:
>
> cite(bib.libsingular, bib.foo, bib.bar)
>
> I also only skimmed #3317, can somebody convert that to a git branch?
>
>
>
>
> On Friday, September 5, 2014 2:07:25 PM UTC+1, Martin Raum wrote:
>>
>> Dear Sage-developer,
>>
>> I'm writing to get an impression on the communities opinion on how
>> citation management should be implemented. As a background, I should say
>> that I have taken it into my head to modernize citation management in Sage.
>> I personally find this very important, as it signalized respect to
>> projects we wrap. More objectively, I figure such facilities can be a
>> certain plus when writing the European Sage grant, as many such projects
>> (Pari, Gap, Singular, FLINT, etc.) are developed in Europe.
>>
>> Current status in Sage
>> ======================
>>
>> Mike Hansen implemented citation facilities in sage.misc.citations. This
>> is all we have.
>>
>> sage: from sage.misc.citation import get_systems
>> sage: get_systems("integrate(x^2,x,0,1)")
>> ['ginac', 'Maxima']
>>
>> His implementation uses profiling:
>> 1) run the given code under control of the profiler.
>> 2) parse the list of functions called, extracting the list of modules
>> called. For example, sage.libs.pari.
>> 3) Match this list against a certain list of projects, given in
>> sage/misc/citation.pyx
>>
>> Problems with the current implementation
>> ========================================
>>
>> I'm not trying to put Mike's code down. Actually, I'm really glade he
>> implemented what we currently have. I'm just saying where we can improve
>>
>> 1) Use of profiling implies that the code runs much slower. Tracing
>> citations for a toy computation may result in failure to pick the right
>> ones.
>> 2) For technical reasons, we miss functions written in Cython.
>> 3) The subsystems themselves don't tell the user how to cite them.
>> 4) The user is not being made aware of current functionality.
>> 5) The naming scheme could be improved. The interface is not user
>> friendly.
>>
>> Two solutions available
>> =======================
>>
>> We have three tickets dealing with. At #3317, there is old code by Niels
>> Ranosch, Michael Brickenstein, Burcin Erocal. It tries to take a
>> completely different approach. At #16777 and #16854, I have provided
>> improved versions of the current method.
>>
>> The issue
>> =========
>>
>> Burcin has correctly argued at #16854 that the profiling approach is not
>> capable of tracking decision trees inside a function. I.e., if a function
>> decides according to some parameter to either call Pari or FLINT, we can't
>> see this in the profiling.
>>
>> On the other hand, #3317 uses decorators, which have to be applied to
>> every function that requires citation management. Alternatively, one can
>> achieve the same by calling a certain function. In any event, this means
>> there will be a slight slow down of Sage in general.
>>
>> Implementation at #3317 is really fast already, but not optimal. If we go
>> for the decorators approach, I would speed it up.
>>
>> Question
>> ========
>>
>> So, what does the community think. Should we prefer the profiling or the
>> decorator approach? I'm calling for a vote, because I plan to get this
>> into Sage until, say, the end of this year.
>>
>> Best,
>> Martin
>>
>> PS: My personal vote is +1 decorators
>>
>>
--
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-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
