#16854: Add bibtex functionality to citation management
-------------------------------------+-------------------------------------
Reporter: mraum | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: sage-6.4
Component: misc | Resolution:
Keywords: | Merged in:
Authors: Martin Raum | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/mraum/citation_bibtex | 2ac77ee3936d9f156c43a8b6e5df8fc9bd18b720
Dependencies: #16777 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by burcin):
Replying to [comment:4 mraum]:
> The code there would require essential work, though.
True, it's been bitrotting for about 2 years.
> The author of #3317, however, did not accept that adding a new standard
spkg from scratch is not possible.
If we had made [http://pybtex.sourceforge.net/ pybtex] an optional package
then it wouldn't have been any trouble by now...
Are you suggesting that this limitation justifies reimplementing bibtex
functionality in Sage when it is already provided by a pure Python package
that is trivial to add to the distribution?
> The code also introduces decorators, which slow code down. He argued
that the slow down is minor and would have to be accepted. But the
community does not seem to agree.
IIRC (and it's been a few years since I looked at the code), the
decorators only introduce one string insertion in a Python set. That's one
hash table lookup, which is negligible compared to what Python goes
through for each function call.
Where do you get the idea that "the community does not seem to agree"?
> I thought about updating the code at #3317 for almost two month, and
started twice. But it is quite different from the profiling approach that
was taken by Mike Hansen. Overwriting code on a ticket is, I think,
incompatible with the basic idea of Trac as we currently use it. So I
opened a new ticket.
It might have helped to contact the authors on the ticket or comment on
the ticket directly.
The profiling approach is broken for several reasons:
* the code used for different problem sizes is often different.
Profiling a small example will not give you the correct information. If
you are really working on the cutting edge of what is computable, then you
don't want to run the whole computation under the profiler once more.
* you have to guess what is being used from the data obtained from the
profiler.
There is no clean way to associate citation information to functions this
way.
* it does not allow tracking more fine grained information than function
names.
If a Sage function wraps several algorithms by calling an external
package with different arguments, you cannot differentiate these.
I'd really like it if Sage improved it's citation capabilities and gave
more credit to authors of underlying packages and the papers describing
the algorithms used. Unfortunately, I don't think this is a step in that
direction.
--
Ticket URL: <http://trac.sagemath.org/ticket/16854#comment:6>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
