Dear Mathé,
Congratulations on almost finishing your thesis. I
trust it will just take a short stretch of time until you
succeed in fully finishing your thesis (code from an
unfinished thesis would be a bit of a red flag). I'll
give a bit of a general view of what the pros and cons of
including code in sagemath are.
Useful new contributions to computer algebra packages
come in many forms. I think two main categories are:
A) Algorithmic contributions -- an implementation of
some non-trivial algorithm (or suite of them) that allow
certain computations that would be hard to do without
them.
B) Infrastructure/interface contributions - parts of
the system that allow convenient and easy access to
algorithms, or sometimes allow for expressing computations
in a way that is closer to mathematics than what "raw"
access to algorithms would allow.
For A), a valuable contribution could be a new
algorithm, or an implementation of an existing algorithm.
The value can come from the implementation being much
faster/more efficient than other existing implementations
or simply from an implementation now being available from
sagemath where it first wasn't. Packaging and interfacing
with existing libraries can fall in this category too, It
helps if there are some "killer applications": things that
a lot of people agree on that are valuable to compute,
that can be done with the new contribution.
For B) I would think of things like implementing a new
ring type, or for instance scheme morphisms (the
underlying algorithm for most of the questions there is a
groebner basis algorithm), where a lot of the value can
come from being able to represent the morphism and the
system checking that the data is consistent. Here too, the
value comes from providing infrastructure that actually
gets used. So relevance for some "killer application"
comes in handy here too. There's a meta-level to B:
infrastructure for implementing such systems (that's where
sage's coercion framework and category framework come in)
For A) you can already make a useful contribution by
providing "raw" access to the algorithm: an API that
allows you to pass in the parameters exactly as the
implementation requires it. The icing on the cake is then
a small wrapper/translation layer that allows the input to
be specified in flexible forms that are convenient to the
user. Generally you want both: the convenience layer costs
overhead, so it's good if there's an option to strip it
out.
I would generally not recommend B) to a novice
contributor. It's where "good design" is of utmost
importance and where compatibility with other design
decisions in sage (themselves not necessarily optimal) is
important. Design that combines room for growth as well as
the room for fast code paths is also important. These are
particularly things where experience of a non-mathematical
nature is invaluable.
From what you describe, it sounds like your
contribution has an important B) component to it:
interface for ring of adeles. One way of implementing
those is by doing all computations in complete local
fields, and then the "adele ring" is mainly a tool for
administrating those computations. Are you doing something
different (it looks like you might, if you're actually
providing Zhat as a projective limit on its own)? Any
significant algorithmic components there? Part 3 sounds
like it, possibly.
One thing I'd be worried about for the B) design of
adelic rings is their close link to, in the geometric
case, function fields and the computation of their Picard
groups (and in the number field case too) It doesn't need
to be there in the first iteration, but it's worth paying
attention to the design so that no big roadblocks are
created.
Finally, what are your "killer applications"?
An option other than immediate incorporation into sage
would be to first let it live for a while as a separate
repository. You'll be more nimble in redesigning the
interface if it's necessary. Then, with more maturity and
proven audience interest, incorporation in sage is an easy
decision to make. It also establishes a consistency record
on your side, so that more regular sagemath contributors
aren't worried that this is a commit-and-run, where
someone checks in a piece of code with just the right
amount of work to get it past review and then isn't around
anymore to fix the little things that slipped through
review.
While it might seem that incorporation into sage is a
good way of protecting the package from withering away in
its own little repository, I think that doesn't actually
help too much: discoverability in sage is only there if
people know to look for it, and if it doesn't get used,
incorporation into sage only adds to the maintenance
burden. For you getting credit for the work: sure "code
accepted into SageMath" is an OK CV-item, but a separate
repo may actually provide better visibility of the code.
--
You received this message because you are subscribed to a
topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/15ALIvGHqYs/unsubscribe.
To unsubscribe from this group and all its topics, send an
email to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/67b380ee-aa2e-492f-b740-495fc91abe6dn%40googlegroups.com.
