On Dec 10, 7:48 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 10, 2008 at 7:36 AM, Jason Grout
<SNIP>
> >> The ultimate goal should be to get code into Sage since there is
> >> nearly always common code to factor out and getting more users for
> >> some infrastructure bits in Sage has always improved that code. And if
> >> you apply the same demands to the contributed code as to Sage library
> >> code, i.e. 100% doctests and so on, you might as well get the code in
> >> the library itself. Obviously some people will likely disagree with me
> >> on the kitchen sink model :)
>
> > You had my intent right.
Ok, I didn't want to flame you :)
> > So you think having a "minimum_rank_bounds"
> > function on graphs and an associated file or two would be okay to be in
> > the Sage library?
>
> I don't see why not, as long as it is up to snuff code-quality wise. Just
> don't make it a function imported to the global namespace by default on
> startup of Sage.
I 100% agree, the trade off of not having the code in Sage is minimal.
There have been similar discussions on the Linux kernel mailing list
and in the end the consensus is for the kitchen sink model regarding
drivers. Very often some collection of obscure drivers has some common
infrastructure and as a result the code gets refactored and
consequently code quality improves. People who have to write similar
drivers end up using well debugged existing infrastructure code
instead of writing and maintaining their own implementation.
Transferring this to Sage I think there is a lot of potential for
cross fertilizations and the advantage of having something just there
for someone who needs it even if that group of users is a miniscule
percentage of Sage users it will still be a positive contribution to
Sage. This is clearly one of the key advantages of Sage that we can
take in somewhat specialized code, i.e. how many MMA, Maple or Magma
code libraries are out there that have been written for some old
release and no longer work and/or are a pain to use? I conjecture that
in the long term Sage will just hover up the good quality third party
implementations out there and by doing so make Sage stronger because
instead of downloading some code and either patching it in or doing
all kinds of funny stuff to get the code to do the right thing (think
non-technical grad student or absent minded professor) in Sage all you
need is version Sage x.y.z or later and it just works.
Another thing is that typically new code in Sage goes through various
stages and very often it takes someone to hit the code really hard to
start shaking out the bugs. I.e. the initial code works because the
author uses it in the way it is intended because the person wrote it.
Then code is merged, it passes doctests, but then all the sudden some
third party starts using the code and finds all kind of bugs, be it
correctness or performance. That is because a third party does plenty
of "dumb" things that the author of the code never considered doing
because it was obviously the wrong thing to do, didn't happen in that
use case, etc.
Think about the graph isomorphism code by Boyer. You threw all the
graphs with fewer than X vertices at it and low and behold you found
bugs, in the code as well as our bindings. Now someone else one day
who wants to use some graphs in their computations will have the
benefit of using a well debugged interface and library [once we fix
all the remaining open tickets :)], maybe even never realize that he/
she is using the planarity code because it is called from some other
higher level algorithm. I am sure that you will find plenty of people
who might think that all that graph library code in Sage is not very
important, but some of them will end up using that code.
Another example are the "tetration guys" - it seems like a rather
obscure area of mathematical research, but interacting with them has
already led to some design discussions and hopefully future
improvements for the power series code. That is a prime example of why
we want third party code in Sage. In this particular case it might
never get submitted or will mature outside the main tree for a long
time, but we can incorporate such code because the open source
community friendly model allows us to do so.
> > I don't think it would pass the "widely-needed"
> > criteria of a standard spkg. However, if people think it is interesting
> > enough to go into the Sage proper, then I have no objection. I'd have
> > to get the approval of the other developers, of course.
>
> > I think probably less than 10 research groups may use this code
> > currently. Those are people that we are actively exposing to Sage,
> > though :).
10 research groups is potentially a huge audience and many of those
people might start using Sage in teaching or influence other people to
use Sage :)
> A Sage build is over a gigabyte, involves well over 5 million lines of
> code, and is probably bigger than any other single math software
> system in the world. And amazingly we're doing fine size-wise. I
> think we can handle a few more hundreds of pages of hand-written
> Python code.
Yes, the secret goal here is world domination after all ;)
But I think Moore's law will protect us from ever growing faster in
relative terms than the computer's average ability. Just compare the
size of recent Sage releases and you will see that the average growth
rate of the tarball is slowing down. And if we ever reach a colossal
size that makes development cease or significantly slow down we can
always consider creating a smaller core of Sage for those who want it.
> william
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-support@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-support
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
