On Thu, May 1, 2008 at 6:57 AM, Bill Hart <[EMAIL PROTECTED]> wrote:
> [stuff about docs]
IMHO the right thing to do regarding documenting algorithms is to write research
papers and books, e.g., like Henri Cohen has done.
> On the other hand, in the mean time, SAGE has become an enormous
> project (and quite a success story). The breadth of coverage is
> staggering as are all the neat internet tools, cython and all the
> other SAGE spinoffs.
>
> I do have some specific concerns about SAGE:
I have some remarks below that might help clarify some of your (all
valid) concerns,
which are informed by my "more involved" perspective.
> 1) The adequacy of test code to detect corner cases.
Same here. I hope people will write more test code. By the way, doctests
are not the only testing code in Sage
sage: T = tests.modsym()
sage: T.random()
will run random tests of modular symbols computations attempting
to find inconsistencies. I would like to greatly expand code like the above.
However, I view doctests as the obvious first thing you do before
you do much more extensive sophisticated testing.
Every user benefits from the doctests and they
are incredibly easy to write, and easy to teach other people how
to write.
> 2) The way SAGE handles exceptions and special cases when interfacing
> with some of the underlying packages.
This is a difficult problem. That Sage is able to get any reuse at all
out of underlying and external packages is already surprising. The
use of underlying packages is driven entirely by the goal of getting
stuff done today and fostering a spirit of community and collaboration.
The goal is that when using Sage one never *has* to think about
underlying packages (e.g., Maxima, GAP). Everything should have
a nice unified Python-ic interface.
> 3) The fact that mathematics is an expansive subject, thus there is no
> end in sight for what can be implemented.
What will be implemented is defined by the functionality that people
are very interested in actually using that somebody is also interested
in implementing and getting into Sage.
> Thus with still far too few
> people working on SAGE, there is little consolidation of what is
> already in SAGE. New volunteer effort usually focuses on implementing
> new functionality and often just makes the base wider rather than
> improving the quality of what is there. Of course this is also a
> strength of SAGE.
I think part of your misconception is because there are several rather
different stages to the evolution of Sage from start four years ago to world
domination. Michael Abshoff gave several concrete instances related
to this in his email.
> 4) The time and resources of a core group of SAGE volunteers is
> stretched thinner and thinner, largely on account of 3.
Yep, some people love working on Sage so much that they work on
Sage too much.
> 5) I *perceive* that there is an attitude of "I've implemented
> algorithm x in SAGE", when in reality all that has been done is that
> algorithm x was previously implemented by someone else in package K
> and merely *wrapped* trivially in SAGE. Please don't mistake my
> meaning here. There is a lot of original code in SAGE implementing
> actual algorithms, and I'm not criticising the attitude of the hard
> working volunteers who contributed that. Also understand I am not
> criticising the ideal of not reinventing the wheel, which is again a
> strength of SAGE. I'm talking about distinguishing more carefully what
> is wrapped and what is implemented. There is also a major difference
> between implementing an algorithm in SAGE which might take just a few
> lines, based on what is already in SAGE, and then optimising that
> functionality, which might take hundreds or thousands of lines.
People working on Sage
development have their eyes on a very specific goal which is
to create a viable open source free alternative to Maple, Magma,
Mathematica, and Matlab. With that as the goal, developers aren't
thinking "look how cool I am -- I just implemented XYZ"; much
more important is "look, we got XYZ working for Sage, since we
need XYZ in order to accomplish our goal ... OK, what next."
We are all on the same team.
This perspective is dramatically different than the FLINT
perspective, so I understand that it would be easy to misunderstand.
> 6) The performance of some functions really sucks, and quite often
> this is functions that have been implemented afresh. I think Tim Daly
> mentioned this.
The only way to fix this is for people to fix it. Fix it and send me a patch.
> There also seems to be little attempt at
> systematically monitoring performance and making sure that the
> algorithms in SAGE cover a wide range of input parameters and that the
> functions are not just efficient for the small examples in the doctest
> (which often just boil down to reducing python overhead).
I wish there were more. Work is underway in this direction though.
> No one is going to do this for you. The original "implementor" must take
> responsibility for testing, profiling and documentation of their code
> (build testing is a separate matter).
It's better to work with other people as a team. Don't
believe dogmatically that doing so isn't possible. Also, other
people are capable of amazing difficult superhuman tasks -- such
as "testing, profiling and documenting" even code that you wrote.
I'm not making this up.
> 7) New packages seem to be suggested for inclusion in SAGE on a
> regular basis. This just worries me. This conjures the image of
> ravening wolves who cannot wait to consume (wrap) more functionality
> in SAGE. This has some advantages for SAGE, but on the whole I think
> it starts to go too far at some point.
We do not include new packages willy nilly:
http://wiki.sagemath.org/spkg/InclusionProcedure
Anyway, this is another instance of Sage having several stages of development.
> 8) I have found the documentation somewhat unhelpful so far. From the
> point of view of someone who does not use python it is so far hard to
> get familiar with SAGE compared to a much simpler (and simplistic)
> package such as Pari for example, though it is probably comparable
> with learning how to use Magma effectively.
Learning Python is a prerequisite for using Sage. There is no way
around that. Sorry. (It's sort of like how learning C is a prerequisite
for using FLINTlib.)
> 9) There are many bugs in the trac which will never be fixed, some
> have been fixed or have become irrelevant, some should have been fixed
> a long time ago but have not, and the list grows ever longer, which is
> in itself worrying. I know mabshoff does an excellent job of fixing
> bugs related to build testing, but numerous other bugs seem to get
> little attention. The main focus seems to be on fixing bugs related to
> failing doctests. My honest gut feeling is that these could be
> multiplied ad infinitum if careful tests were carried out, and this
> concerns me. I hope I'm wrong about this.
We would love to have more bug reports!!!
William
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
