On 16 Aug, 22:50, William Stein <wst...@gmail.com> wrote: > On Mon, Aug 16, 2010 at 2:32 PM, Bill Hart <goodwillh...@googlemail.com> > wrote: > > Is there even a link from which Sympow can be downloaded so that one > > can look through the code to see if it is worth salvaging. I can't > > even find a webpage for Mark Watkins at the moment, let alone sympow. > > > I honestly suspect that Mark has just moved on to other projects. I > > doubt very much if his work on Magma precludes him from maintaining > > this package. I've personally worked with him on projects since he > > joined the Magma group and we both made use of each other's code > > without even asking the question. > > The above is just speculation without even asking him.
I'll email him, as I speak to him quasi-regularly by email. And I know for a fact he has been working on other things. I personally worked on them with him, and he discussed other projects he's done too. I don't think I speculated in any of the three sentences here. But I will explicitly ask him about the status of sympow. > > > But, we should be more selective when including packages. > > No new packages ever again :-) Is that the official policy or were you joking. I actually don't know what the current policy is, though I think I saw a not too old version of it some time not too long ago, which significantly toughened the restrictions for new packages. > > > IMHO, from > > the start, sympow should have been merged to become part of a larger > > library of functionality, though to be honest, I'm not quite sure > > where it exactly belongs. I don't think it belongs in flint as such. > > Maybe Pari? > > And whose going to do this work? You? John's original question was about whether a rewrite of the particular functionality we want from sympow was warranted. Isn't this rather the point of the thread? And no, I am not personally planning to rewrite sympow. I have never used it and it isn't really important for me at the present time. I might become more interested over the next few years, but I'm not currently interested. > > > I'm also really wondering why cephes is in Sage. Unless there are two > > packages with the same name, it was last updated circa 1994 and uses > > non-portable long doubles. We've booted packages from Sage for much > > less felonious offences. > > Cephes is in Sage because it's absolutely critical for the Windows port. You mean you used it in the Cygwin port? Doesn't the inclusion of an old package like this with no maintainer potentially cause more maintenance problems for people down the line. Isn't this the lesson we are learning from sympow? Or am I missing that it now has a more recent version maintained by someone and it no longer uses long doubles. > > > Is there a modularity problem here? I always thought that given Sage > > sees itself as more of a distribution (like linux) than a single > > project, > > Sage is not more of a distribution than a single project. Sage is: > > 1. A distribution > 2. Unified interfaces to math software > 3. A new library and math software system, > > with the single guiding goal to "create a viable free open source > alternative to Magma, Maple, Mathematica, and MATLAB." Ok. > > > then all but a very small number of core libs should be able > > to be added/removed from Sage at the flick of a switch. > > This is not even true of Linux distributions. Even the most minimal > ubuntu install still has tons of packages... or at least a lot more > then "a very small number". But I think packages in a linux distribution have prerequisites, and if you install one, the prereqs get installed too (e.g. using apt- get). I'm not seeing that happening with the sage spkgs. And I don't know if that is possible or technically feasible. But I am asking the question. > > > It sure would've made a Windows port easier! > > Programs that aren't Sage are easier to port to Windows :-). > You might try porting SPD to Windows instead, which would > be easier.http://github.com/certik/spd The primary difficulty in porting Sage is in porting the C libraries Sage relies on. SPD probably just doesn't include them. Looking at the project now....... ....OK. I see, it is based on Sage, but has a more modular install system, just like what I've been advocating, and the base install is 60mb and builds in 10 minutes. But unless I am mistaken, unlike Sage it is geared more towards scientific computation than just general mathematics. Good idea, but it misses on an important criteria for me. Having said that, it might be a good place to *start* on a true Sage port to Windows. At least it excises a functional component of Sage, though IMHO it would be better if more such "components" were "excised", which is what I guess I was advocating, i.e. modularity. Hey someone "forked" Sage. Quick, call the lawyers! This is outrageous. Those f**kers!! > > > Is it too late to fix the spkg > > system to be more modular. Is there even an efficient method in Python > > of conditionally including code based on availability of prereqs? I > > know this exists at some levels, for example GMP vs MPIR or NTL vs > > FLINT or zn_poly vs FLINT vs Pari for Z/nZ[x], etc. But this only > > seems to be where one library can substitute for another, which is > > rare. Could this be extended and still efficient? For example I don't > > think you want to be checking in Python whether you have GMP loaded > > every time you go to add two integers together. But then maybe with > > the possibility of a choice between MPIR and GMP at the spkg level, > > GMP/MPIR should be viewed as essential to Sage and thus a core lib? > > Maybe ALL the libraries in Sage are considered core and only those > > packages which are optional spkgs are considered truly.... optional. > > Correct. I take it this refers to the last sentence, meaning that a minimal Sage will always be all of Sage standard. IMHO this makes it harder for Sage to grow in certain ways.... > > > If so, I think the core is potentially unwieldy and > > It's not unwieldy, but it is difficult to wield. > > > may be > > contributing to some of the maintenance issues..... > > Sage is definitely contributing to the maintenance issues of Sage. > I mean the lack of modularity is contributing. But I've made this point before and it all just got sent to sage-flame. So I won't continue making it here. Back to what I was doing.... > > > > > > Bill. > > > On 16 Aug, 13:55, John Cremona <john.crem...@gmail.com> wrote: > >> On 16 August 2010 13:38, Dr. David Kirkby <david.kir...@onetel.net> wrote: > > >> > On 08/16/10 11:51 AM, John Cremona wrote: > > >> >> The spkg sympow (Mark Watkins's C library for computing symmetric > >> >> power L-functions, which applications) is causing more and more > >> >> problems (see #9705 for example) > > >> > John, > > >> > I think you mean #9703 - #9705 looks unrelated to SYMPOW to me. > > >> Correct. (Eyesight not what it was...) > > >> John > > >> > #9166 (Cygwin related) is another relevant ticket, though there's > >> > probably > >> > more information on #9703. > > >> > Dave > > >> > -- > >> > To post to this group, send an email to sage-devel@googlegroups.com > >> > To unsubscribe from this group, send an email to > >> > sage-devel+unsubscr...@googlegroups.com > >> > For more options, visit this group at > >> >http://groups.google.com/group/sage-devel > >> > URL:http://www.sagemath.org > > > -- > > To post to this group, send an email to sage-devel@googlegroups.com > > To unsubscribe from this group, send an email to > > sage-devel+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/sage-devel > > URL:http://www.sagemath.org > > -- > William Stein > Professor of Mathematics > University of Washingtonhttp://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
