[sage-devel] make style of documentation consistent with sagemath.org
Hi folks, This subject has been raised before, but I want to revive it in case anyone wants update on the issue. Ticket #9850 [1] has three patches that aims to make the visual style of the Sage standard documentation consistent with the theme used by the Sage website. So far, the patches have received positive review. If anyone wants to preview the new theme that will be used by default in the Sage documentation, see the URL http://mvngu.googlecode.com/hg/9850-new-style/en/index.html It's important we get ticket #9850 into the upcoming alpha release to iron out anything people find uncomfortable/annoying about, and get lots of feedback on, the new theme. [1] http://trac.sagemath.org/sage_trac/ticket/9850 -- Regards Minh Van Nguyen -- 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
[sage-devel] Re: Using valgrind to find segfaults
On 3 Nov., 06:29, Bill Hart wrote: > [...] > Firstly, thank you to all the people who took the time to work on > putting the new MPIR and Pari into Sage. > > (By the way, I don't understand why MPIR has been updated to 2.1.2 and > not 2.1.3 which fixes a serious bug in the mpf functions. Nor do I > understand why MPIR has been updated and the thread for this hasn't > been closed. Also FLINT hasn't been updated, even though I explicitly > stated it isn't safe to build the old flint against the new MPIR.) Em, we haven't yet upgraded MPIR in Sage (see #8664), it's still 1.2.2. (I recently sent you and thempirteam an e-mail regarding the [rather trivial] exec stack problem of MPIR 2.1.x with Fedora 14. I couldn't find it on mpir-devel, and MPIR's trac was down.) Hopefully we'll get the new MPIR into an early alpha of 4.6.1, but there's still work to do to make /upgrading Sage/ work with that, since currently not all dependent parts of the /Sage library/ get automatically properly rebuilt. I think we made a step forward with the 4.6 release, since now at least dependent /spkgs/ get rebuilt. W.r.t. 2.1.3, somebody else said we're currently not using any of the mpf functions in Sage. > Anyhow, whilst reading the long Pari trac ticket, and associated > tickets, a few things stood out to me (a C programmer) that just might > not be obvious to everyone. Apologies if this is already known to > everyone here. > > At some point the new Pari + new MPIR caused a segfault in one of the > doctests. Now, segfaults are in some ways the easiest types of bugs to > track down. Here's how: > > You simply compile the relevant C libraries with gcc -g (this adds > symbol information and line numbers to the compiled libraries). Next, > you run the program valgrind. You don't need to do anything to run > this program. It just works. > > If you normally type "blah" at the command line to run your program, > just type "valgrind blah" instead. It will take much longer to run > (usually 25-100 times longer), but it will tell you precisely which > lines of the C code caused the segfault and if it was reading or > writing to an invalid memory address at the time! Its output is a bit > like a stack trace in Python. > > Note you can actually do all this with a Sage doctest, because after > all, Sage is just a program you run from the command line. > > Once you find out which lines of C code the segfault occurs at, you > can put a trace in to see if the data being fed to the relevant > function is valid or not. This tells you if the library is at fault or > your higher level Python/Cython code is somehow responsible for > feeding invalid data (e.g. some C object wasn't initialised). > > Once upon a time, Michael Abshoff used to valgrind the entire Sage > test suite and fix all the myriad bugs that showed up! > > So valgrind is the bug hunters friend. > > A second observation, made by Leif I think, is spot on. This all quite > possibly shows up a problem with insufficient doctesting in Sage. > > Now the MPIR test code is pretty extensive and really ought to have > picked up this bug. We put a lot of time into the test code for that > MPIR release, so this is unfortunate. > > However, the entire Pari test suite and the entire Sage test suite > (with an older version of Pari) passed without picking up this pretty > serious bug in the MPIR division code! > > I think this underscores something I have been saying for a long time. > Sage doesn't test the C libraries it uses well enough. As a result of > that, it is taking inordinate amounts of developers' time to track > down bugs turned up by Sage doctests when spkg's are updated. In some > cases there is actually woefully inadequate test code in the C library > itself. But even when this is not the case, it makes sense for Sage to > do some serious testing before assuming the library is bug free. This > is particularly easy to do in Python, and much harder to do at the > level of the C library itself, by the way. > > I have been saying this for a very long time, to many people. *ALL* > mathematical libraries are broken and contain bugs. If you don't test > the code you are using, it *is* broken. The right ratio of test code > to code is really pretty close to 50/50. And if you think I don't do > this myself when I write code (even Sage code), well you'd be wrong. > > One solution would be for everyone to test more widely. If you write > code that depends on feature Y of module X and module X doesn't > properly test feature Y, assume it is broken and write doctests for > that code as well as the code you are writing yourself. > > To give an example, Andy Novocin and I have been working on new > polynomial factoring code in FLINT for a couple of years now. Around 6 > months ago we had a long test of some 100,000 or so polynomials > factoring correctly. We also had a long test of some 20 odd very > difficult polynomials factoring correctly. Thus there was no reason at > all to suppose there we
[sage-devel] Re: Cellular Automata Tools
That sounds amazing. Assuming enough people submitted often enough, it would be the best screensaver ever. If there were enough users for it to be real-time it would be even cooler. On Nov 2, 5:43 pm, Jason Grout wrote: > On 11/2/10 7:22 PM, William Stein wrote: > > > > > > > > > > > On Tue, Nov 2, 2010 at 5:15 PM, Hypercube wrote: > >> Some examples of CA usage: > > >> -cryptography,http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=338094 > >> -pseudo-random number > >> generators,http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=31545 > >> -modelling of certain chemical > >> reactions,http://search.ieice.org/bin/summary.php?id=e85-a_9_2093 > >> -traffic flow > >> modelling,http://cat.inist.fr/?aModele=afficheN&cpsidt=3141169 > >> -quantum dot > >> cells,http://en.wikipedia.org/wiki/Quantum_dot_cellular_automaton > >> -fluid simulations,http://en.wikipedia.org/wiki/Lattice_gas_automaton > > >> There does seem to be much skepticism towards cellular automata > >> (Wolfram's outrageous claims have played no small part in this), but > >> they certainly have some real-world applications, and are also an > >> interesting theoretical model for computation and computational > >> complexity. > > > Plus they provide many cool pictures and screen savers to zone out on. > > What more could you ask for ? > > Crazy idea: the Sage screen saver > > up-to-date visualizations of research from around the world people are > doing in Sage. Anyone can submit visualizations of their current > research and a short blurb and contact information. The screen saver > downloads a bunch of these (or maybe the database of these things is > distributed with Sage and updated every release), and displays the > visualization (animated or not), blurb, and contact info for the person. > > Sage Screen Saver: The new way to find cool exciting research! > > Thanks, > > Jason -- 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
[sage-devel] Re: Cellular Automata Tools
Yes, they are very cool to look at. My favourite is Rule 90. On Nov 2, 5:22 pm, William Stein wrote: > On Tue, Nov 2, 2010 at 5:15 PM, Hypercube wrote: > > Some examples of CA usage: > > > -cryptography,http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=338094 > > -pseudo-random number > > generators,http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=31545 > > -modelling of certain chemical > > reactions,http://search.ieice.org/bin/summary.php?id=e85-a_9_2093 > > -traffic flow modelling,http://cat.inist.fr/?aModele=afficheN&cpsidt=3141169 > > -quantum dot > > cells,http://en.wikipedia.org/wiki/Quantum_dot_cellular_automaton > > -fluid simulations,http://en.wikipedia.org/wiki/Lattice_gas_automaton > > > There does seem to be much skepticism towards cellular automata > > (Wolfram's outrageous claims have played no small part in this), but > > they certainly have some real-world applications, and are also an > > interesting theoretical model for computation and computational > > complexity. > > Plus they provide many cool pictures and screen savers to zone out on. > What more could you ask for ? > > > 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 > > athttp://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
[sage-devel] Using valgrind to find segfaults
Hi all, I've been down with the flu for a few days and so amusing myself in ways that don't make my head hurt too much. So, for fun, I just read through the *very* long trac ticket for getting the new Pari into Sage. Firstly, thank you to all the people who took the time to work on putting the new MPIR and Pari into Sage. (By the way, I don't understand why MPIR has been updated to 2.1.2 and not 2.1.3 which fixes a serious bug in the mpf functions. Nor do I understand why MPIR has been updated and the thread for this hasn't been closed. Also FLINT hasn't been updated, even though I explicitly stated it isn't safe to build the old flint against the new MPIR.) Anyhow, whilst reading the long Pari trac ticket, and associated tickets, a few things stood out to me (a C programmer) that just might not be obvious to everyone. Apologies if this is already known to everyone here. At some point the new Pari + new MPIR caused a segfault in one of the doctests. Now, segfaults are in some ways the easiest types of bugs to track down. Here's how: You simply compile the relevant C libraries with gcc -g (this adds symbol information and line numbers to the compiled libraries). Next, you run the program valgrind. You don't need to do anything to run this program. It just works. If you normally type "blah" at the command line to run your program, just type "valgrind blah" instead. It will take much longer to run (usually 25-100 times longer), but it will tell you precisely which lines of the C code caused the segfault and if it was reading or writing to an invalid memory address at the time! Its output is a bit like a stack trace in Python. Note you can actually do all this with a Sage doctest, because after all, Sage is just a program you run from the command line. Once you find out which lines of C code the segfault occurs at, you can put a trace in to see if the data being fed to the relevant function is valid or not. This tells you if the library is at fault or your higher level Python/Cython code is somehow responsible for feeding invalid data (e.g. some C object wasn't initialised). Once upon a time, Michael Abshoff used to valgrind the entire Sage test suite and fix all the myriad bugs that showed up! So valgrind is the bug hunters friend. A second observation, made by Leif I think, is spot on. This all quite possibly shows up a problem with insufficient doctesting in Sage. Now the MPIR test code is pretty extensive and really ought to have picked up this bug. We put a lot of time into the test code for that MPIR release, so this is unfortunate. However, the entire Pari test suite and the entire Sage test suite (with an older version of Pari) passed without picking up this pretty serious bug in the MPIR division code! I think this underscores something I have been saying for a long time. Sage doesn't test the C libraries it uses well enough. As a result of that, it is taking inordinate amounts of developers' time to track down bugs turned up by Sage doctests when spkg's are updated. In some cases there is actually woefully inadequate test code in the C library itself. But even when this is not the case, it makes sense for Sage to do some serious testing before assuming the library is bug free. This is particularly easy to do in Python, and much harder to do at the level of the C library itself, by the way. I have been saying this for a very long time, to many people. *ALL* mathematical libraries are broken and contain bugs. If you don't test the code you are using, it *is* broken. The right ratio of test code to code is really pretty close to 50/50. And if you think I don't do this myself when I write code (even Sage code), well you'd be wrong. One solution would be for everyone to test more widely. If you write code that depends on feature Y of module X and module X doesn't properly test feature Y, assume it is broken and write doctests for that code as well as the code you are writing yourself. To give an example, Andy Novocin and I have been working on new polynomial factoring code in FLINT for a couple of years now. Around 6 months ago we had a long test of some 100,000 or so polynomials factoring correctly. We also had a long test of some 20 odd very difficult polynomials factoring correctly. Thus there was no reason at all to suppose there were *ANY* bugs in the polynomial factoring code or any of the functions it made use of. By Sage standards I think this is an insane level of testing. But I insisted that every function we have written have its own test code. This has meant 6 months more work (there was something like 40,000 lines of new code to test). But I cannot tell you how many new serious bugs (and also performance problems too) that we turned up. There must be dozens of serious bugs we've fixed, many of which would have led to incorrect factorisations of whole classes of polynomials. The lesson for me was: just because my very extensive 5 or 6 doctests passed for the very complex ne
[sage-devel] Re: Version numbers of sage_scripts, extcode, examples, sagenb
On 3 Nov., 05:35, leif wrote: > On 2 Nov., 21:55, François Bissey wrote: > > > > > > This is a topic which I already touched in the "Merging tickets into > > > sagenb" thread, but I believe the discussion was not finished. > > > > Currently, every new Sage version has a new version of the following > > > spkgs: sage, sage_scripts, extcode, examples. However, it is likely > > > that not all those spkgs change in every version. > > > > So my proposal would be: > > > * Only update these spkgs whenever the actual code changes. Use the > > > Sage version as version number. This means that sage-4.6.1.alpha1 may > > > contain extcode-4.6.1.alpha0.spkg if extcode is not updated in > > > sage-4.6.1.alpha1. > > > * Also add sagenb to the list of spkgs handled this way. > > > > How to implement: > > > * Simplify sage-sdist such that it does not package sage_scripts, > > > extcode, examples (or make a sage-sdist-light script which does this). > > > * Merge sage_scripts, extcode, examples in the merger script. > > > As far as I am concerned it would nice not to bump packages more than > > necessary. > > +N > > > In the case of sage_script I believe the sage banner is updated > > to reflect the version each time. Otherwise there are little changes > > usually. > > We're currently [hopefully] addressing this at #9433, i.e. having the > version number outside of the Sage scripts repo. (Completely > incidentally, #9434 is related. Both are still a bit work in progress > though, slightly dragging.) > > > If you want to go that route, I would suggest that the versioning of these > > packages should be completely separate from the sage spkg, same as the > > notebook. > > +1 > > > My own opinion of course. > > No, mine too. P.S.: I must admit I haven't yet reasoned much about the impact this would have on trac (tickets); perhaps both more structure *and* confusion... -Leif -- 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
Re: [sage-devel] Should Sage have a list of priorities, based on its mission statement?
On Tue, Nov 2, 2010 at 5:04 AM, David Kirkby wrote: > If Sage were a commercial software product, a set of priorities would > be set, and people told to work on those things that are most > important. If people did not agree to work on them, they would > probably lose their job. > > Clearly in an open-source project like Sage, any attempt to tell > people what they must work on would not be acceptable. > > But there should perhaps be a happy medium, where a list of priorities > for Sage were set, listing the most important features in the > commercial products that Sage either lacks, or is significantly > poorer. People who wanted to contribute to Sage could then look at > that list, and see what's considered high priority and interesting to > them. Such priorities should be based on what would be most useful to > the majority of people, even if there were of absolutely no interest > to William or any other Sage developer. > > I'm not saying this would be a perfect solution, but one > semi-objective way of doing this would be to look at the Mathematica > documentation, and see what functions existed in early versions, and > what has been added more recently. Clearly that would not be perfect - > some things that are pretty important may not have been possible with > the computing power available 20 years ago. > > Another idea might be to prioritise things that get lot of hits on Google > > Bessel function - About 20,200,000 results > zeta function - About 443,000 result > > Another idea might be to look at the importance given to topics on Wikipedia's > > http://en.wikipedia.org/wiki/Category:Top-Priority_mathematics_articles > > Or the frequently viewed mathematics pages on Wikipedia. > http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Mathematics/Wikipedia_1.0/Frequently_viewed > > Another might be to look at the number of books written about a topic. > > What I'm basically trying to say is have a list of priorities, based > on an objective criteria, rather than those of any individuals > research interests. > > Although of no interest to me, I suspect Windows support and Financial > modeling tools would be pretty important to a large number of > potential users. I think your idea to come up with a list of priorities is very valuable. Harald has done some surveys in the past, which created a lot of data that could feed into such a list. What are some examples in other open source projects? The mongodb project has surveys of their top 5 devel priorities, though I can't find their page right now. http://python.org/ has a survey on the right right now about "I wish there was Python 3 support in _." For sage, we made such a list of "high priority issues" on trac in May/June: http://trac.sagemath.org/sage_trac/wiki/stab1 Most are done, but a few remain. The non-notebook ones are: Sage startup time: #8254 Upgrade cvxopt: #6456 which both have packages/patches. My current personal main desire for Sage is to make it into a solid high quality "bug free" core on which to build other more cutting edge unstable code (such as psage: http://code.google.com/p/purplesage/). To me this means fixing bugs, and making the referee process even more careful. So instead of being against "bug fix only releases", I'm starting to want "only bugfix releases" :-). Of course, I think another key to this is that Sage also be easily installable as a standalone Python library, which will require interesting new build development (it's a technical challenge). -- William > > 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 > -- William Stein Professor of Mathematics University of Washington http://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
[sage-devel] Re: Version numbers of sage_scripts, extcode, examples, sagenb
On 2 Nov., 21:55, François Bissey wrote: > > This is a topic which I already touched in the "Merging tickets into > > sagenb" thread, but I believe the discussion was not finished. > > > Currently, every new Sage version has a new version of the following > > spkgs: sage, sage_scripts, extcode, examples. However, it is likely > > that not all those spkgs change in every version. > > > So my proposal would be: > > * Only update these spkgs whenever the actual code changes. Use the > > Sage version as version number. This means that sage-4.6.1.alpha1 may > > contain extcode-4.6.1.alpha0.spkg if extcode is not updated in > > sage-4.6.1.alpha1. > > * Also add sagenb to the list of spkgs handled this way. > > > How to implement: > > * Simplify sage-sdist such that it does not package sage_scripts, > > extcode, examples (or make a sage-sdist-light script which does this). > > * Merge sage_scripts, extcode, examples in the merger script. > > As far as I am concerned it would nice not to bump packages more than > necessary. +N > In the case of sage_script I believe the sage banner is updated > to reflect the version each time. Otherwise there are little changes usually. We're currently [hopefully] addressing this at #9433, i.e. having the version number outside of the Sage scripts repo. (Completely incidentally, #9434 is related. Both are still a bit work in progress though, slightly dragging.) > If you want to go that route, I would suggest that the versioning of these > packages should be completely separate from the sage spkg, same as the > notebook. +1 > My own opinion of course. No, mine too. -Leif -- 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
[sage-devel] why are there two copies of the Sage library in devel/sage/build?
Refereeing #9967 has turned into implementing some of its key features, and I need to know more about how the Sage library is built by SAGE_ROOT/devel/sage/setup.py. I know that it creates a symlink from SAGE_ROOT/local/lib/python/site-packages to a build directory. What I eventually want is for the build process to not create a symlink and go straight to that directory, but in the meantime, I see that SAGE_ROOT/devel/sage/build has three directories which each seem to include a copy of the Sage library: dr...@sagenb:~/s/sage-4.6/devel/sage-main/build$ du -s -h * 147Mlib.linux-x86_64-2.6 182Msage 168Mtemp.linux-x86_64-2.6 They seem to be independent copies. Why are they there? Which one is the "real" one that's used when Sage is running? (And, most importantly for #9967, how do we get setup.py to use the correct directory directly? Changing SITE_PACKAGES in setup.py didn't seem to work.) Thanks, Dan -- --- Dan Drake - http://mathsci.kaist.ac.kr/~drake --- signature.asc Description: Digital signature
Re: [sage-devel] virtual machines on boxen.math
Hi, I'd be happy to help configure a pair of images. I have the most experience with Ubuntu and CentOS (though it's been a couple years with CentOS), wouldn't have a problem getting any of them up and running. Cheers, Geoff Ehrman Grad Student, Dept. of Mathematics University of New Hampshire http://euclid.unh.edu/~ehrman On Tue, Nov 2, 2010 at 9:48 PM, William Stein wrote: > Hi, > > I have a new faster laptop with a lot more RAM (8GB, woot), so it's > suddenly become much easier for me to install Linux into VirtualBox's > in my spare time in the background. So I'm going to be adding > VirtualBox images to boxen for the following OS's: > > CentOS-5.5-i386 > CentOS-5.5-x86_64 > Fedora-13-i686 > Fedora-13-x86_64 > debian-506-amd64 > debian-506-i386 > ubuntu-10.10-desktop-amd64 > ubuntu-10.10-desktop-i386 > > I do not want to spend much time configuring and maintaining them > myself though! Does anybody want to help? > Basically, I would turn the machine on, and give you an account with > sudo permissions, and hope you can add build tools, add the machine to > Mitesh's buildbot. What else is critical to do? > > I'll then turn off the existing very old versions of the above OS's, > which are currently being served on boxen. > > -- William > > > -- > William Stein > Professor of Mathematics > University of Washington > http://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 > -- 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
[sage-devel] virtual machines on boxen.math
Hi, I have a new faster laptop with a lot more RAM (8GB, woot), so it's suddenly become much easier for me to install Linux into VirtualBox's in my spare time in the background. So I'm going to be adding VirtualBox images to boxen for the following OS's: CentOS-5.5-i386 CentOS-5.5-x86_64 Fedora-13-i686 Fedora-13-x86_64 debian-506-amd64 debian-506-i386 ubuntu-10.10-desktop-amd64 ubuntu-10.10-desktop-i386 I do not want to spend much time configuring and maintaining them myself though! Does anybody want to help? Basically, I would turn the machine on, and give you an account with sudo permissions, and hope you can add build tools, add the machine to Mitesh's buildbot. What else is critical to do? I'll then turn off the existing very old versions of the above OS's, which are currently being served on boxen. -- William -- William Stein Professor of Mathematics University of Washington http://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
Re: [sage-devel] Re: Blog Post: "How to referee Sage Trac tickets"
On Tue, Nov 2, 2010 at 1:03 AM, Johan S. R. Nielsen
wrote:
> Very nice. Will this be put somewhere persistent where new Sage
> developers can be expected to find it? E.g. as a supplement to the
> Developer's Guide.
I encourage somebody to add it!
Here's the raw html, if that is helpful:
http://wstein.org/edu/2010/581d/notes/2010-11-01.html
William
>
> I have one comment: In the current version, sage.misc.misc.deprecation
> has some steep limitations. Trac #9919 (along with #9907) fixes it so
> it can be used on non-function callables (e.g. methods). Trac #9907
> moves it to sage.misc.decorators.deprecation. Trac #9976 patches
> Sphinx so decorated callables in general will not have their signature
> reduced to a generic one in the documentation. These tracs depend on
> each other in that order and they all need review (hint hint).
> Especially the relocation of the decorator should perhaps be kept in
> mind for the blog entry.
>
> Cheers, Johan
>
> On Nov 1, 11:30 am, Jason Grout wrote:
>> On 11/1/10 12:23 AM, William Stein wrote:
>>
>> >http://sagemath.blogspot.com/2010/10/how-to-referee-sage-trac-tickets...
>>
>> Nice. I'll have more comments later, but I did notice that this:
>>
>> from sage.misc.misc import deprecation
>> deprecation("function_name is deprecated, using new_function_name instead!")
>>
>> came out in formatting wrong (the second line looks like this in my
>> firefox (3.6.12, osx snow leopard):
>>
>> deprecation("function_name is deprecated, using new
>>
>> Also, you may want to put in the Sage version number to give people a
>> clue about when to remove the function (see the second argument to
>> deprecation).
>>
>> Thanks,
>>
>> Jason
>
> --
> 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 Washington
http://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
[sage-devel] Re: Cellular Automata Tools
On 11/2/10 7:22 PM, William Stein wrote: On Tue, Nov 2, 2010 at 5:15 PM, Hypercube wrote: Some examples of CA usage: -cryptography, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=338094 -pseudo-random number generators, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=31545 -modelling of certain chemical reactions, http://search.ieice.org/bin/summary.php?id=e85-a_9_2093 -traffic flow modelling, http://cat.inist.fr/?aModele=afficheN&cpsidt=3141169 -quantum dot cells, http://en.wikipedia.org/wiki/Quantum_dot_cellular_automaton -fluid simulations, http://en.wikipedia.org/wiki/Lattice_gas_automaton There does seem to be much skepticism towards cellular automata (Wolfram's outrageous claims have played no small part in this), but they certainly have some real-world applications, and are also an interesting theoretical model for computation and computational complexity. Plus they provide many cool pictures and screen savers to zone out on. What more could you ask for ? Crazy idea: the Sage screen saver up-to-date visualizations of research from around the world people are doing in Sage. Anyone can submit visualizations of their current research and a short blurb and contact information. The screen saver downloads a bunch of these (or maybe the database of these things is distributed with Sage and updated every release), and displays the visualization (animated or not), blurb, and contact info for the person. Sage Screen Saver: The new way to find cool exciting research! Thanks, Jason -- 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
Re: [sage-devel] Re: Cellular Automata Tools
On Tue, Nov 2, 2010 at 5:15 PM, Hypercube wrote: > Some examples of CA usage: > > -cryptography, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=338094 > -pseudo-random number generators, > http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=31545 > -modelling of certain chemical reactions, > http://search.ieice.org/bin/summary.php?id=e85-a_9_2093 > -traffic flow modelling, http://cat.inist.fr/?aModele=afficheN&cpsidt=3141169 > -quantum dot cells, > http://en.wikipedia.org/wiki/Quantum_dot_cellular_automaton > -fluid simulations, http://en.wikipedia.org/wiki/Lattice_gas_automaton > > There does seem to be much skepticism towards cellular automata > (Wolfram's outrageous claims have played no small part in this), but > they certainly have some real-world applications, and are also an > interesting theoretical model for computation and computational > complexity. Plus they provide many cool pictures and screen savers to zone out on. What more could you ask for ? > 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 Washington http://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
[sage-devel] Re: Cellular Automata Tools
Some examples of CA usage: -cryptography, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=338094 -pseudo-random number generators, http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=31545 -modelling of certain chemical reactions, http://search.ieice.org/bin/summary.php?id=e85-a_9_2093 -traffic flow modelling, http://cat.inist.fr/?aModele=afficheN&cpsidt=3141169 -quantum dot cells, http://en.wikipedia.org/wiki/Quantum_dot_cellular_automaton -fluid simulations, http://en.wikipedia.org/wiki/Lattice_gas_automaton There does seem to be much skepticism towards cellular automata (Wolfram's outrageous claims have played no small part in this), but they certainly have some real-world applications, and are also an interesting theoretical model for computation and computational complexity. -- 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
[sage-devel] Re: Cellular Automata Tools
On Nov 2, 4:07 am, David Kirkby wrote: > > It would be rather embarrising for Steven Wolfram if Sage could do the > stuff in Mathematica 1000x faster. Not really. In this regard he would show ease of programming and neatness of display, not speed. > > > Their importance in Mathematica per se is probably for curiosity. No > > applications except as a random number generator. > > Well, there are a number of things for which no applications currently > exist, but are useful from a theoretical point of view. Several seem > to think the fact Steven Wolfram's rule 110 is Turing complete, i.e., > capable of universal computation, is important. This is irrelevant to a computer system. Either rule 110 is Turing complete or it is not. It doesn't change the program, or anyone's use of it. .. snip.. > > > You can bet that if there were significant applications, there would > > be > > support for CA in Matlab. > > MATLAB seems to be aimed at solving practical science/engineering > problems, rather than theoretical issues like Turing machines. So it's > no surprise to me that MATLAB does not have this. As I just said, "solving" theoretical issues is irrelevant to Mathematica users. > > "Hypercube" said Cellular automata have proved to be a useful tool > for modeling discrete systems in various applications, According to ??? Hypercube seems to have no first-hand experience. > so he thought > it could be useful to a wide scope of researchers. I've got no idea > how true that claim is, but if true it would suggest it would be > useful in Sage. Certainly unlikely, given past history. > -- 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
Re: [sage-devel] Version numbers of sage_scripts, extcode, examples, sagenb
> This is a topic which I already touched in the "Merging tickets into > sagenb" thread, but I believe the discussion was not finished. > > Currently, every new Sage version has a new version of the following > spkgs: sage, sage_scripts, extcode, examples. However, it is likely > that not all those spkgs change in every version. > > So my proposal would be: > * Only update these spkgs whenever the actual code changes. Use the > Sage version as version number. This means that sage-4.6.1.alpha1 may > contain extcode-4.6.1.alpha0.spkg if extcode is not updated in > sage-4.6.1.alpha1. > * Also add sagenb to the list of spkgs handled this way. > > How to implement: > * Simplify sage-sdist such that it does not package sage_scripts, > extcode, examples (or make a sage-sdist-light script which does this). > * Merge sage_scripts, extcode, examples in the merger script. > As far as I am concerned it would nice not to bump packages more than necessary. In the case of sage_script I believe the sage banner is updated to reflect the version each time. Otherwise there are little changes usually. If you want to go that route, I would suggest that the versioning of these packages should be completely separate from the sage spkg, same as the notebook. My own opinion of course. Francois -- 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
Re: [sage-devel] How does the Symbolic Ring work (in particular: new_Expression_from_GEx)
On Tue, Nov 2, 2010 at 12:15 PM, koffie wrote: > return new_Expression_from_GEx(self._parent, > g_hold2_wrapper(g_power_construct, self._gobj, g_ex1_2, hold)) > > Can someone help with this? It returns a new Expression (sage.symbolic.expression.Expression) object that corresponds to a GiNaC/Pynac object (second argument) with a given parent (first argument). It's just a constructor for Expression like Expression.__init__, except that it takes a pointer to a C++ object. --Mike -- 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
Re: [sage-devel] Trac: no space left on device
On 2 November 2010 17:35, Jeroen Demeyer wrote: > On 2010-11-02 16:44, Willem Jan Palenstijn wrote: >> At a guess I'd say /sagenb is causing this? At least a 'find | wc -l' there >> took longer to complete than I cared to keep it running... > 3667802 > > real 25m9.316s > user 0m10.780s > sys 1m41.000s > > That's 3.6 million files in /sagenb 3.6 million does not seem a lot of files to me in this day and age. On my machine, almost doubt that for /export/home. drkir...@hawk:/export/home# time find . | wc -l 6899446 real36m51.862s user0m11.468s sys 1m12.535s That however users a 128 bit ZFS file system. I don't know what limits there are on inodes, but I know that fully populating a 128-bit ZFS storage pool would, require more energy than that needed to boil the oceans. http://blogs.sun.com/bonwick/entry/128_bit_storage_are_you 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
[sage-devel] How does the Symbolic Ring work (in particular: new_Expression_from_GEx)
Hej All, I was trying to do some work on: http://trac.sagemath.org/sage_trac/ticket/9129 The problem seems to be in the .sqrt functiontion for symbolic ring elements. The source code is: return new_Expression_from_GEx(self._parent, g_hold2_wrapper(g_power_construct, self._gobj, g_ex1_2, hold)) But I get stuck here since I have no clue what new_Expression_from_GEx does (it doesn't have a docstring and I'm not able to figure it out by source code alone.) Can someone help with this? -- 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
Re: [sage-devel] Trac: no space left on device
There are definitely tools to do this sort of automated checking, but if you're only concerned with inode usage then a simple shell script run as a periodic cronjob is the most straightforward solution imho. On Tue, Nov 2, 2010 at 1:20 PM, David Kirkby wrote: > On 2 November 2010 15:52, Jeroen Demeyer wrote: > > On 2010-11-02 16:44, Willem Jan Palenstijn wrote: > >> At a guess I'd say /sagenb is causing this? At least a 'find | wc -l' > there > >> took longer to complete than I cared to keep it running... > > > > Could this also explain the recent slowness of http://www.sagenb.org/ ? > > I would personally doubt it - I would expect errors, not slowness if > there are no inodes left. > > ext3 file systems are not immune to fragmentation issues. Certainly > running low on disk space could cause the file system to become very > fragmented, which would reduce speed. > > Systems like trac failing due to lack of disk space seem quite a > common occurrence. It might be worth investigating some tools which > will send an email if a system is unreachable, or disk space is > getting too close to the maximum. I'm sure there are tools for this, > but if not a cron job with a few lines of code cooud send an email > when disk usage gets close to ithe limits. > > -- > 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
Re: [sage-devel] Trac: no space left on device
On 2010-11-02 16:44, Willem Jan Palenstijn wrote: > At a guess I'd say /sagenb is causing this? At least a 'find | wc -l' there > took longer to complete than I cared to keep it running... 3667802 real25m9.316s user0m10.780s sys 1m41.000s That's 3.6 million files in /sagenb -- 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
Re: [sage-devel] Trac: no space left on device
On 2 November 2010 15:52, Jeroen Demeyer wrote: > On 2010-11-02 16:44, Willem Jan Palenstijn wrote: >> At a guess I'd say /sagenb is causing this? At least a 'find | wc -l' there >> took longer to complete than I cared to keep it running... > > Could this also explain the recent slowness of http://www.sagenb.org/ ? I would personally doubt it - I would expect errors, not slowness if there are no inodes left. ext3 file systems are not immune to fragmentation issues. Certainly running low on disk space could cause the file system to become very fragmented, which would reduce speed. Systems like trac failing due to lack of disk space seem quite a common occurrence. It might be worth investigating some tools which will send an email if a system is unreachable, or disk space is getting too close to the maximum. I'm sure there are tools for this, but if not a cron job with a few lines of code cooud send an email when disk usage gets close to ithe limits. -- 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
Re: [sage-devel] Trac: no space left on device
On 2010-11-02 16:44, Willem Jan Palenstijn wrote: > At a guess I'd say /sagenb is causing this? At least a 'find | wc -l' there > took longer to complete than I cared to keep it running... Could this also explain the recent slowness of http://www.sagenb.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
Re: [sage-devel] Trac: no space left on device
On Tue, Nov 02, 2010 at 04:24:41PM +0100, Jeroen Demeyer wrote: > On 2010-11-02 16:18, Willem Jan Palenstijn wrote: > > Possible options I can think of: > > > > * the filesystem could be out of inodes rather than out of space. (Use 'df > > -i') > > That's the issue, on boxen: > $ df -i > FilesystemInodes IUsed IFree IUse% Mounted on > /dev/sda14481024 4378857 102167 98% / > > This usually happens when you have a lot of small files and the file > system is not specifically formatted for this. I don't immediately see > how to solve this without taking boxen offline. At a guess I'd say /sagenb is causing this? At least a 'find | wc -l' there took longer to complete than I cared to keep it running... -Willem Jan -- 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
Re: [sage-devel] Trac: no space left on device
On 2010-11-02 16:18, Willem Jan Palenstijn wrote: > Possible options I can think of: > > * the filesystem could be out of inodes rather than out of space. (Use 'df > -i') That's the issue, on boxen: $ df -i FilesystemInodes IUsed IFree IUse% Mounted on /dev/sda14481024 4378857 102167 98% / This usually happens when you have a lot of small files and the file system is not specifically formatted for this. I don't immediately see how to solve this without taking boxen offline. Jeroen. -- 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
Re: [sage-devel] Trac: no space left on device
On Tue, Nov 02, 2010 at 07:42:51AM -0700, William Stein wrote: > On Tuesday, November 2, 2010, David Kirkby wrote: > > On 2 November 2010 00:10, William Stein wrote: > >> On Mon, Nov 1, 2010 at 5:07 PM, Jeroen Demeyer > >> wrote: > >>> Hi, I just got the following error on Trac: > >>> > >>> Oops? > >>> Trac detected an internal error: > >>> > >>> OSError: [Errno 28] No space left on device: > >>> '/var/trac/sage_trac/attachments/ticket/7513' > >> > >> That's annoying. ? This was caused by me working on upgrading the sage > >> install on boxen (which is still at 4.5). > >> It's odd, since the disk advertises having 11GB free, so there must be > >> some files locked, and not being given back. > >> Anyways, I deleted the temp space I was using for this, and now trac > >> should work again. > > > > I believe you might be using snapshots. Look at the possibility that > > the space is used by them is not reported in the "norma" l way. > > > > No snapshots are beingvused for / on boxen. It is just standard ext3. > One can use lsof to trac down while space isn't being returned. Free space doesn't include space used by unlinked files, as far as I know, so if df still reports 11GB free, it is maybe something else. Possible options I can think of: * the filesystem could be out of inodes rather than out of space. (Use 'df -i') * blocks reserved for the superuser (5% by default on ext2/ext3) -Willem Jan -- 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
Re: [sage-devel] Trac: no space left on device
On Tuesday, November 2, 2010, David Kirkby wrote: > On 2 November 2010 00:10, William Stein wrote: >> On Mon, Nov 1, 2010 at 5:07 PM, Jeroen Demeyer >> wrote: >>> Hi, I just got the following error on Trac: >>> >>> Oops… >>> Trac detected an internal error: >>> >>> OSError: [Errno 28] No space left on device: >>> '/var/trac/sage_trac/attachments/ticket/7513' >> >> That's annoying. This was caused by me working on upgrading the sage >> install on boxen (which is still at 4.5). >> It's odd, since the disk advertises having 11GB free, so there must be >> some files locked, and not being given back. >> Anyways, I deleted the temp space I was using for this, and now trac >> should work again. > > I believe you might be using snapshots. Look at the possibility that > the space is used by them is not reported in the "norma" l way. > No snapshots are beingvused for / on boxen. It is just standard ext3. One can use lsof to trac down while space isn't being returned. > 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 > -- William Stein Professor of Mathematics University of Washington http://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
Re: [sage-devel] Re: Cellular Automata Tools
On 2 November 2010 12:49, Jason Grout wrote: > On 11/2/10 6:07 AM, David Kirkby wrote: >> >> If Sage is ever to become a viable alternative to Mathematica, then it >> really needs the features of that program. > > > I think early on, there was a distinction made between focusing on having > parity of features with other programs and having the features users really > care about. The attitude here was that instead of looking at other programs > and saying, "What do they have that we don't have?" we look at the *people* > using those programs and say "What do we not have that you really want?" Before going to this in any detail, see my second post on a related topic, "Should Sage have a list of priorities, based on its mission statement?" where I elaborate a bit more. > Sage becomes an alternative because it implements the features the people > need (whether or not other programs have those features), not because it has > feature-parity with other programs. Yes, I'm not disagreing - but again I think I covered this in better detail in my other post, which. It might be better to reply to that directly. > You sort of say this too in your post. I just wanted to highlight it. I certainly do not disagree with you. Dave > > Thanks, > > Jason > > > -- > 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
[sage-devel] Re: Cellular Automata Tools
On 11/2/10 6:07 AM, David Kirkby wrote: If Sage is ever to become a viable alternative to Mathematica, then it really needs the features of that program. I think early on, there was a distinction made between focusing on having parity of features with other programs and having the features users really care about. The attitude here was that instead of looking at other programs and saying, "What do they have that we don't have?" we look at the *people* using those programs and say "What do we not have that you really want?" Sage becomes an alternative because it implements the features the people need (whether or not other programs have those features), not because it has feature-parity with other programs. You sort of say this too in your post. I just wanted to highlight it. Thanks, Jason -- 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
[sage-devel] Should Sage have a list of priorities, based on its mission statement?
If Sage were a commercial software product, a set of priorities would be set, and people told to work on those things that are most important. If people did not agree to work on them, they would probably lose their job. Clearly in an open-source project like Sage, any attempt to tell people what they must work on would not be acceptable. But there should perhaps be a happy medium, where a list of priorities for Sage were set, listing the most important features in the commercial products that Sage either lacks, or is significantly poorer. People who wanted to contribute to Sage could then look at that list, and see what's considered high priority and interesting to them. Such priorities should be based on what would be most useful to the majority of people, even if there were of absolutely no interest to William or any other Sage developer. I'm not saying this would be a perfect solution, but one semi-objective way of doing this would be to look at the Mathematica documentation, and see what functions existed in early versions, and what has been added more recently. Clearly that would not be perfect - some things that are pretty important may not have been possible with the computing power available 20 years ago. Another idea might be to prioritise things that get lot of hits on Google Bessel function - About 20,200,000 results zeta function - About 443,000 result Another idea might be to look at the importance given to topics on Wikipedia's http://en.wikipedia.org/wiki/Category:Top-Priority_mathematics_articles Or the frequently viewed mathematics pages on Wikipedia. http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Mathematics/Wikipedia_1.0/Frequently_viewed Another might be to look at the number of books written about a topic. What I'm basically trying to say is have a list of priorities, based on an objective criteria, rather than those of any individuals research interests. Although of no interest to me, I suspect Windows support and Financial modeling tools would be pretty important to a large number of potential users. 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
[sage-devel] Version numbers of sage_scripts, extcode, examples, sagenb
This is a topic which I already touched in the "Merging tickets into sagenb" thread, but I believe the discussion was not finished. Currently, every new Sage version has a new version of the following spkgs: sage, sage_scripts, extcode, examples. However, it is likely that not all those spkgs change in every version. So my proposal would be: * Only update these spkgs whenever the actual code changes. Use the Sage version as version number. This means that sage-4.6.1.alpha1 may contain extcode-4.6.1.alpha0.spkg if extcode is not updated in sage-4.6.1.alpha1. * Also add sagenb to the list of spkgs handled this way. How to implement: * Simplify sage-sdist such that it does not package sage_scripts, extcode, examples (or make a sage-sdist-light script which does this). * Merge sage_scripts, extcode, examples in the merger script. Jeroen. -- 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
Re: [sage-devel] Re: Cellular Automata Tools
On 2 November 2010 02:17, rjf wrote: > Cellular automata of the sort that Wolfram talks about can be > implemented > in languages other than Mathematica much more efficiently. Maybe > 10,000 > times faster when I wrote some stuff in lisp. Not for doing anything > useful, > just a speed competition. It would be rather embarrising for Steven Wolfram if Sage could do the stuff in Mathematica 1000x faster. > Their importance in Mathematica per se is probably for curiosity. No > applications except as a random number generator. Well, there are a number of things for which no applications currently exist, but are useful from a theoretical point of view. Several seem to think the fact Steven Wolfram's rule 110 is Turing complete, i.e., capable of universal computation, is important. > Almost without exception, the reviews by technical experts of > Wolfram's NKS were in > the range from hostile to merely negative. My own thoughts, for what they are worth are: * His excessive use of the word "I" was really irritating. * Several people have pointed out that a lot of what he claims is his own were worked out long before him. * Excessively verbose * An excessive number of rather boring diagrams. * An overly exagerated claim of the importance of his work. * His boast that he sat down for a decade and worked on his own, whilst ignoring what others were doing, seems ones of stupidity rather than good science. I'm aware of someone who posts on sci.math.symbolic who done some interesting work, yet he had no access to any libraries or the internet for decades, due to the contruy he lived in. Given his circumstances, I can understand if some of his work is not new. But Wolfram seems to not have looked at the literature, which seems rather stupid to me. > You can bet that if there were significant applications, there would > be > support for CA in Matlab. MATLAB seems to be aimed at solving practical science/engineering problems, rather than theoretical issues like Turing machines. So it's no surprise to me that MATLAB does not have this. > There's no particular downside in including CA stuff in Sage; just > speculation that something > more useful could be done by "Hypercube" instead. "Hypercube" said Cellular automata have proved to be a useful tool for modeling discrete systems in various applications, so he thought it could be useful to a wide scope of researchers. I've got no idea how true that claim is, but if true it would suggest it would be useful in Sage. If Sage is ever to become a viable alternative to Mathematica, then it really needs the features of that program. That said, I would tend to think Sage lacks more important things. IMHO, the fact Sage can't read data from laboratory test instruments and plot it in real time like MATLAB is far more of an omission than the lack of CA support. But if "Hypercube" is interested in CAs, and not in reading data from lab instruments, there's no point in him working on the latter. 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
[sage-devel] 3 documentation tickets suitable for beginning contributors
Hi folks, The following are three documentation tickets needing review: * #10143 Bring 2D plotting up to 100% doctest coverage (except plot.py) http://trac.sagemath.org/sage_trac/ticket/10143 * #9655 Add an example plotting spherical harmonics to spherical_plot3d's docstring http://trac.sagemath.org/sage_trac/ticket/9655 * #10197 typo in Sage documentation article: "Elliptic Curves -- Three Lectures about Explicit Methods in Number Theory" http://trac.sagemath.org/sage_trac/ticket/10197 These tickets are suitable for new contributors to Sage or anyone who wants to get into Sage development. If a new contributor takes on any of the above tickets, I promise to act as a mentor and guide you through your first contribution to Sage. -- Regards Minh Van Nguyen -- 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
Re: [sage-devel] Trac: no space left on device
On 2 November 2010 00:10, William Stein wrote: > On Mon, Nov 1, 2010 at 5:07 PM, Jeroen Demeyer wrote: >> Hi, I just got the following error on Trac: >> >> Oops… >> Trac detected an internal error: >> >> OSError: [Errno 28] No space left on device: >> '/var/trac/sage_trac/attachments/ticket/7513' > > That's annoying. This was caused by me working on upgrading the sage > install on boxen (which is still at 4.5). > It's odd, since the disk advertises having 11GB free, so there must be > some files locked, and not being given back. > Anyways, I deleted the temp space I was using for this, and now trac > should work again. I believe you might be using snapshots. Look at the possibility that the space is used by them is not reported in the "norma" l way. 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
Re: [sage-devel] Re: Blog Post: "How to referee Sage Trac tickets"
Hi Johan, On Tue, Nov 2, 2010 at 7:03 PM, Johan S. R. Nielsen wrote: > Very nice. Will this be put somewhere persistent where new Sage > developers can be expected to find it? E.g. as a supplement to the > Developer's Guide. Excellent idea. If you open a ticket and upload a patch, I promise to review it. -- Regards Minh Van Nguyen -- 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
[sage-devel] Re: Blog Post: "How to referee Sage Trac tickets"
Very nice. Will this be put somewhere persistent where new Sage
developers can be expected to find it? E.g. as a supplement to the
Developer's Guide.
I have one comment: In the current version, sage.misc.misc.deprecation
has some steep limitations. Trac #9919 (along with #9907) fixes it so
it can be used on non-function callables (e.g. methods). Trac #9907
moves it to sage.misc.decorators.deprecation. Trac #9976 patches
Sphinx so decorated callables in general will not have their signature
reduced to a generic one in the documentation. These tracs depend on
each other in that order and they all need review (hint hint).
Especially the relocation of the decorator should perhaps be kept in
mind for the blog entry.
Cheers, Johan
On Nov 1, 11:30 am, Jason Grout wrote:
> On 11/1/10 12:23 AM, William Stein wrote:
>
> >http://sagemath.blogspot.com/2010/10/how-to-referee-sage-trac-tickets...
>
> Nice. I'll have more comments later, but I did notice that this:
>
> from sage.misc.misc import deprecation
> deprecation("function_name is deprecated, using new_function_name instead!")
>
> came out in formatting wrong (the second line looks like this in my
> firefox (3.6.12, osx snow leopard):
>
> deprecation("function_name is deprecated, using new
>
> Also, you may want to put in the Sage version number to give people a
> clue about when to remove the function (see the second argument to
> deprecation).
>
> Thanks,
>
> Jason
--
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
