Re: [sage-combinat-devel] Bug in words: 'charge' gives the charge of the reversed word
Hi Jason,
Thanks for the detailed response! You are correct that I had some
unfortunate errors in my last message. Let me summarize my points
below, before responding in more detail. The two problems I have are
the following:
1. In sage, for t a tableau, t.charge() does not equal
t.to_word().charge(), in general.
Yes.
2. In sage, t.cocharge() is just not defined correctly.
Yes, and this is definitely a bug.
Here is a session which illustrates these points more clearly.
sage: t = Tableau([[1, 1, 2, 3], [2]]); t.pp()
1 1 2 3
2
sage: t.charge() # this good
2
sage: t.to_word() # this is good
word: 21123
sage: t.to_word().charge() # this is what I don't like
1
sage: t.charge?? # I want this to be self.to_word().charge()
...
return self.to_word().reversal().charge()
sage: t.cocharge() # This should be 2
1
sage: t.cocharge??
...
return self.to_word().charge()
In Macdonald's book, he would say that the word of the above tableau is
32112 (and not 21123). (Sorry I'm in Michigan and can't give a precise
reference right now, but it is in the section on transition matrices of
Hall polynomials, where he precisely defines charge.) I think this is
likely the source of the inconsistency in sage.
snip
I hope I have made this more clear in the example above. When sage
computes the charge of the word 21123 it gets 1. This is what I would
get if I computed the charge of the word 32113. It was when I looked at
the algorithm used by Word([2,1,1,2,3]).charge() that I realized that it
was performing precisely the calculations I would use to compute the
charge of 32112. Does this make more sense now? If not, please let me
know...
Yes, I take your point (except that you mean This is what I would
get if I computed the charge of the word 32112. (instead of 32113)).
I think your formula above is wrong.
The formula that works even if \mu is not a partition is
ch(t) + cc(t) = \sum_{ij} min(\mu_i, \mu_j)
Oh, I didn't know this. Thanks!
(See for example the paragraph after Equation (2.4) in
http://front.math.ucdavis.edu/9802.5111 ).
ch(t) + cc(t) = \sum_i (i-1) \mu_i
Yes, this was definitely what I meant. Sorry!
Ok, good. Then we agree.
Agreed. But I think it is (much) faster to define charge directly on
words. This can almost certainly be done more efficiently than repeated
insertions. (At least I believe this for words of partition content.
I'm less sure about the speed of cyclage versus the s_i operators.)
I agree that from the efficiency point of view the definition in terms
of words is probably better.
For the s_i you can use crystal operators. Or in any case, the same
bracketing kind of ideas.
I hope you can answer this now. Given that currently t.charge() !=
t.to_word().charge() and that we do *not* want to change the behavior of
t.charge() there are three options:
a) Do nothing and leave this inconsistency.
b) Change the behavior of t.to_word() to agree with the convention in
Macdonald's book. This would give t.charge() == t.to_word().charge()
for any t.
c) Change the behavior of Word(*).charge() to agree with the current
behavior of charge on tableaux so that t.charge() ==
t.to_word().charge() for any t.
I think (c) is the best option since I don't like the inconsistency, I
think Word(*).charge() is rarely used, and I think option (b) would be
completely impractical.
Definitely *not* (b) (this would also go the convention used in crystals).
Since I am usually only using charge on tableaux (not words), I do not
mind so much. But if you prefer (c), I will back you.
I think it would be a good idea to define the charge/cocharge of
tableaux for any content, not just partition content!
I definitely intend to do this!
Good!
Cheers,
Anne
PS: tab.completed!
--
You received this message because you are subscribed to the Google Groups
sage-combinat-devel group.
To post to this group, send email to sage-combinat-de...@googlegroups.com.
To unsubscribe from this group, send email to
sage-combinat-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sage-combinat-devel?hl=en.
Re: [sage-devel] Re: Attributes onto edges in sage graphs
Il 21/06/2010 09:14, Nathann Cohen ha scritto: It is ! O_O And I have to admit it would have required some time before I began to suspect such a thing may have come from the graph backends... Good work !!! :) I am adding Robert Miller in Cc as he will know better than anyone else which parts of the library would need to be updated to fix this. I think a small fix (mantaining different objects event if they are equals in contents) is a rapid solution, but a refactoring (mantaining two nx attributes, one for labels and one for sage attributes dicts with different archiving policyes) may be a better one. -- Michele Comignano Computer Science student University of Pisa, Italy -- 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: Attributes onto edges in sage graphs
Il 20/06/2010 23:52, Michele Comignano ha scritto:
The check_edge_label is where sage checks for equals labels in
http://hg.sagemath.org/sage-main/file/2cffe66bd642/sage/graphs/base/sparse_graph.pyx#l1
1318 #l1318 if edge_labels[l_int] == l:
My opinion about that: I would remove rows 1408 and 1409. Or, may be
better replace row 1318 with:
if id(edge_labels[l_int]) == id(l):
I applyed that patch to my sage installation and my previous sample got
working fine:
{'a': 10, 'b': 20}
label dictionary id: 0xafd4c64
{'a': 10, 'b': 25}
label dictionary id: 0xafd48ac
{'a': 10, 'b': 20}
label dictionary id: 0xafd4934
{'a': 10, 'b': 20, 'sometimes_duplicate': 0}
label dictionary id: 0xafd4c64
{'a': 10, 'b': 25, 'sometimes_duplicate': 1}
label dictionary id: 0xafd48ac
{'a': 10, 'b': 20, 'sometimes_duplicate': 2}
label dictionary id: 0xafd4934
{'a': 10, 'b': 20, 'sometimes_duplicate': 0}
{'a': 10, 'b': 25, 'sometimes_duplicate': 1}
{'a': 10, 'b': 20, 'sometimes_duplicate': 2}
Someone should take a look to dense graphs backend to see if behaves as
the sparse one before my patch.
Attached is the patch produced through mercurial.
I have no time di add to the trac now.
Bye :)
--
Michele Comignano
Computer Science student
University of Pisa, Italy
--
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
# HG changeset patch
# User Michele Comignano com...@gmail.com
# Date 1277112801 -7200
# Node ID 6594a8f8148ae4deb94a3e68491a9f0e582d31e1
# Parent 2cffe66bd64266c6a64d31ca37ad81d8d5390af8
Modified check_edge_label to consider equals the same objects and not objects with the same contents.
diff -r 2cffe66bd642 -r 6594a8f8148a sage/graphs/base/sparse_graph.pyx
--- a/sage/graphs/base/sparse_graph.pyx Fri Jun 04 12:50:55 2010 -0700
+++ b/sage/graphs/base/sparse_graph.pyx Mon Jun 21 11:33:21 2010 +0200
@@ -1315,7 +1315,7 @@
cdef int l_int, max = 0
for l_int in edge_labels:
-if edge_labels[l_int] == l:
+if id(edge_labels[l_int]) == id(l):
return l_int
if max l_int:
max = l_int
Re: [sage-devel] What are the most important parts of Sage?
On 06/21/10 02:19 AM, François Bissey wrote: make test Thank you. That worked. A package is up for review at http://trac.sagemath.org/sage_trac/ticket/9295 if you would like to review it. This found 5 failures on my machine, so it was well worth running, given Python is such a central part of Sage. 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] Re: Sage OSX Clickable App
Okay, I created a simple application (none of the copyright is set for example) that does the following: 1. On launch it runs sage -notebook (which will open the default browser etc. (unless there is a server running)) This would be if one had it in (say) /Applications and double-clicked a Sage icon? 2. It only appears as a menu extra which allows opening notebooks, the log, and several shell sessions (am I missing anything -- reveal SAGE_ROOT in Finder perhaps?). I'm not sure exactly what this means. I see the screenshot... but does that mean it doesn't appear in the Dock? This seems counterintuitive to me; for instance, ideally one should be able to drag and drop a .sws file onto it (eventually, not immediately). I really like the many options, though, and opening SAGE_ROOT in the Finder would be quite useful. 3. On quit it stops the server (should there be an option to quit without stopping the server?). Probably not at this point. It's supposed to be for those not interested in the command line, though of course usable by all. If you want to try it, I have put it up athttp://math.byu.edu/~gvol/files/SageMenu.zip and a screen shot athttp://math.byu.edu/~gvol/files/sage-menu-screenshot.png For testing purposes it creates a symlink in Contents/Resources/ to a local sage root directory. In the distributed version I imagine that the sage root would reside there (like it does in the app created currently). Because of this, if you have problems running, it may be that sage is not in your path. If this is the case then you will need to edit Targets SageMenu Run Script and change the default sage root directory. Right now I created it completely outside of Sage, but I can of course replace the app that is in Sage, or add this in addition. Does anyone prefer the application that is currently created? Obviously sage -bdist will have to be changed as well, but that shouldn't be hard. I will at least test it out... I think that having something that 'looks' as much like other math software does in Mac (including Mac- native Grapher) is important. Right now, even if I put the contents of SageMenu in an app bundle (inside of Contents/Resources) it doesn't want to start (perhaps not surprisingly, since there isn't a MacOS directory?). Do the menu items have a different folder structure? Phew. I don't know why my emails always turn out to be novels. But that is good! As much detail as possible for those of us who otherwise would be completely lost. Thanks for this work; having something with all code visible will be great. - kcrisman -- 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] matplotlib html5 canvas backend
Some people have just released a preliminary version of an html5 canvas matplotlib backend. What this means is cool interactive 2d graphics for Sage. If anyone wants to look at it and see how it works, the code is up here: http://code.google.com/p/mplh5canvas/ 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] matplotlib html5 canvas backend
On Jun 21, 2010, at 8:12 AM, Jason Grout wrote: Some people have just released a preliminary version of an html5 canvas matplotlib backend. What this means is cool interactive 2d graphics for Sage. If anyone wants to look at it and see how it works, the code is up here: http://code.google.com/p/mplh5canvas/ Very cool. Seems to be based on callbacks, which should be natural for those used to using twisted. - Robert -- 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] pushing towards 90% doctest coverage for Sage 5.0
On Jun 11, 2010, at 2:42 AM, Minh Nguyen wrote: Hi Florent, On Fri, Jun 11, 2010 at 7:33 PM, Florent Hivert florent.hiv...@univ-rouen.fr wrote: SNIP I like this way of seeing. However, I was speaking about module or functions which are not tested nor deprecated and nowhere used into sage (easy to check using grep). Does it make sens to remove them without a deprecation warning ? Many code seems to had been put here, just in case it is useful, and was never used by the sage lib itself, but maybe by some users... Do we agree on the policy: - If a user need a code, he should take care to document and test it. - Corollary: any code which is not tested, nor used can be safely removed without a deprecation warning. There are functions, classes, methods that were introduced into the Sage library well before the policy of 100% doctest coverage was implemented and os completely lack testing. It can be difficult to know if a piece of orphaned code should be removed. I think we need to consider your proposed policy on a module by module basis. +1. Much of that code has been around for years, and so is the least safe to deprecate without warning. Of course, there's a lot of dead code that could be pruned/cleaned, but lets put at least some deprecation warnings in sooner rather than later. Perhaps, if your thinking about coverage, it would be fair to not count deprecated code in that number. - Robert -- 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] Vote for including GLPK standard in Sage
Hello, Almost a year ago there was a brief discussion about this topic: http://groups.google.com/group/sage-devel/browse_thread/thread/fed15c54478e8d5 GLPK is a GPLv3 program from the FSF for linear programming: http://www.gnu.org/software/glpk/ Many of the awesome graph theory functions (such as for Hamiltonian graphs) depend on some LP program being installed, and I think it would be great if sage-standard could, e.g. solve the is_hamiltonian question. Here are a few William Stein quotes from the last discussion: NOTE: GLPK is GPLv3. Since we need to retain the ability to release GPLv2 versions of Sage for now, this is another very good reason to make it optional for a while (so it is easy to swap out). ... I personally think GLPK will end up being standard in Sage before long, so I think your approach right now is pretty good. It's just that it has to be optional for a bit (a month or so), since that's what we do. I recently emailed him about the GPLv3 issue, asking is GPLv3 a deal-breaker? and he replied No, it is not a dealbreaker. As more and more functions requiring LP get merged into Sage, I think the time has come to reconsider this. -- Robert L. Miller http://www.rlmiller.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: Surprising code !!!
On Jun 15, 2010, at 3:15 AM, William Stein wrote: On Tue, Jun 15, 2010 at 2:09 AM, daveloeffler dave.loeff...@gmail.com wrote: On Jun 14, 11:25 pm, Jason Grout jason-s...@creativetrax.com wrote: So the doctests for that function are useless for testing that function, obviously. I've wondered before if there's any way to make the test script check that a given function has actually been called. I've seen several errors similar to the above, with buggy code that was masked by code in other modules, so the doctests for the original function were actually calling something entirely different. I doubt it in *general* due to the subtlety of Cython, which is a massive part of Sage... With line profiling (to be implemented, but not too hard), we can start getting line coverage stats for our test suite, which would be very interesting to look at. (In fact, we could get function coverage right now, as function profiling works for both Cython and Python). I very often write doctests that defensively avoid this. E.g., if I'm writing a test in a class Foo, then in my test I'll put sage: make object X sage: type(X) Foo sage: ... This is especially important, because make object X could in the future make an object of a totally different class, e.g., when polynomials over QQ eventually switch to using FLINT. Then all tests using them would not really be testing the generic polynomial class! So the above means the relevant tests would break, and one would have to replaces polys over QQ by some other generic poly class for generic tests. +1. I try to do this too (not for every doctests, but for enough that things will break if I start creating/testing the wrong implementation). - Robert -- 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] 90% doctest coverage update: 14 June 2010
On Jun 14, 2010, at 5:35 AM, Dr. David Kirkby wrote: On 06/14/10 01:17 PM, Dr. David Kirkby wrote: On 06/14/10 12:18 PM, Tim Joseph Dumol wrote: As for Cython and gcc, the Sage notebook uses pure Python. I do acknowledge that there's a minuscule chance that a Python update could change runtime behaviour. But what is used to build python? - gcc of course! So we have *at least* the following possibilities which could result in a problem. * gcc update * python update * someone patching python (it is already at patch level 8 or so in Sage) * operating system update * port to another platform (Cygwin, OpenSolaris and FreeBSD are all being worked on.) * someone's computer may be mis-configured. I should have also considered anything that is needed to build python, could change the behavior of python. That includes * zlib - which will be updated in 4.4.4.alpha1 * termcap * readline * sqlite * gnutls * libpng Some I accept are unlikely, but none are impossible. I have yet to see any Python code that behaves differently on different platforms except for code using platform dependent features, numerical noise (and even then only on Sparc), or external recourses (including timing). It's possible, but there's much more fruitful things to test. Is there *any* other motivation for removing this from the testing, apart from increasing the percentage of doctest coverage? That I feel is the most important question. If not, it boils down to sacrificing quality for better looking statistics. Which is what I think we are doing. It's not just about better looking statistics, it's also about more accurately reflecting the state of the codebase. To clarify, in this case the reason that code needs to be there is just to unpickle old notebooks, meaning that there needs to be a class of a specific name in a specific module (again looked up by name) or the old pickle won't know how to reconstruct itself. Most (all?) of the actual code there could probably be deleted without affecting unpickleability (todo once we have good tests of that). - Robert -- 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: 2d hyperbolic geometry, homogeneous spaces, plot
Okay, I'll get to work on that Greg On Jun 18, 10:39 am, Jason Grout jason-s...@creativetrax.com wrote: On 6/17/10 10:23 AM, Greg Laun wrote: Ourgeometrylab has a good deal of existing code for hyperbolic geometry, and one of my goals this summer is to port it to Sage. I spoke with Bill Goldman, who heads the lab, and he's on board with GPLing the code and releasing it into the Sage code base if that's something people want. I think it would be great to have those things in Sage! 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: Design discussion / request for comment
On Jun 14, 2010, at 4:19 PM, Florent Hivert wrote: Hi Robert, Copy on write *should* be rather easy to implement for matrices at least. This is both true and false: Making the data-structure for having copy-on-write object is fairly easy. This is just aving an extra level of indirection and we have something good for that in sage-combinat queue (see [1]). Note that if this patch were be really used, it certainly should be Cythonized. The main problem for COW is a problem of syntax. If obj is a python object then obj1 = obj makes only a new reference on the *same* object. Unfortunately in Python, there is now way to change that like overloading operator::= in C++. Personally, I think not being able to execute arbitrary code on assignment is a feature not a bug :) I more or less agrees with that... if you want to make a new *semantic copy* you have to use a different syntax. The way we tried that in our experiment is with obj.mutable(): # obj is now a new semantic copy of itself # copy is done here if needed. obj[1] = 1 # in place modifications The result of the experiment is that, given you have to use this new syntax, most of the time if you use it, you really need a *new* copy. The overhead of COW is simply not worth it. Therefore we decided that the prototype design pattern was better suitable to our need than COW. Of course, if there was a was to overload = things were completely different. My proposal is not to make everything copy on write by default, but rather to make the copy() method lazy. This would be a smaller step, but still useful. In particular, this wouldn't change any current Sage semantics, but would only be an optimization feature. The prototypical use case is when something returns a matrix that's worth caching, but doesn't know if the user just wants to read it, or might want to modify it. Well ! I not sure to understand exactly... So you want to return a (semantic) copy of what is cached, right ? So any function returning a matrix (say inverse) will have to explicitely call return copy(result). So inverse is only computed once. Yes. But still, do you return a mutable or immutable matrix ? If you were returning an immutable one, there would be no need to bother with the copy. Or maybe with this COW you don't want to distinguish anymore ? I'm fine with still making this distinction. E.g. The original inverse matrix could still be immutable (for safety, in case anyone gets their hands on it). As for the overhead, one could put the copying code in clear_cache(), and there would be no need for an extra layer of indirection. So basically you still want to write A = copy(B) # create a semantic copy but no actual copy is done A[1,2] = 4 # the copy is triggered... An since the actual entries of the matrix are stored in an attributes called _entries, two different matrix objects can have share the same entries so that the matrix object is doing the indirection for you. So this sound good and not very hard to do... Yep. It's not as transparent as COW on assignment, and happens to be specific to matrices (arguably the most common use) but explicit is better than implicit. - Robert -- 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] Vote for including GLPK standard in Sage
On Monday, June 21, 2010, Robert Miller r...@rlmiller.org wrote: Hello, Almost a year ago there was a brief discussion about this topic: http://groups.google.com/group/sage-devel/browse_thread/thread/fed15c54478e8d5 GLPK is a GPLv3 program from the FSF for linear programming: http://www.gnu.org/software/glpk/ Many of the awesome graph theory functions (such as for Hamiltonian graphs) depend on some LP program being installed, and I think it would be great if sage-standard could, e.g. solve the is_hamiltonian question. Here are a few William Stein quotes from the last discussion: NOTE: GLPK is GPLv3. Since we need to retain the ability to release GPLv2 versions of Sage for now, this is another very good reason to make it optional for a while (so it is easy to swap out). ... I personally think GLPK will end up being standard in Sage before long, so I think your approach right now is pretty good. It's just that it has to be optional for a bit (a month or so), since that's what we do. I recently emailed him about the GPLv3 issue, asking is GPLv3 a deal-breaker? and he replied No, it is not a dealbreaker. As more and more functions requiring LP get merged into Sage, I think the time has come to reconsider this. This is an official call for a vote: [ ] yes, include glpk [ ] no, don't because ___ -- Robert L. Miller http://www.rlmiller.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 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] Should we block the use of CC and CXX except for developers?
On Jun 15, 2010, at 12:50 AM, David Kirkby wrote: On 15 June 2010 02:41, Pablo De Napoli pden...@gmail.com wrote: I really think that spliting users into developers and non developers is very much against the spirit of open source I'm not sure if its against the spirit of open-source. Many of us use packages we do not develop - OpenOffice is one example for me. And OpenOffice is not a very healthy looking project... Firefox is another good example of users developers. Any barrier of entrance to development is against that. +1 It is against the spirit of Sage to widen this gap. I'm not proposing we make a barrier. What I propose is that we warn uses that setting these variables does not work correctly, but allow them to do so if they wish. At the minute, there is no warning if one set CC or CXX, despite the fact they are not fully supported in Sage. I'm +1 to a warning for having CC and CXX set, there's a distinction between developing Sage and trying to build it in as-yet unsupported (and known broken) ways and platforms. Rather than having a plethora of environment variables to set, perhaps we could have a different make target (e.g. make porting or make experimental) that would run the prereq script in interactive mode (e.g. CC is unsupported and set, continue anyways? [y/N]) Moreover, I think that the idea of that all the environment has to be controlled when building sage and therefore all the dependencies should be included has some serious drawbacks, like making difficult the creation of packages for different linux distributions (see how difficult would be to update the current debian package to the current sage version) and this goal would be important for attracting more non-technical users to sagre. I agree, but I also see Williams point that having to require people to have a large number of different packages, modified in some way, would be very difficult. +1. Forcing the user (or each of several linux distributions) to manage the dependancies would not make things easier IMHO. -Robert -- 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: Sage OSX Clickable App
On Jun 21, 2010, at 8:34 AM, kcrisman wrote: Okay, I created a simple application (none of the copyright is set for example) that does the following: 1. On launch it runs sage -notebook (which will open the default browser etc. (unless there is a server running)) This would be if one had it in (say) /Applications and double-clicked a Sage icon? Yes. 2. It only appears as a menu extra which allows opening notebooks, the log, and several shell sessions (am I missing anything -- reveal SAGE_ROOT in Finder perhaps?). I'm not sure exactly what this means. I see the screenshot... but does that mean it doesn't appear in the Dock? This seems counterintuitive to me; for instance, ideally one should be able to drag and drop a .sws file onto it (eventually, not immediately). It doesn't show up in the dock. That's easy to change though, it's just a little weird since I haven't hooked up any menus etc. To change it, edit SageMenu-Info.plist (e.g. in Xcode under Resources), and change Application is agent (UIElement) to be unchecked. I really like the many options, though, and opening SAGE_ROOT in the Finder would be quite useful. Okay, I'll add that when I have some time. Any other suggestions? 3. On quit it stops the server (should there be an option to quit without stopping the server?). Probably not at this point. It's supposed to be for those not interested in the command line, though of course usable by all. That's kind of what I was thinking. If you want to try it, I have put it up athttp://math.byu.edu/~gvol/files/SageMenu.zip and a screen shot athttp://math.byu.edu/~gvol/files/sage-menu-screenshot.png For testing purposes it creates a symlink in Contents/Resources/ to a local sage root directory. In the distributed version I imagine that the sage root would reside there (like it does in the app created currently). Because of this, if you have problems running, it may be that sage is not in your path. If this is the case then you will need to edit Targets SageMenu Run Script and change the default sage root directory. Right now I created it completely outside of Sage, but I can of course replace the app that is in Sage, or add this in addition. Does anyone prefer the application that is currently created? Obviously sage -bdist will have to be changed as well, but that shouldn't be hard. I will at least test it out... I think that having something that 'looks' as much like other math software does in Mac (including Mac- native Grapher) is important. Right now, even if I put the contents of SageMenu in an app bundle (inside of Contents/Resources) it doesn't want to start (perhaps not surprisingly, since there isn't a MacOS directory?). Do the menu items have a different folder structure? Oh sorry, I forgot to mention the very important point that it's only the source. I didn't want to worry about creating a universal binary, 32 vs 64 bit etc. Open the SageMenu.xcodeproj in Xcode and click the Build Run button. I always forget some minor detail, sorry. -Ivan -- 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: Vote for including GLPK standard in Sage
As long as there are no licensing issues, we *definitely* need something for semi-serious LP (and I don't even use it!). If this is the most obvious candidate for an official package, do it. It's not more than another 100 MB to the tarball, is it? ;) - kcrisman On Jun 21, 2:20 pm, William Stein wst...@gmail.com wrote: On Monday, June 21, 2010, Robert Miller r...@rlmiller.org wrote: Hello, Almost a year ago there was a brief discussion about this topic: http://groups.google.com/group/sage-devel/browse_thread/thread/fed15c... GLPK is a GPLv3 program from the FSF for linear programming: http://www.gnu.org/software/glpk/ Many of the awesome graph theory functions (such as for Hamiltonian graphs) depend on some LP program being installed, and I think it would be great if sage-standard could, e.g. solve the is_hamiltonian question. Here are a few William Stein quotes from the last discussion: NOTE: GLPK is GPLv3. Since we need to retain the ability to release GPLv2 versions of Sage for now, this is another very good reason to make it optional for a while (so it is easy to swap out). ... I personally think GLPK will end up being standard in Sage before long, so I think your approach right now is pretty good. It's just that it has to be optional for a bit (a month or so), since that's what we do. I recently emailed him about the GPLv3 issue, asking is GPLv3 a deal-breaker? and he replied No, it is not a dealbreaker. As more and more functions requiring LP get merged into Sage, I think the time has come to reconsider this. This is an official call for a vote: [ ] yes, include glpk [ ] no, don't because ___ -- Robert L. Miller http://www.rlmiller.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 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
Re: [sage-devel] Should we block the use of CC and CXX except for developers?
On Monday, June 21, 2010, Robert Bradshaw rober...@math.washington.edu wrote: On Jun 15, 2010, at 12:50 AM, David Kirkby wrote: On 15 June 2010 02:41, Pablo De Napoli pden...@gmail.com wrote: I really think that spliting users into developers and non developers is very much against the spirit of open source I'm not sure if its against the spirit of open-source. Many of us use packages we do not develop - OpenOffice is one example for me. And OpenOffice is not a very healthy looking project... Firefox is another good example of users developers. Any barrier of entrance to development is against that. +1 It is against the spirit of Sage to widen this gap. I'm not proposing we make a barrier. What I propose is that we warn uses that setting these variables does not work correctly, but allow them to do so if they wish. At the minute, there is no warning if one set CC or CXX, despite the fact they are not fully supported in Sage. I'm +1 to a warning for having CC and CXX set, there's a distinction between developing Sage and trying to build it in as-yet unsupported (and known broken) ways and platforms. Rather than having a plethora of environment variables to set, perhaps we could have a different make target (e.g. make porting or make experimental) that would run the prereq script in interactive mode (e.g. CC is unsupported and set, continue anyways? [y/N]) I am -1 on anything interactive in any sage build scripts. It makes it a major pain to optimize things and make sure that a build is reproducible. Moreover, I think that the idea of that all the environment has to be controlled when building sage and therefore all the dependencies should be included has some serious drawbacks, like making difficult the creation of packages for different linux distributions (see how difficult would be to update the current debian package to the current sage version) and this goal would be important for attracting more non-technical users to sagre. I agree, but I also see Williams point that having to require people to have a large number of different packages, modified in some way, would be very difficult. +1. Forcing the user (or each of several linux distributions) to manage the dependancies would not make things easier IMHO. -Robert -- 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] Vote for including GLPK standard in Sage
On Mon, Jun 21, 2010 at 2:20 PM, William Stein wst...@gmail.com wrote: On Monday, June 21, 2010, Robert Miller r...@rlmiller.org wrote: ... This is an official call for a vote: [ ] yes, include glpk I vote yes. [ ] no, don't because ___ -- 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: Vote for including GLPK standard in Sage
On Mon, Jun 21, 2010 at 11:34 AM, kcrisman kcris...@gmail.com wrote: As long as there are no licensing issues, we *definitely* need something for semi-serious LP (and I don't even use it!). If this is the most obvious candidate for an official package, do it. It's not more than another 100 MB to the tarball, is it? ;) The tarballs are roughly 3MB. -- 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] Vote for including GLPK standard in Sage
On Monday, June 21, 2010, Robert Miller r...@rlmiller.org wrote: On Mon, Jun 21, 2010 at 11:34 AM, kcrisman kcris...@gmail.com wrote: As long as there are no licensing issues, we *definitely* need something for semi-serious LP (and I don't even use it!). If this is the most obvious candidate for an official package, do it. It's not more than another 100 MB to the tarball, is it? ;) The tarballs are roughly 3MB. Build time? Tested on solaris? Tested on cygwin? -- 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] Vote for including GLPK standard in Sage
Build time? On my MacBook, under two minutes: $ time sage -f glpk ... real1m25.964s user0m58.227s sys 0m14.410s Tested on solaris? Tested on cygwin? Sorry, but I have no idea... -- Robert L. Miller http://www.rlmiller.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] Vote for including GLPK standard in Sage
Many of the awesome graph theory functions (such as for Hamiltonian graphs) depend on some LP program being installed, and I think it would be great if sage-standard could, e.g. solve the is_hamiltonian question. I'm all in favour of having some LP (and MIP) solver in Sage by default. It seems to me GLPK fits the requirements best. It is not a very efficient solver (at least in my experience) but there is not GPL'd alternative AFAIK. So I vote yes. Martin PS: Of course, we'll have to figure out Solaris and Cygwin support first etc. -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://www.informatik.uni-bremen.de/~malb _jab: martinralbre...@jabber.ccc.de -- 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] Vote for including GLPK standard in Sage
On Mon, Jun 21, 2010 at 11:45 AM, William Stein wst...@gmail.com wrote: Tested on cygwin? Seems to work on Cygwin: real9m30.674s user2m52.117s sys 5m37.069s Successfully installed glpk-4.42.p0 Now cleaning up tmp files. Making Sage/Python scripts relocatable... Making script relocatable Finished installing glpk-4.42.p0.spkg mhan...@winxp2 ~/sage-4.3.5 --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
[sage-devel] Re: Vote for including GLPK standard in Sage
This is an official call for a vote: [ X] yes, include glpk I have not had any problems installing glpk, which I have done quite a bit in testing the sandpiles package. I believe it builds on solaris (definitely used to), and I know it does on a range of linux and mac machines I have used. -Marshall Hampton -- 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 we block the use of CC and CXX except for developers?
On 06/21/10 07:30 PM, Robert Bradshaw wrote: On Jun 15, 2010, at 12:50 AM, David Kirkby wrote: On 15 June 2010 02:41, Pablo De Napoli pden...@gmail.com wrote: I really think that spliting users into developers and non developers is very much against the spirit of open source I'm not sure if its against the spirit of open-source. Many of us use packages we do not develop - OpenOffice is one example for me. And OpenOffice is not a very healthy looking project... Firefox is another good example of users developers. I suspect the very nature of Firefox and OpenOffice means many users are not very technical, so are less likely to be developers. Of course there are exceptions, but I would suspect it is generally more true than with Sage Any barrier of entrance to development is against that. +1 It is against the spirit of Sage to widen this gap. I think what is often overlooked is that just because you are a good mathematician and can use Sage, it does not make you a good developer. If Sage is ever to become a viable alternative to the 4 M's for a lot of people, then it needs software engineering skills. I'm not proposing we make a barrier. What I propose is that we warn uses that setting these variables does not work correctly, but allow them to do so if they wish. At the minute, there is no warning if one set CC or CXX, despite the fact they are not fully supported in Sage. I'm +1 to a warning for having CC and CXX set, there's a distinction between developing Sage and trying to build it in as-yet unsupported (and known broken) ways and platforms. Rather than having a plethora of environment variables to set, perhaps we could have a different make target (e.g. make porting or make experimental) that would run the prereq script in interactive mode (e.g. CC is unsupported and set, continue anyways? [y/N]) I've never come an autoconf script (which is what prereq is), that is interactive. Even if it could be done, I think it defeats the whole point about autoconf. I'd personally find that annoying. Then you would have to start using programs like 'expect' to perform non-interactive builds. Whilst one will have to set certain environment variables, these can at least be added to a .profile/.bashrc or whatever you want. I have SAGE_PORT=yes as an environment variable, so its always seen. Also, the environment variables are self-documenting, in that if you need one, it tells you what to type. Moreover, I think that the idea of that all the environment has to be controlled when building sage and therefore all the dependencies should be included has some serious drawbacks, like making difficult the creation of packages for different linux distributions (see how difficult would be to update the current debian package to the current sage version) and this goal would be important for attracting more non-technical users to sagre. I agree, but I also see Williams point that having to require people to have a large number of different packages, modified in some way, would be very difficult. +1. Forcing the user (or each of several linux distributions) to manage the dependancies would not make things easier IMHO. -Robert It's just a shame that the present system of using Sage puts off many Linux distributions. But I don't claim to know the answer - it's just an observation. 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] Re: Vote for including GLPK standard in Sage
A +1 from me, of course :-) Nathann -- 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] Vote for including GLPK standard in Sage
Il 21/06/2010 20:20, William Stein ha scritto: This is an official call for a vote: [ ] yes, include glpk [ ] no, don't because ___ [X] yes, include glpk Having a class to build easily MILP problems and discover that p.solve() raise an excetion by default is somewhat frustrating! :) -- Michele Comignano Computer Science student University of Pisa, Italy -- 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: Vote for including GLPK standard in Sage
yes, sure! By the way, GLPK has a CVXOPT interface, so this would also means that this interface needs to be somehow taken care of in a new release of CVXOPT package, that I hopefully will be able to deal with in July... Dima On Jun 21, 8:02 pm, Robert Miller r...@rlmiller.org wrote: Hello, Almost a year ago there was a brief discussion about this topic: http://groups.google.com/group/sage-devel/browse_thread/thread/fed15c... GLPK is a GPLv3 program from the FSF for linear programming: http://www.gnu.org/software/glpk/ Many of the awesome graph theory functions (such as for Hamiltonian graphs) depend on some LP program being installed, and I think it would be great if sage-standard could, e.g. solve the is_hamiltonian question. Here are a few William Stein quotes from the last discussion: NOTE: GLPK is GPLv3. Since we need to retain the ability to release GPLv2 versions of Sage for now, this is another very good reason to make it optional for a while (so it is easy to swap out). ... I personally think GLPK will end up being standard in Sage before long, so I think your approach right now is pretty good. It's just that it has to be optional for a bit (a month or so), since that's what we do. I recently emailed him about the GPLv3 issue, asking is GPLv3 a deal-breaker? and he replied No, it is not a dealbreaker. As more and more functions requiring LP get merged into Sage, I think the time has come to reconsider this. -- Robert L. Millerhttp://www.rlmiller.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] Vote for including GLPK standard in Sage
On 06/21/10 07:45 PM, William Stein wrote: On Monday, June 21, 2010, Robert Millerr...@rlmiller.org wrote: On Mon, Jun 21, 2010 at 11:34 AM, kcrismankcris...@gmail.com wrote: As long as there are no licensing issues, we *definitely* need something for semi-serious LP (and I don't even use it!). If this is the most obvious candidate for an official package, do it. It's not more than another 100 MB to the tarball, is it? ;) The tarballs are roughly 3MB. Build time? Pretty quick! On my Sun Ultra 27, with a parallel build, I can build it in under 7 seconds! 'configure' takes a bit under 3 seconds, and 'make' takes a bit under 3.8 seconds. For a serial build, it takes a little under 20 seconds. So even on old hardware, that is not going to take too long. Tested on solaris? 32-bit Solaris 10 on SPARC - OK 64-bit Solaris 10 on SPARC - OK 32-bit OpenSolaris on x64 - OK 64-bit OpenSolaris on x64 - OK In all cases, I just used 'configure' to the source code. I've not tried it whatever a Sage package decides to link to it. Tested on cygwin? -- 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] What are the most important parts of Sage?
On 06/20/10 11:19 PM, David Kirkby wrote: Anyway, what of the following would be considered worth doing first, given I don't have the time or inclination to do them all? All these lack an spk-check file. Python has been resolved. John Palmieri has reviewed the python package http://boxen.math.washington.edu/home/kirkby/revised-patches/python-2.6.4.p9.spkg http://trac.sagemath.org/sage_trac/ticket/9295 so we can now check python. So far, all systems tested (OS X, Solaris and OpenSolaris) all have 5 failures, though the 5 failures are not the same, though 'test_distutils' has failed on all platforms tested to date. So what of these is most critical in Sage, and could most do with being tested? It seem strange we are only checking about 20% of the packages, even if SAGE_CHECK is yes. ./blas-20070724/spkg-install // there are NO tests in blas ./boost-cropped-1.34.1/spkg-install // there are NO self tests ./cephes-2.8/spkg-install // HAS self tests, but no spkg-check ./cliquer-1.2.p5/spkg-install ./conway_polynomials-0.2/spkg-install ./cvxopt-0.9.p8/spkg-install ./cython-0.12.1/spkg-install ./docutils-0.5.p0/spkg-install ./ecl-10.2.1/spkg-install ./elliptic_curves-0.1/cremona_mini/spkg-install ./elliptic_curves-0.1/ellcurves/spkg-install ./elliptic_curves-0.1/spkg-install ./examples-4.4.4.alpha1/spkg-install ./extcode-4.4.4.alpha1/spkg-install ./flintqs-20070817.p4/spkg-install ./fortran-20100428/spkg-install ./freetype-2.3.5.p2/spkg-install ./gap-4.4.12.p3/spkg-install ./gd-2.0.35.p5/spkg-install ./gdmodule-0.56.p7/spkg-install ./genus2reduction-0.3.p6/spkg-install ./gfan-0.4plus.p1/spkg-install ./ghmm-20080813.p0/spkg-install ./gnutls-2.2.1.p5/spkg-install ./graphs-20070722.p1/spkg-install ./iml-1.0.1.p12/spkg-install ./ipython-0.9.1.p0/spkg-install ./jinja-1.2.p0/spkg-install ./jinja2-2.1.1.p0/spkg-install ./lapack-20071123.p1/spkg-install ./lcalc-20100428-1.23/spkg-install ./libgpg_error-1.6.p3/spkg-install ./libm4ri-20100221/spkg-install ./libpng-1.2.35.p2/spkg-install ./linbox-1.1.6.p3/spkg-install ./matplotlib-0.99.1.p4/spkg-install ./maxima-5.20.1.p0/spkg-install ./mercurial-1.3.1.p2/spkg-install ./moin-1.9.1.p1/spkg-install ./mpfi-1.3.4-cvs20071125.p8/spkg-install ./mpmath-0.14/spkg-install ./networkx-1.0.1/spkg-install ./numpy-1.3.0.p3/spkg-install ./opencdk-0.6.6.p4/spkg-install ./palp-1.1.p2/spkg-install ./pari-2.3.5.p1/spkg-install ./pexpect-2.0.p4/spkg-install ./pil-1.1.6.p2/spkg-install ./polybori-0.6.4.p1/spkg-install ./polytopes_db-20100210/spkg-install ./pycrypto-2.0.1.p5/spkg-install ./pygments-0.11.1.p0/spkg-install ./pynac-0.2.0.p3/spkg-install ./python_gnutls-1.1.4.p7/spkg-install ./ratpoints-2.1.3.p1/spkg-install ./readline-6.0.p1/spkg-install ./rubiks-20070912.p10/spkg-install ./sage_scripts-4.4.4.alpha1/spkg-install ./sage-4.4.4.alpha1/spkg-install ./sagenb-0.8.p2/spkg-install ./scipy_sandbox-20071020.p5/spkg-install ./scons-1.2.0/spkg-install ./setuptools-0.6c9.p0/spkg-install ./singular-3-1-0-4-20100214/spkg-install ./singular-3.1.0.4.p6/spkg-install ./sphinx-0.6.3.p4/spkg-install ./sqlite-3.6.22/spkg-install ./symmetrica-2.0.p5/spkg-install ./sympow-1.018.1.p7/spkg-install ./sympy-0.6.4.p0/spkg-install ./tachyon-0.98beta.p11/spkg-install ./termcap-1.3.1.p1/spkg-install ./twisted-9.0.p2/spkg-install ./weave-0.4.9.p0/spkg-install ./zlib-1.2.3.p5/spkg-install ./zodb3-3.7.0.p3/spkg-install -- 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] Vote for including GLPK standard in Sage
On Jun 21, 2010, at 11:20 AM, William Stein wrote: On Monday, June 21, 2010, Robert Miller r...@rlmiller.org wrote: Hello, Almost a year ago there was a brief discussion about this topic: http://groups.google.com/group/sage-devel/browse_thread/thread/fed15c54478e8d5 GLPK is a GPLv3 program from the FSF for linear programming: http://www.gnu.org/software/glpk/ Many of the awesome graph theory functions (such as for Hamiltonian graphs) depend on some LP program being installed, and I think it would be great if sage-standard could, e.g. solve the is_hamiltonian question. Here are a few William Stein quotes from the last discussion: NOTE: GLPK is GPLv3. Since we need to retain the ability to release GPLv2 versions of Sage for now, this is another very good reason to make it optional for a while (so it is easy to swap out). ... I personally think GLPK will end up being standard in Sage before long, so I think your approach right now is pretty good. It's just that it has to be optional for a bit (a month or so), since that's what we do. I recently emailed him about the GPLv3 issue, asking is GPLv3 a deal-breaker? and he replied No, it is not a dealbreaker. As more and more functions requiring LP get merged into Sage, I think the time has come to reconsider this. This is an official call for a vote: [ ] yes, include glpk Makes sense to me. Does it have a spkg-check? - Robert -- 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] What are the most important parts of Sage?
On Jun 21, 2010, at 2:03 PM, Dr. David Kirkby wrote: On 06/20/10 11:19 PM, David Kirkby wrote: Anyway, what of the following would be considered worth doing first, given I don't have the time or inclination to do them all? All these lack an spk-check file. Python has been resolved. John Palmieri has reviewed the python package http://boxen.math.washington.edu/home/kirkby/revised-patches/python-2.6.4.p9.spkg http://trac.sagemath.org/sage_trac/ticket/9295 so we can now check python. So far, all systems tested (OS X, Solaris and OpenSolaris) all have 5 failures, though the 5 failures are not the same, though 'test_distutils' has failed on all platforms tested to date. So what of these is most critical in Sage, and could most do with being tested? It seem strange we are only checking about 20% of the packages, even if SAGE_CHECK is yes. Yes, I guess you could say we trust the upstream testing too much. I'll add an spkg-check to Cython the next time I update that package. - Robert -- 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: What are the most important parts of Sage?
If what you are saying is true, then that is appalling, David. Any
package which is not rigorously tested is completely and utterly
broken, as anyone who code, knows.
I think maybe future versions of flint should have no test suite and
no documentation. It would get done three times faster.
I vote that all packages without a decent test suite be deprecated.
{only half joking}
Bill.
On Jun 20, 11:19 pm, David Kirkby david.kir...@onetel.net wrote:
I reported yesterfay that only 19 of the 98 or so standard packages
have an spkg-check file, making it possible to test the packages as
Sage is built. None of the list below have any way of running
self-tests on the packages, though in many cases the upstream packages
have no test suites.
I've just added one to 'boehm_gc' but what what of the following would
be most useful to add self-tests to? I can't be bothered to do them
all, but I don't mind doing a few now and then.
I would have thought python was pretty critical, but I can'f find a
way of testing python. Although python is built with the usual
configure
make
make install
there is no 'make check'.
Does anyone know how to test python properly? I know Sage does a
couple of rudementary checks, like importing _hashlib and getting
python to print Sage works at one point, but that is hardly very
extensive.
Anyway, what of the following would be considered worth doing first,
given I don't have the time or inclination to do them all? All these
lack an spk-check file.
./blas-20070724/spkg-install // there are NO tests in blas
./boost-cropped-1.34.1/spkg-install // there are NO self tests
./cephes-2.8/spkg-install // HAS self tests, but no spkg-check
./cliquer-1.2.p5/spkg-install
./conway_polynomials-0.2/spkg-install
./cvxopt-0.9.p8/spkg-install
./cython-0.12.1/spkg-install
./docutils-0.5.p0/spkg-install
./ecl-10.2.1/spkg-install
./elliptic_curves-0.1/cremona_mini/spkg-install
./elliptic_curves-0.1/ellcurves/spkg-install
./elliptic_curves-0.1/spkg-install
./examples-4.4.4.alpha1/spkg-install
./extcode-4.4.4.alpha1/spkg-install
./flintqs-20070817.p4/spkg-install
./fortran-20100428/spkg-install
./freetype-2.3.5.p2/spkg-install
./gap-4.4.12.p3/spkg-install
./gd-2.0.35.p5/spkg-install
./gdmodule-0.56.p7/spkg-install
./genus2reduction-0.3.p6/spkg-install
./gfan-0.4plus.p1/spkg-install
./ghmm-20080813.p0/spkg-install
./gnutls-2.2.1.p5/spkg-install
./graphs-20070722.p1/spkg-install
./iml-1.0.1.p12/spkg-install
./ipython-0.9.1.p0/spkg-install
./jinja-1.2.p0/spkg-install
./jinja2-2.1.1.p0/spkg-install
./lapack-20071123.p1/spkg-install
./lcalc-20100428-1.23/spkg-install
./libgpg_error-1.6.p3/spkg-install
./libm4ri-20100221/spkg-install
./libpng-1.2.35.p2/spkg-install
./linbox-1.1.6.p3/spkg-install
./matplotlib-0.99.1.p4/spkg-install
./maxima-5.20.1.p0/spkg-install
./mercurial-1.3.1.p2/spkg-install
./moin-1.9.1.p1/spkg-install
./mpfi-1.3.4-cvs20071125.p8/spkg-install
./mpmath-0.14/spkg-install
./networkx-1.0.1/spkg-install
./numpy-1.3.0.p3/spkg-install
./opencdk-0.6.6.p4/spkg-install
./palp-1.1.p2/spkg-install
./pari-2.3.5.p1/spkg-install
./pexpect-2.0.p4/spkg-install
./pil-1.1.6.p2/spkg-install
./polybori-0.6.4.p1/spkg-install
./polytopes_db-20100210/spkg-install
./pycrypto-2.0.1.p5/spkg-install
./pygments-0.11.1.p0/spkg-install
./pynac-0.2.0.p3/spkg-install
./python_gnutls-1.1.4.p7/spkg-install
./python-2.6.4.p8/spkg-install
./ratpoints-2.1.3.p1/spkg-install
./readline-6.0.p1/spkg-install
./rubiks-20070912.p10/spkg-install
./sage_scripts-4.4.4.alpha1/spkg-install
./sage-4.4.4.alpha1/spkg-install
./sagenb-0.8.p2/spkg-install
./scipy_sandbox-20071020.p5/spkg-install
./scons-1.2.0/spkg-install
./setuptools-0.6c9.p0/spkg-install
./singular-3-1-0-4-20100214/spkg-install
./singular-3.1.0.4.p6/spkg-install
./sphinx-0.6.3.p4/spkg-install
./sqlite-3.6.22/spkg-install
./symmetrica-2.0.p5/spkg-install
./sympow-1.018.1.p7/spkg-install
./sympy-0.6.4.p0/spkg-install
./tachyon-0.98beta.p11/spkg-install
./termcap-1.3.1.p1/spkg-install
./twisted-9.0.p2/spkg-install
./weave-0.4.9.p0/spkg-install
./zlib-1.2.3.p5/spkg-install
./zodb3-3.7.0.p3/spkg-install
--
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: questions about sage/databases/*
Hi, 1. It seems to me that kohel.py is broken and has not been used in the past 5 years or so. Then I suppose we should remove it, unless David Kohel has objections. Go ahead and remove it. Cheers, David -- 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: What are the most important parts of Sage?
On Jun 21, 2010, at 2:27 PM, Bill Hart wrote:
If what you are saying is true, then that is appalling, David. Any
package which is not rigorously tested is completely and utterly
broken, as anyone who code, knows.
This is assuming that no one upstream does any testing. I think the
focus should be on new code (e.g. the Sage library itself, or code
that's not widely used outside of Sage.)
I think maybe future versions of flint should have no test suite and
no documentation. It would get done three times faster.
;-)
I vote that all packages without a decent test suite be deprecated.
{only half joking}
Well, we should make it a requirement for any new packages at least.
Anyway, what of the following would be considered worth doing first,
given I don't have the time or inclination to do them all? All these
lack an spk-check file.
Here's my very quick partitioning (in terms of spkg-check):
Very important:
./blas-20070724/spkg-install // there are NO tests in blas
./cephes-2.8/spkg-install // HAS self tests, but no spkg-check
./cliquer-1.2.p5/spkg-install
./cvxopt-0.9.p8/spkg-install
./gnutls-2.2.1.p5/spkg-install
./iml-1.0.1.p12/spkg-install
./lapack-20071123.p1/spkg-install
./lcalc-20100428-1.23/spkg-install
./libm4ri-20100221/spkg-install
./linbox-1.1.6.p3/spkg-install
./maxima-5.20.1.p0/spkg-install
./pari-2.3.5.p1/spkg-install
./pexpect-2.0.p4/spkg-install
./singular-3-1-0-4-20100214/spkg-install
./polybori-0.6.4.p1/spkg-install
./numpy-1.3.0.p3/spkg-install
./opencdk-0.6.6.p4/spkg-install
./palp-1.1.p2/spkg-install
./symmetrica-2.0.p5/spkg-install
./sympow-1.018.1.p7/spkg-install
./sagenb-0.8.p2/spkg-install
./ratpoints-2.1.3.p1/spkg-install
Somewhat important:
./boost-cropped-1.34.1/spkg-install // there are NO self tests
./cython-0.12.1/spkg-install
./fortran-20100428/spkg-install
./ecl-10.2.1/spkg-install
./gdmodule-0.56.p7/spkg-install
./gap-4.4.12.p3/spkg-install
./genus2reduction-0.3.p6/spkg-install
./gfan-0.4plus.p1/spkg-install
./ghmm-20080813.p0/spkg-install
./ipython-0.9.1.p0/spkg-install
./matplotlib-0.99.1.p4/spkg-install
./mpfi-1.3.4-cvs20071125.p8/spkg-install
./mpmath-0.14/spkg-install
./python-2.6.4.p8/spkg-install
./networkx-1.0.1/spkg-install
./mercurial-1.3.1.p2/spkg-install
./pynac-0.2.0.p3/spkg-install
./rubiks-20070912.p10/spkg-install
./sympy-0.6.4.p0/spkg-install
./scipy_sandbox-20071020.p5/spkg-install
./tachyon-0.98beta.p11/spkg-install
./weave-0.4.9.p0/spkg-install
Not very important (for us to test):
./freetype-2.3.5.p2/spkg-install
./docutils-0.5.p0/spkg-install
./gd-2.0.35.p5/spkg-install
./libgpg_error-1.6.p3/spkg-install
./libpng-1.2.35.p2/spkg-install
./jinja-1.2.p0/spkg-install
./jinja2-2.1.1.p0/spkg-install
./python_gnutls-1.1.4.p7/spkg-install
./moin-1.9.1.p1/spkg-install
./pil-1.1.6.p2/spkg-install
./pycrypto-2.0.1.p5/spkg-install
./pygments-0.11.1.p0/spkg-install
./readline-6.0.p1/spkg-install
./zodb3-3.7.0.p3/spkg-install
./scons-1.2.0/spkg-install
./setuptools-0.6c9.p0/spkg-install
./sphinx-0.6.3.p4/spkg-install
./sqlite-3.6.22/spkg-install
./twisted-9.0.p2/spkg-install
./zlib-1.2.3.p5/spkg-install
Databases:
./conway_polynomials-0.2/spkg-install
./elliptic_curves-0.1/cremona_mini/spkg-install
./elliptic_curves-0.1/ellcurves/spkg-install
./elliptic_curves-0.1/spkg-install
./graphs-20070722.p1/spkg-install
./polytopes_db-20100210/spkg-install
Deprecated?
./flintqs-20070817.p4/spkg-install # part of flint now
./examples-4.4.4.alpha1/spkg-install
Other
./sage-4.4.4.alpha1/spkg-install
./extcode-4.4.4.alpha1/spkg-install
./sage_scripts-4.4.4.alpha1/spkg-install
./termcap-1.3.1.p1/spkg-install
--
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] What are the most important parts of Sage?
On 06/21/10 10:09 PM, Robert Bradshaw wrote: On Jun 21, 2010, at 2:03 PM, Dr. David Kirkby wrote: It seem strange we are only checking about 20% of the packages, even if SAGE_CHECK is yes. Yes, I guess you could say we trust the upstream testing too much. But many of the upstream packages have no test suite. But failures can be caused my many things. * Compiler bugs * Operating systems bugs * Operating systems which are mis-configured. * An almost endless list of other things. So actually testing the packages is a good idea. Clearly the doc tests do not pick up many possible issues in Sage. If the python results are anything to go by, 3 systems give 3 different set of failures. 1) John's Mac (OS X I assume) test_asynchat test_ctypes test_distutils test_locale test_smtplib 2) My Blade 1000 (Solaris 10 SPARC) test_distutils test_float test_hotshot test_multiprocessing test_sunaudiodev 3) My Ultra 27 (OpenSolaris on x64) test_distutils test_float test_multiprocessing test_posix test_zlib The only common one is test_distutils which has failed on all 3 tested systems. I found the python testing quite useful, as there was a bug http://trac.sagemath.org/sage_trac/ticket/8440 which was preventing '_multiprocessing' from building on Solaris. I worked around that, so now '_multiprocessing' builds, but I note 'test_multiprocessing' fails the test suite on both Solaris machines. So perhaps my fix was not as good as I had hoped! That looks like it will be something that needs reporting upstream. I'll add an spkg-check to Cython the next time I update that package. Good. - Robert MPIR, MPFR and now Python (once #9295 is committed) are all covered. I'd like to know what else is pretty critical. I guess Cython must one be one such package, but what else? I'm 99% sure if we run the Maxima test suite there will be several failures due to numerical errors, but I don't know how to run that from the command line (i.e. spkg-check). I think you need to fire up maxima first. 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: What are the most important parts of Sage?
On 06/21/10 11:03 PM, Robert Bradshaw wrote:
On Jun 21, 2010, at 2:27 PM, Bill Hart wrote:
If what you are saying is true, then that is appalling, David. Any
package which is not rigorously tested is completely and utterly
broken, as anyone who code, knows.
This is assuming that no one upstream does any testing. I think the
focus should be on new code (e.g. the Sage library itself, or code
that's not widely used outside of Sage.)
Well Python is pretty widely used, so using that logic, Python would escape
testing.
Yet testing Python on 3 different systems (John's Mac, my Solaris and
OpenSolaris machines), have produced 5 errors on each machine. Though some are
common, there is probably around 10-12 different failures spread amount the 3
different systems.
I vote that all packages without a decent test suite be deprecated.
{only half joking}
Well, we should make it a requirement for any new packages at least.
I think it is not unreasonable that anyone updating a package add an spkg-check
file if one does not exist. It would of course be really boring for someone to
do all 80 packages, but less of a burden someone did it when updating a package,
like you plan to do with Cython.
Anyway, what of the following would be considered worth doing first,
given I don't have the time or inclination to do them all? All these
lack an spk-check file.
Here's my very quick partitioning (in terms of spkg-check):
Very important:
./blas-20070724/spkg-install // there are NO tests in blas
Worrying of course, given there are no self-tests, and you consider it very
important.
./cephes-2.8/spkg-install // HAS self tests, but no spkg-check
./cliquer-1.2.p5/spkg-install
./cvxopt-0.9.p8/spkg-install
./gnutls-2.2.1.p5/spkg-install
./iml-1.0.1.p12/spkg-install
./lapack-20071123.p1/spkg-install
./lcalc-20100428-1.23/spkg-install
./libm4ri-20100221/spkg-install
./linbox-1.1.6.p3/spkg-install
./maxima-5.20.1.p0/spkg-install
./pari-2.3.5.p1/spkg-install
./pexpect-2.0.p4/spkg-install
./singular-3-1-0-4-20100214/spkg-install
./polybori-0.6.4.p1/spkg-install
./numpy-1.3.0.p3/spkg-install
./opencdk-0.6.6.p4/spkg-install
./palp-1.1.p2/spkg-install
./symmetrica-2.0.p5/spkg-install
./sympow-1.018.1.p7/spkg-install
./sagenb-0.8.p2/spkg-install
./ratpoints-2.1.3.p1/spkg-install
Thank you. That list is interesting. I doubt I'll do them all, but if I get
bored, I'll look at them first.
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] MPIR secrets and bsdnt
Hi all, this is the first of three posts, primary audience sage-devel, esp. those attending Sage Days in Leiden. As many of you know, I recently stepped down from the MPIR project. The main reason was that I need to focus on FLINT until about 1 Oct 2010, then need to transition to 80% research, 20% coding (my colleagues at Warwick will be aghast that this is not already the ratio - but they probably guessed as much). Now that I have stepped down from MPIR, I can divulge all the secret development plans I had, in the hope that some other people might get inspired. That is what this email is about - potential MPIR projects that *anyone* could work on (assuming they code in C), even research level projects!! Firstly, in my mind, MPIR is not going away just because I stopped working on it regularly. Since the last release I managed, a major MPIR has been released, 2.1.1, which includes support for MSVC 2010 from Dr. Brian Gladman and proper xgcd normalisation (actually done by me) and a number of other fixes by Jason Moxham. Minh Nguyen managed the release, and did a stellar job! Brian Gladman has always said, MPIR *is* him, me and Jason, so without me it's just him and Jason. But Jason recently posted to mpir-devel with plans for the next release. So the project is not stopping. As everyone is aware, we switched to LGPL v3+ so that code could be exchanged with GMP devels and indeed much code from GMP 5.x.y went into MPIR 2.0.0. Even if MPIR turns into GMP with proper MSVC Windows support, it'll still be a success in my book. But a *lot* more is possible. Here are some of the secret plans I had for the future: Multiplication: * We currently don't have Toom 6 (GMP does). Someone could pull this code from GMP and put it in MPIR. It is largely written by Marco Bodrato, using a new mixing idea, which we had not thought of in MPIR. So it is very fast and well coded. Marco Bodrato and Alberto Zanoni are the leading experts on Toom related stuff. * We do have Toom 8 (also largely by Marco), but what should come next? Perhaps Toom 12? Perhaps a general Toom 2n? This is research mathematics. Currently such a thing doesn't exist. You could write a paper on it. Do please talk to Marco, who is very friendly and approachable and probably has lots of good ideas about what is possible. There's an open question as to what the actual asymptotics of a general Toom 2n is. The best known result is due to Knuth in TAOCP. * FFT - I have written a completely new FFT (I did this last Christmas). Apart from not having the sqrt2 trick implemented, this is actually almost ready to be put into MPIR. It should be *much* better than the FFT currently there, and I even have some new ideas which I could discuss with anyone who would like to do even better. I will be giving a talk at the upcoming Sage Days in Leiden on the FFT. If you get inspired, talk to me and I'll explain my new ideas. __I will *not* have time to complete this FFT___, but wrote extensive notes on what needs to be done to finish it, and there's a thousand lines of code or so ready for someone to work on if they so pleased. This new code is currently not used by anything! This is a project absolutely *anyone* could work on. Division * Anyone who's checked will notice MPIR's division code is actually slower than GMP's. This is fully intentional. It is because I decided we should use David Harvey's divide and conquer code (just a quick note - he disclaims responsibility for bugs in our code - we used his pre-implementation and adapted it for MPIR and he bears no responsibility for the ways in which we massacred it). Now theoretically divide and conquer code based on middle product should be faster than that based on straight multiplication (as currently used by GMP say). But this boils down to as much work being put into middle product code as into ordinary multiplication code, which is currently not the case. Specifically David Harvey invented this fantastic integer middle product algorithm (which was completely new). We've got an implementation largely by him (some by some of the GMP devels) which has assembly code for a basecase, then there is the equivalent of karatsuba multiplication for middle product (it's called toom42_mulmid). Actually you can invert any ordinary multiplication algorithm and turn it into an algorithm for middle product. This uses a type of inversion which is called Tellegen's principal (I can provide references, though they are also contained in David Harvey's paper on his website). Now, the next logical step is to implement Toom63_mulmid. This is an inverted Toom3 algorithm. In fact I have derived the correct identity for doing this (it took me ages as I did it by hand ;-)). Warning: David said he once gave this a go and it wasn't faster. However, he still left the door open for it to be successful because without proper assembly code for some of the components, it simply *can't* compete with the Toom3 multiplication in MPIR. But done
Re: [sage-devel] Re: What are the most important parts of Sage?
On 06/21/10 10:27 PM, Bill Hart wrote: If what you are saying is true, then that is appalling, David. I believe it is true. There's a list here of the packages which have spkg-check files. http://groups.google.com/group/sage-devel/browse_thread/thread/1d6d6ad88557674d?hl=en# as you can see, there are just 19 of them, which is about 20%. I've added the required file to python and boehm_gc, but that still leaves a lot untested. Remember also, most people will never run these, as typing 'make' or 'make test' will not run them. You need to export SAGE_CHECK to yes to even run them. There might be the odd package which runs 'make check' or 'make test' from spkg-install. (I know MPFR does). But I think such packages are very rare. Any package which is not rigorously tested is completely and utterly broken, as anyone who code, knows. My single biggest concern with Sage is that I do not believe it is tested sufficiently. 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] shell commands in the notebook
What exactly has been done to prevent users of http://sagenb.org to do mischief on that server. It's easy to set the session type to sh and find out about the system. Ralf -- 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] FLINT 1.6 coming....
Andy Novocin and I have been working on flint 1.6 for about a year or maybe a year and a half. This has involved numerous visits of him to the UK and me to France. The big improvement... factoring polynomials over Z with a new algorithm due to him and Mark van Hoeij. This is a massive project to implement. When we started I think FLINT had 80,000 lines of code. Now it has about 107,000, and still there is very little test code written for the new stuff. But the result *should* be soundly better than any other algorithm out there for any kind of polynomial over Z (there's a nice collection on the NTL website, and Mark van Hoeij and Andy Novocin have been collecting pathological examples too). The algorithm works, we've implemented it (prototype implementation really), Andy will have finished texing the (long) proof by tomorrow, and even the prototype implementation performs well, modulo the huge number of things in flint which need optimising to make this work fast. We are going to be working very hard on it at the coming Sage Days in Leiden. Shortly thereafter, we hope to release flint 1.6 which will finally have factorisation in Z[x]!! This will be the last flint 1.x.y release evah!! FLINT 1.6 will also include a nice new module written by Sebastian Pancratz ages ago (he's been waiting and waiting for us to release this, but I think his code is used directly by Sage anyway by now). That's all ready to go. Some minor documentation issues remain, everything else is ready. There'll also be some minor bug fixes for issues people have reported, including stuff to do with the makefile, which needs to be incrementally improved to properly support recent Sage build targets. So, if flint 1.x.y is going to finally be put to rest, what is to replace it? That will be the subject of my third post to sage-devel. Bill. -- 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] shell commands in the notebook
On Jun 21, 2010, at 4:47 PM, Ralf Hemmecke wrote: What exactly has been done to prevent users of http://sagenb.org to do mischief on that server. It's easy to set the session type to sh and find out about the system. All worksheet processes run as (several) limited-privilege users within a virtual machine. Of course more could be done, but that's at least something. Also, Yoav Aner did a thesis on the securing of the Sage notebook (available at http://sagemath.org/library-publications.html ). - Robert -- 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] shell commands in the notebook
Thanks. Looks like I rather want to use localhost. But I need it for about 20 users. What options do I have to give to sage -notebook? Ralf On 06/22/2010 01:58 AM, Robert Bradshaw wrote: On Jun 21, 2010, at 4:47 PM, Ralf Hemmecke wrote: What exactly has been done to prevent users of http://sagenb.org to do mischief on that server. It's easy to set the session type to sh and find out about the system. All worksheet processes run as (several) limited-privilege users within a virtual machine. Of course more could be done, but that's at least something. Also, Yoav Aner did a thesis on the securing of the Sage notebook (available at http://sagemath.org/library-publications.html ). - Robert -- 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] flint2 update
As FLINT 1.6 will be the last in the FLINT 1.x.y series, what will replace it? Well, for over a year now, I've been working on a *complete rewrite* of FLINT from scratch, now called flint2. Every single function has been rewritten for _clarity_ and _speed_!! I've been able to make significant gains for each of these criteria. The main thing that prompted the rewrite was the fact that the old flint fmpz integer type did no automatic memory management for you, which made things hard to use. It all just grew from that point to a radical rewrite of the whole damned library (it's called obsessive compulsive disorder) Here is a list of modules that already exist in flint2, some of which have been padded out extensively, others of which still have much to be completed: fmpz - the new FLINT multiple precision integer format (does memory management for you, like GMP's mpz's - only much more efficient for FLINT type stuff) fmpz_mat - matrices over fmpz's i.e. over Z fmpz_mpoly - multivariate polynomials over Z fmpz_poly - univariate polynomials over Z fmpz_vec - routines common to other fmpz modules which rely only on a vector of fmpz's LLL - an doubles/fmpz/mpfr version of Damien Stehle's fpLLL (up to about fpLLL 2.1) mpfr_mat - matrices over R (relies on mpfr), basically to support fpLLL at this stage mpfr_poly - polynomials over R (experimental - needs to be redone to work over cyclotomic fields I think) mpfr_vec - common routines for vectors over R nmod_poly - polynomials over Z/nZ for word sized modulus n (similar to the old zmod_poly only much, much, much better) nmod_vec - common routines for vectors over Z/nZ for a word sized modulus ulong_extras - routines for C unsigned longs, including modular arithmetic, factorisation, primality testing, everything you can think of really (module is about complete and insanely fast) By the end of the year, the following modules will be added (and the above completed): nmod_mpoly - multivariate polynomials over Z/nZ for word sized moduli nmod_mat - matrices over Z/nZ for word sized moduli (I have already written some experimental code for this) fmpz_mod_poly - polynomials over Z/nZ for multiprecision moduli (automatically used nmod_poly for small moduli) code already exists in flint repo for this module fmpz_mod_mat - matrices over Z/nZ for multiprecision moduli I'm currently working on a roadmap release of flint2 which will have at least *some* implementation of all of the basic functionality planned for each module, even if it is not 100% optimal. At this stage the only assembly code actually in flint2 is the longlong.h file which is derived from that in GMP (though completely cleaned out and re-presented for clarity). At this stage I've only put the x86 and x86_64 assembly in, and if anyone would like other platforms supported, I'd love to have help putting the assembly in for those and testing flint2 on those platforms. It should be *much* easier to port flint2 to MSVC. I've generally tried to avoid gnuisms, at least in the library code, though there'll still be occasional ones which slipped through. At least this won't be a nightmare task for anyone. flint2 depends on MPIR (it currently does not support GMP, though with a few week's work on someone's part it might be possible to port it - if anyone cares about that), and depends extensively on mpfr. It depends on the very latest version of both libraries (I think maybe I have a hacked MPIR and MPFR on my machine which represent the latest svn or something). flint2 is infinitely better than the flint 1.x.y series. Everything is much, much more reliable, cleanly coded, and in many cases faster (or it will be when done). Some things should be five times faster than in flint 1.5. when done. This is due to the radical redesign of flint from the ground up and a much greater attention to detail (including reduction of code bloat!!). One downer is that flint2 is *not* a drop-in replacement for flint1.x.y. Some people (probably me included) will have to work very hard to switch existing Sage code over. The interface is *necessarily* quite a bit different to flint 1.x.y, but the advantages for Sage are too numerous to list. There is absolutely *nothing* I can do to work around this. It simply isn't possible to support the old flint interface. The old flint will be completely deprecated. But my understanding is Sage doesn't use all that much from flint anyhow, so at most a handful of functions will be arranged differently and some work will have to go into switching them over. As always, flint2 is open for contribution. If you think you'd like to help at all, there's an enormous number of interesting things to do. There's everything from porting work, to reimplementing flint1 functions using the new flint2 paradigm, to implementation of some brand new ideas I've had whilst implementing flint2 which would improve things in some cases by really large factors, but which I haven't had time to work on. There's
[sage-devel] Re: Vote for including GLPK standard in Sage
On 6/21/10 11:20 AM, William Stein wrote: [ ] yes, include glpk [ ] no, don't because ___ Yes. 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: Vote for including GLPK standard in Sage
On Jun 21, 11:20 am, William Stein wst...@gmail.com wrote: This is an official call for a vote: Just some input to throw into the mix. About 16 months ago, out of curiosity, I signed up for the GLPK mailing list. It is fairly active at about 100 messages/month, with about a quarter of those from the official maintainer (Andrew Makhorin). Various folks seem interested in writing other front-ends on top of it. So based on limited observation, it seems to have a fairly healthy community with a responsive maintainer. Rob -- 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
