[sage-devel] save bug (filename dependent behaviour when saving list)
Hi all, there is a problem with save(), (at least) with sage 4.3, 4.3.1, 4.3.3. I found trac#2046, but i am not sure if it is connected. somehow the .sobj-suffixing mechanism seems to be broken. i'd suggest just leaving the filenames as specified. see below for the details. regards and thank You felix ## # the implementation works: sage: 1.save(foo) sage: load(foo) 1 # but then: sage: [1,2].save(foo) --- AttributeErrorTraceback (most recent call last) /home/felix/hesage/ipython console in module() AttributeError: 'list' object has no attribute 'save' ### # interestingly this works: sage: save([1,2],foo) sage: load(foo) [1, 2] ### # and now this is absurd: sage: save([1,2],foo.bar) --- AttributeErrorTraceback (most recent call last) /`pwd`/ipython console in module() /path/to/sage/local/lib/python2.6/site-packages/sage/structure/sage_object.so in sage.structure.sage_object.save (sage/structure/sage_object.c:8108)() AttributeError: 'list' object has no attribute 'save' ## # since this again works: sage: save(1,foo.bar) -- 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] make test fails on over 100 items with sage-4.3.3
Hello sage-devel, I built sage-4.3.3 and then ran make test. The test failed on over 100 items, see the log here: http://pastebin.com/3fF3HMbu The machine I did this with has the following specs: OS: Linux Processors: 4x Opteron 280 Memory: 8GB When I ran the build and when I ran the test this machine was all mine (i.e. no other users running anything) and this was the only thing running at that time. Could you please give me some hints/tips on how to solve this or find the cause? If you need more information, please let me know. Greetings, Erwin Junge -- 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: make test fails on over 100 items with sage-4.3.3
Hi again, I tried running the failed tests again, and now they all passed. Strange... Any ideas on why the tests failed the first time and not the second time? Greetings, Erwin Junge On Feb 26, 10:57 am, ErwinJunge erwinju...@gmail.com wrote: Hello sage-devel, I built sage-4.3.3 and then ran make test. The test failed on over 100 items, see the log here:http://pastebin.com/3fF3HMbu The machine I did this with has the following specs: OS: Linux Processors: 4x Opteron 280 Memory: 8GB When I ran the build and when I ran the test this machine was all mine (i.e. no other users running anything) and this was the only thing running at that time. Could you please give me some hints/tips on how to solve this or find the cause? If you need more information, please let me know. Greetings, Erwin Junge -- 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: experimental spkg: CHomP -- call for votes
On Feb 18, 6:00 pm, William Stein wst...@gmail.com wrote: We don't need a vote for experimental -- that's only for optional and standard. So, I've addedchompto experimental just now. Can you clarify this? My understanding was: 1) An experimental package addition should have a trac ticket, but anything reasonable should be allowed in. 2) An optional package should have a trac ticket, compile on supported platforms as much as possible, and at least work on the supported platforms. I suppose there are license issues as well as to what we can distribute. 3) A standard package should compile on all supported platforms, have a trac ticket, and if its new it should have a sort of probationary period as an optional package. Then a vote is taken here on sage- devel. I think having the CHomP package in is great, but perhaps there should have been a ticket for that? -Marshall -- 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: dream machine ideas
One thing that would be nice is to have a faster machine than t2 running solaris. -Marshall On Jan 22, 1:52 pm, William Stein wst...@gmail.com wrote: Hi, We are considering purchasing a new computer for the sage.math cluster, which will act partly as a Sage notebook server.The budget is about $20-30K (!). If you're a hardware lover, and have been looking at what one could get for that much money (tons of RAM? cores?) these days, let me know. We could just got 1 or 2 computers like sage.math.washington.edu (i.e., 24 2.6Ghz cores,128GBRAM, etc.)... but maybe there is something new or about to come out that we should be aware of? -- William -- William Stein Associate 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] Re: dream machine ideas
On Fri, Feb 26, 2010 at 7:20 AM, mhampton hampto...@gmail.com wrote: One thing that would be nice is to have a faster machine than t2 running solaris. We have disk.math.washington.edu, which is an 8-core 2.3Ghz opteron with 32GB of RAM, which runs *OpenSolaris*. Also, one could setup a Solaris 10 x86 virtual machine on boxen, which would be another way to get x86 solaris that is way faster than t2. Regarding sparc solaris, there are fast machines on skynet. -- William -Marshall On Jan 22, 1:52 pm, William Stein wst...@gmail.com wrote: Hi, We are considering purchasing a new computer for the sage.math cluster, which will act partly as a Sage notebook server. The budget is about $20-30K (!). If you're a hardware lover, and have been looking at what one could get for that much money (tons of RAM? cores?) these days, let me know. We could just got 1 or 2 computers like sage.math.washington.edu (i.e., 24 2.6Ghz cores,128GBRAM, etc.)... but maybe there is something new or about to come out that we should be aware of? -- William -- William Stein Associate 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 -- William Stein Associate 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: dream machine ideas
On 26 February 2010 15:31, William Stein wst...@gmail.com wrote: Regarding sparc solaris, there are fast machines on skynet. -- William Is there anything quicker than the Blade 2500, which is quite old? The fastest processor that machine could have is 1.6 GHz, which is pretty damm slow by today's standards. Something like an M3000 http://www.oracle.com/us/products/servers-storage/servers/sparc-enterprise/031588.htm with a much faster and modern CPU would be a lot quicker. Perhaps it is not possible, given 't2' was donated, but Sun might accept it in part-ex. In fact, a new M3000 is cheaper than a new T5240! 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: experimental spkg: CHomP -- call for votes
I got those networking failures when trying to build chomp on t2, using sage-4.3.0.1. If someone built chomp on t2, what sage version were you using? Thanks, Marshall On Feb 20, 10:25 am, Dr. David Kirkby david.kir...@onetel.net wrote: Robert Bradshaw wrote: The code looks quite clean - only two warnings. But it will not build on Solaris. I suspect it needs the right libraries linked, as things like gethostbyname need -lnsl. Networking Services Library Functions gethostbyname(3NSL) NAME gethostbyname,gethostbyname_r,gethostbyaddr, gethostbyaddr_r, gethostent, gethostent_r, sethostent, endhostent - get network host entry Surely these are unnecessary for computing homology, so hopefully they can be easily patched around. - Robert Perhaps they can, but the revised package (chomp-20100213.p0.spkg md5 checksum df74f1d69719f6e3469074fd9e84ae29) builds fine on the Blade 1000 I tested this on, and someone else reports it built on 't2' too. There are no warnings now, which is a small miracle given both options -Wall and -pedantic were given. Clearly the author(s) have taken some trouble over this code. 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] BipartiteGraph status
I'm having a lovely conversation with myself in the comments for trac #8350 that I want to share. :-) There are two related problems. 1. The current BipartiteGraph class is incomplete, see trac #1941. I want to use it, so I'm trying to plug some of the holes. In particular, trac #8350 suggests overriding add_vertex() and add_vertices() to properly maintain the bipartition data structures. 2. The current Graph code assumes vertices and edges can be added at will, e.g. the algorithm for is_cirular_planar(). Also, many other methods do not behave as expected for BipartiteGraphs, e.g. union() will return a Graph given two BipartiteGraph's. Problem 1 first. add_vertex() needs to maintain the bipartition sets. When a new vertex is added, it needs to go left or right. The natural solution is to include an extra argument or two in order to specify where the new vertex (vertices) will go. I thought I had a clever solution for problem (2): if a new vertex is added without specifying which partition it belongs to, just change the current object from a BipartiteGraph to a Graph instance. But now I think this is a really bad idea, since calling an arbitrary method that *should not* change the graph. For example, a test like is_circular_planar would suddenly and silently change the class of my object! I considered another option. Why not just wait until an edge is added to figure out whether a node is left or right? Because all the vertices should be in one set or the other at all times. For example, if I add a vertex and then iterate (before adding any edges) over the left and right subsets, the new vertex would be absent! OK, assume we solve (1) by requiring an indication of which partition a vertex belongs in and raising an exception otherwise. What about Graph algorithms that change the graph temporarily or just don't do the right thing for BipartiteGraph's? I see a few possibilities. A. Change BipartiteGraph so that it doesn't inherit from Graph. This requires adding a bunch of code to bring the BipartiteGraph functionality to par with Graph. Also, any future methods added to Graph will need to be duplicated (often simply delegated) in BipartiteGraph. PRO: clean separation, BipartiteGraph should always work. CON: BipartiteGraph will likely lag behind Graph in functionality; perhaps small performance loss for delegation. B. Make BipartiteGraph handling an integral part of the Graph class, similar to DiGraph and the '_directed attribute. This requires a thorough review of the current Graph code to see where bipartite-ness must be taken into account or can be exploited (optional). Also, future methods will need to be aware of the possibility of operating on BipartiteGraphs. PRO: similar to current DiGraph solution; most likely to keep BipartiteGraph and Graph features equal. CON: some Graph methods may break for BipartiteGraph instances; some methods may run a little slower due to extra conditional handling. C. Continue as we do now, i.e. BipartiteGraph is a subclass of Graph and overrides methods when necessary. This requires a thorough review of the current Graph code to see where bipartite-ness must be taken into account or can be exploited (optional). These methods will need overrides in BipartiteGraph. Also, future methods in the Graph class will need this same review. PRO: clean separation; perhaps a little less work initially. CON: future Graph methods most likely to break for BipartiteGraph instances; some duplication of code possible for similar but distinct BipartiteGraph algorithms. SUMMARY: All of the options require a good chunk of work to really finish the BipartiteGraph class. (I will not have time to finish this task soon.) I think option (B) is best: it's similar to the current DiGraph situation; many new Graph methods will just work for BipartiteGraph (not constantly playing catch-up); and the BipartiteGraph case is most likely to be noticed, handled and tested by people working on the Graph class -- once someone does the big chunk of work. I suppose since I'm not committing to doing the work, I'm asking for a policy decision so I can fix my pressing problems appropriately. I also volunteer to put comments at the top of graph.py and bipartite_graph.py explaining problem and the policy. :-) Thanks! - Ryan -- 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: experimental spkg: CHomP -- call for votes
On Feb 26, 8:51 am, mhampton hampto...@gmail.com wrote: I got those networking failures when trying to build chomp on t2, using sage-4.3.0.1. If someone built chomp on t2, what sage version were you using? Did you use the .p0 version of the chomp spkg? See below for the link. I built it on t2, but by hand: executing the commands in the spkg-install file manually, because I don't have my own copy of a sage installation. I guess I could copy the system one to a /scratch directory, but I haven't gotten around to doing that yet. http://sage.math.washington.edu/home/palmieri/SPKG/chomp-20100213.p0.spkg -- John -- 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: experimental spkg: CHomP -- call for votes
On 26 February 2010 17:44, John H Palmieri jhpalmier...@gmail.com wrote: On Feb 26, 8:51 am, mhampton hampto...@gmail.com wrote: Did you use the .p0 version of the chomp spkg? See below for the link. I built it on t2, but by hand: executing the commands in the spkg-install file manually, because I don't have my own copy of a sage installation. I guess I could copy the system one to a /scratch directory, but I haven't gotten around to doing that yet. http://sage.math.washington.edu/home/palmieri/SPKG/chomp-20100213.p0.spkg -- John If you use a simple copy, then you will probably find that the links will be copied as files, which will make for a huge installation. I'd copy http://boxen.math.washington.edu/sage/solaris/sage-4.3.0.1-Solaris-10-SPARC-sun4u-or-sun4v.tar.7z to your home directory, and use 'p7zip -d filename' to decompress the binary. I believe you can then add your own package and test it. It certainly did build on my Blade 1000, with an unusually low number of warnings. 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: make test fails on over 100 items with sage-4.3.3
No idea. They're all timeout failures, but the other timings seem reasonable. If it doesn't pop up again I wouldn't worry about it too much. David On Fri, Feb 26, 2010 at 5:46 AM, ErwinJunge erwinju...@gmail.com wrote: Hi again, I tried running the failed tests again, and now they all passed. Strange... Any ideas on why the tests failed the first time and not the second time? Greetings, Erwin Junge On Feb 26, 10:57 am, ErwinJunge erwinju...@gmail.com wrote: Hello sage-devel, I built sage-4.3.3 and then ran make test. The test failed on over 100 items, see the log here:http://pastebin.com/3fF3HMbu The machine I did this with has the following specs: OS: Linux Processors: 4x Opteron 280 Memory: 8GB When I ran the build and when I ran the test this machine was all mine (i.e. no other users running anything) and this was the only thing running at that time. Could you please give me some hints/tips on how to solve this or find the cause? If you need more information, please let me know. Greetings, Erwin Junge -- 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.comsage-devel%2bunsubscr...@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] BipartiteGraph status
This is an interesting post. A few informal comments below. On Fri, Feb 26, 2010 at 12:05 PM, Ryan Hinton iob...@email.com wrote: I'm having a lovely conversation with myself in the comments for trac #8350 that I want to share. :-) There are two related problems. 1. The current BipartiteGraph class is incomplete, see trac #1941. I want to use it, so I'm trying to plug some of the holes. In particular, trac #8350 suggests overriding add_vertex() and add_vertices() to properly maintain the bipartition data structures. 2. The current Graph code assumes vertices and edges can be added at will, e.g. the algorithm for is_cirular_planar(). Also, many other methods do not behave as expected for BipartiteGraphs, e.g. union() will return a Graph given two BipartiteGraph's. Problem 1 first. add_vertex() needs to maintain the bipartition sets. When a new vertex is added, it needs to go left or right. The natural solution is to include an extra argument or two in order to specify where the new vertex (vertices) will go. I thought I had a clever solution for problem (2): if a new vertex is added without specifying which partition it belongs to, just change the current object from a BipartiteGraph to a Graph instance. But now I think this is a really bad idea, since calling an arbitrary method that *should not* change the graph. For example, a test like is_circular_planar would suddenly and silently change the class of my object! Agreed, this is not the solution. I considered another option. Why not just wait until an edge is added to figure out whether a node is left or right? Because all the vertices should be in one set or the other at all times. For example, if I add a vertex and then iterate (before adding any edges) over the left and right subsets, the new vertex would be absent! OK, assume we solve (1) by requiring an indication of which partition a vertex belongs in and raising an exception otherwise. What about Graph algorithms that change the graph temporarily or just don't do the right thing for BipartiteGraph's? I see a few possibilities. It seems you are suggesting that there should be 2 ways to add a vertex to a bipartite graph. Either add_vertex with a required parameter specifying which vertex set to add it to, or using add_edge? I don't see a problem off-hand. A. Change BipartiteGraph so that it doesn't inherit from Graph. This requires adding a bunch of code to bring the BipartiteGraph functionality to par with Graph. Also, any future methods added to Graph will need to be duplicated (often simply delegated) in BipartiteGraph. I personally favor this as it seems to me (and I definitely could be wrong) that the code will be more readable in this case. If every method in graph.py must test if the graph is bipartite or not, that makes it more difficult read and more difficult to debug, IMHO. PRO: clean separation, BipartiteGraph should always work. CON: BipartiteGraph will likely lag behind Graph in functionality; perhaps small performance loss for delegation. ... SUMMARY: All of the options require a good chunk of work to really finish the BipartiteGraph class. (I will not have time to finish this task soon.) I think option (B) is best: it's similar to the current DiGraph situation; many new Graph methods will just work for BipartiteGraph (not constantly playing catch-up); and the BipartiteGraph case is most likely to be noticed, handled and tested by people working on the Graph class -- once someone does the big chunk of work. I suppose since I'm not committing to doing the work, I'm asking for a policy decision so I can fix my pressing problems appropriately. I also volunteer to put comments at the top of graph.py and bipartite_graph.py explaining problem and the policy. :-) Hopefully, others will reply who know more about the graph theory code structure thank I do. Thanks! - Ryan -- 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] Two numerical noise tickets for review
If anyone has a spare minute, there are a coupler of tickets I created for numerical noise issues on Solaris. http://trac.sagemath.org/sage_trac/ticket/8375 http://trac.sagemath.org/sage_trac/ticket/8374 They should not take long to review. 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] Suggestion to add date+time to test.log
If one runs 'make test' it creates a file test.log in $HOME/.sage/tmp If would be useful if that file had the date and time in its name, or even the PID so one could test multiple versions of Sage on the same machine at the same time. 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: BipartiteGraph status
Thanks for the reply. Response to your suggestions below. On Feb 26, 1:21 pm, David Joyner wdjoy...@gmail.com wrote: ...snip... I considered another option. Why not just wait until an edge is added to figure out whether a node is left or right? Because all the vertices should be in one set or the other at all times. For example, if I add a vertex and then iterate (before adding any edges) over the left and right subsets, the new vertex would be absent! It seems you are suggesting that there should be 2 ways to add a vertex to a bipartite graph. Either add_vertex with a required parameter specifying which vertex set to add it to, or using add_edge? I don't see a problem off-hand. Let me clarify my suggestion. add_vertex could have a limbo set -- neither left nor right -- and nodes could be moved from limbo to the appropriate set when an edge is added. In short, we know what set a node should be in once it has an edge, but not immediately upon adding it. Allowing add_edge to also create the node is interesting, but doesn't solve the problem of what to do when add_vertex is called with insufficient information. A. Change BipartiteGraph so that it doesn't inherit from Graph. This requires adding a bunch of code to bring the BipartiteGraph functionality to par with Graph. Also, any future methods added to Graph will need to be duplicated (often simply delegated) in BipartiteGraph. I personally favor this as it seems to me (and I definitely could be wrong) that the code will be more readable in this case. If every method in graph.py must test if the graph is bipartite or not, that makes it more difficult read and more difficult to debug, IMHO. Yes, this is the purest approach. On the other hand, a large fraction of the Graph methods will work *unchanged* for BipartiteGraph instances. And the vast majority of those that do need changes require only minor adjustments. Personally, adding a little extra code to (Generic)Graph is preferable to duplicating lots of code (and possible bugs) in BipartiteGraph. Thanks for your opinion! - Ryan -- 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: make test fails on over 100 items with sage-4.3.3
You could try stressing that install a little more by testing with the -long option. If those pass then I wouldn't worry about it too much. Perhaps some system process like a file-indexer fired up in the middle of the first run? -Marshall On Feb 26, 4:46 am, ErwinJunge erwinju...@gmail.com wrote: Hi again, I tried running the failed tests again, and now they all passed. Strange... Any ideas on why the tests failed the first time and not the second time? Greetings, Erwin Junge On Feb 26, 10:57 am, ErwinJunge erwinju...@gmail.com wrote: Hello sage-devel, I built sage-4.3.3 and then ran make test. The test failed on over 100 items, see the log here:http://pastebin.com/3fF3HMbu The machine I did this with has the following specs: OS: Linux Processors: 4x Opteron 280 Memory: 8GB When I ran the build and when I ran the test this machine was all mine (i.e. no other users running anything) and this was the only thing running at that time. Could you please give me some hints/tips on how to solve this or find the cause? If you need more information, please let me know. Greetings, Erwin Junge -- 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] Two numerical noise tickets for review
GIven that this pops up again and again, and works on every other platform (these are not tests with lots of rounding), is there any way to get Solaris to compile the correct constant double for e? On Feb 26, 2010, at 10:29 AM, David Kirkby wrote: If anyone has a spare minute, there are a coupler of tickets I created for numerical noise issues on Solaris. http://trac.sagemath.org/sage_trac/ticket/8375 http://trac.sagemath.org/sage_trac/ticket/8374 They should not take long to review. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: experimental spkg: CHomP -- call for votes
OK, your .p0 package installed fine on t2, using sage-4.3.0.1. If its helpful to you, I have a copy of that at: http://sage.math.washington.edu/home/mhampton/solaris/sage-4.3.0.1-Solaris-10-SPARC-sun4u-or-sun4v.tar The package that is currently in the experimental repository must be an earlier effort of yours - it is missing the patches to the makefile. That one installed OK on OS X for me, but it would be good if someone can update it to your .p0 version. -Marshall On Feb 26, 11:44 am, John H Palmieri jhpalmier...@gmail.com wrote: On Feb 26, 8:51 am, mhampton hampto...@gmail.com wrote: I got those networking failures when trying to build chomp on t2, using sage-4.3.0.1. If someone built chomp on t2, what sage version were you using? Did you use the .p0 version of the chomp spkg? See below for the link. I built it on t2, but by hand: executing the commands in the spkg-install file manually, because I don't have my own copy of a sage installation. I guess I could copy the system one to a /scratch directory, but I haven't gotten around to doing that yet. http://sage.math.washington.edu/home/palmieri/SPKG/chomp-20100213.p0 -- John -- 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] Two numerical noise tickets for review
On 26 February 2010 19:21, Robert Bradshaw rober...@math.washington.edu wrote: GIven that this pops up again and again, and works on every other platform (these are not tests with lots of rounding), is there any way to get Solaris to compile the correct constant double for e? There are other maths libraries, and I know someone reported on comp.unix.solaris that one did give the other value for e. But I'd hate to think what mess it would create to try to change the maths libraries. Fine on a simple bit of C code, but not on 100 packages. Dave On Feb 26, 2010, at 10:29 AM, David Kirkby wrote: If anyone has a spare minute, there are a coupler of tickets I created for numerical noise issues on Solaris. http://trac.sagemath.org/sage_trac/ticket/8375 http://trac.sagemath.org/sage_trac/ticket/8374 They should not take long to review. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- 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] Suggestion to add date+time to test.log
On 26-Feb-10, at 10:41 AM, David Kirkby wrote: If one runs 'make test' it creates a file test.log in $HOME/.sage/tmp If would be useful if that file had the date and time in its name, or even the PID so one could test multiple versions of Sage on the same machine at the same time. +1. Could I suggest that the file itself include such information, if it does not already, and that test.log be a symlink to the latest version (caveat race conditions, etc, that the OS is intended to handle). Nick -- 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] Sanity check on objects, parents and elements
Hi there, In order to sanitize the behavior of objects, parents and elements in sage, I'm about to add some tests to the framework. I think they are all reasonable but I may be asking to much. Please comment about the following: 1 - Any SageObject must have an equality methods such that self == self and self != None 2 - Element construction should be idempotent. More precisely, for any element e within parent P, the equality P(e) == e must hold. This is for example needed by the constructor of many Parent with a base ring, such as matrices. 3 - .zero() and .one() must never be mutable. I'd like to enforce this by computing .__hash__(). Here I see two possibilities: * decide that for any monoid M, if M.one() implement __hash__ it must returns an int (not an Integer) and not raise an exception like in sage: m = matrix([1]).__hash__() ... TypeError: mutable matrices are unhashable * decide that any element of a monoid must be hashable. Do you think this is asking too much ? By the way, if you have ideas of other basic sanity checks which must be added please tell me. Cheers, Florent, back from Sage days 20. PS: Sage days 20 were extremely fun and enjoyable ! Though we worked quite hard (I typically went to bed at 3 and woke up at 8), we haven't been producing that much code but I think we recruited a *lot* of new users among which there may be many developers. A progress report is being written and should be posted very soon. I need some rest now :-) -- 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] Sanity check on objects, parents and elements
Hi Sorry for replying to myself. In order to sanitize the behavior of objects, parents and elements in sage, I'm about to add some tests to the framework. I think they are all reasonable but I may be asking to much. Please comment about the following: 1 - Any SageObject must have an equality methods such that self == self and self != None 2 - Element construction should be idempotent. More precisely, for any element e within parent P, the equality P(e) == e must hold. This is for example needed by the constructor of many Parent with a base ring, such as matrices. 3 - .zero() and .one() must never be mutable. I'd like to enforce this by computing .__hash__(). Here I see two possibilities: * decide that for any monoid M, if M.one() implement __hash__ it must returns an int (not an Integer) and not raise an exception like in sage: m = matrix([1]).__hash__() ... TypeError: mutable matrices are unhashable The following sentence is ambiguous: * decide that any element of a monoid must be hashable. Please replace it by: * decide that element of any monoid must have a __hash__ method, which may raise an error for mutable element but never on .one() (and .zero() in a commutative monoid). Do you think this is asking too much ? By the way, if you have ideas of other basic sanity checks which must be added please tell me. Cheers, Florent -- 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] Sanity check on objects, parents and elements
On Fri, Feb 26, 2010 at 3:59 PM, Florent Hivert florent.hiv...@univ-rouen.fr wrote: Hi there, In order to sanitize the behavior of objects, parents and elements in sage, I'm about to add some tests to the framework. I think they are all reasonable but I may be asking to much. Please comment about the following: 1 - Any SageObject must have an equality methods such that self == self and self != None I don't think this should be true for an arbitrary SageObject. There are some (eg subclasses of sage.factory.UniqueFactory) that are mainly used either internally or as object constructors. I don't think we need to support GF == GF for example. Requiring it for Parents and Elements seems completely reasonable on the other hand. Perhaps CategoryObjects as well. 2 - Element construction should be idempotent. More precisely, for any element e within parent P, the equality P(e) == e must hold. This is for example needed by the constructor of many Parent with a base ring, such as matrices. +1 3 - .zero() and .one() must never be mutable. I'd like to enforce this by computing .__hash__(). Here I see two possibilities: * decide that for any monoid M, if M.one() implement __hash__ it must returns an int (not an Integer) and not raise an exception like in sage: m = matrix([1]).__hash__() ... TypeError: mutable matrices are unhashable I have no problem with requiring an int return value, though I'm not sure how compliant the current sage library is with this condition. I don't like the requirement that __hash__ never raise an error: we want to allow mutable matrices. * decide that element of any monoid must have a __hash__ method, which may raise an error for mutable element but never on .one() (and .zero() in a commutative monoid). This seems like the better option. Though some have raised objections to the idea of zero() and one() returning immutable elements, it did seem to be the consensus in that thread. 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
[sage-devel] Re: experimental spkg: CHomP -- call for votes
The p0 doesn't build for me on Fedora 12 gcc 4.4.3. Adding #include stdio.h fixes it. You can get the (trivially) patched src/include/ chomp/multiwork/mwdata.h from http://www.stp.dias.ie/~vbraun/mwdata.h With this change, it builds fine. Volker - build log -- make[2]: Entering directory `/home/vbraun/opt/sage-4.3.3/spkg/build/ chomp-20100213.p1/src/make' g++ -O2 -ansi -pedantic -Wall -I../include -o ../obj/multiwork/mw.o - c ../src/multiwork/mw.cpp In file included from ../include/chomp/multiwork/mw.h:53, from ../src/multiwork/mw.cpp:32: ../include/chomp/multiwork/mwdata.h: In function ‘std::istream chomp::multiwork::operator(std::istream, chomp::multiwork::mwData)’: ../include/chomp/multiwork/mwdata.h:878: error: ‘EOF’ was not declared in this scope make[2]: *** [../obj/multiwork/mw.o] Error 1 make[2]: Leaving directory `/home/vbraun/opt/sage-4.3.3/spkg/build/ chomp-20100213.p1/src/make' make[1]: *** [multiwork] Error 2 make[1]: Leaving directory `/home/vbraun/opt/sage-4.3.3/spkg/build/ chomp-20100213.p1/src/make' make: *** [CHomP] Error 2 -- 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] Sanity check on objects, parents and elements
Quick question: many types have methods one_element() and zero_element() which are used a lot. For example, ZZ.one() and ZZ.zero() are aliases for ZZ.one_element() and ZZ.zero_element(). Is your intention to deprecate these longer names? John On 26 February 2010 21:16, David Roe r...@math.harvard.edu wrote: On Fri, Feb 26, 2010 at 3:59 PM, Florent Hivert florent.hiv...@univ-rouen.fr wrote: Hi there, In order to sanitize the behavior of objects, parents and elements in sage, I'm about to add some tests to the framework. I think they are all reasonable but I may be asking to much. Please comment about the following: 1 - Any SageObject must have an equality methods such that self == self and self != None I don't think this should be true for an arbitrary SageObject. There are some (eg subclasses of sage.factory.UniqueFactory) that are mainly used either internally or as object constructors. I don't think we need to support GF == GF for example. Requiring it for Parents and Elements seems completely reasonable on the other hand. Perhaps CategoryObjects as well. 2 - Element construction should be idempotent. More precisely, for any element e within parent P, the equality P(e) == e must hold. This is for example needed by the constructor of many Parent with a base ring, such as matrices. +1 3 - .zero() and .one() must never be mutable. I'd like to enforce this by computing .__hash__(). Here I see two possibilities: * decide that for any monoid M, if M.one() implement __hash__ it must returns an int (not an Integer) and not raise an exception like in sage: m = matrix([1]).__hash__() ... TypeError: mutable matrices are unhashable I have no problem with requiring an int return value, though I'm not sure how compliant the current sage library is with this condition. I don't like the requirement that __hash__ never raise an error: we want to allow mutable matrices. * decide that element of any monoid must have a __hash__ method, which may raise an error for mutable element but never on .one() (and .zero() in a commutative monoid). This seems like the better option. Though some have raised objections to the idea of zero() and one() returning immutable elements, it did seem to be the consensus in that thread. 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 -- 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] Sanity check on objects, parents and elements
On 26-Feb-10, at 12:59 PM, Florent Hivert wrote: Hi there, In order to sanitize the behavior of objects, parents and elements in sage, I'm about to add some tests to the framework. I think they are all reasonable but I may be asking to much. I think your suggestions are reasonable, and am a strong +1 to these automated testing frameworks. Nick -- 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] Sanity check on objects, parents and elements
Hi David, In order to sanitize the behavior of objects, parents and elements in sage, I'm about to add some tests to the framework. I think they are all reasonable but I may be asking to much. Please comment about the following: 1 - Any SageObject must have an equality methods such that self == self and self != None I don't think this should be true for an arbitrary SageObject. There are some (eg subclasses of sage.factory.UniqueFactory) that are mainly used either internally or as object constructors. I don't think we need to support GF == GF for example. Requiring it for Parents and Elements seems completely reasonable on the other hand. Perhaps CategoryObjects as well. Ok This is easy to change... [...] 3 - .zero() and .one() must never be mutable. I'd like to enforce this by computing .__hash__(). Here I see two possibilities: * decide that for any monoid M, if M.one() implement __hash__ it must returns an int (not an Integer) and not raise an exception like in sage: m = matrix([1]).__hash__() ... TypeError: mutable matrices are unhashable I have no problem with requiring an int return value, though I'm not sure how compliant the current sage library is with this condition. The best way to know is to check (in progress). I'm expecting to catch some bugs with it. I'll see how hard it is to fix the lib accordingly. The framework allows to make case by case exception. Anyway, it's certainly good to know. I don't like the requirement that __hash__ never raise an error: we want to allow mutable matrices. Of course I'm not forgetting mutable matrices. Let me restate. Please choose between (or suggest something else): Strong requirement: For any Monoid. __hash__ *must* be implemented and it don't raise an error for .one() (Idem for CommutativeMonoids and zero()) Weak requirement: For any monoid M, if M.one() implement __hash__ it must returns an int. This seems like the better option. Though some have raised objections to the idea of zero() and one() returning immutable elements, it did seem to be the consensus in that thread. So I understand that you'll go for strong requirement. I'm sorry for not making myself clear it the first mail. I'm not accustomed in writing computer-law statement like SEP (Sage Enhancement Proposal :-) Cheers, Florent -- 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] Sanity check on objects, parents and elements
Quick question: many types have methods one_element() and zero_element() which are used a lot. For example, ZZ.one() and ZZ.zero() are aliases for ZZ.one_element() and ZZ.zero_element(). Is your intention to deprecate these longer names? I had the impression that this has been already decided see eg [1]: def one_element(self): r Backward compatibility alias for :meth:`self.one()`. TESTS:: sage: S = Monoids().example() sage: S.one_element() '' return self.one() Though I can't find the thread. Also, In the category roadmap [2]: A.one() A.zero() a.is_one() a.is_zero() A(1) A(0) when it makes sense A.one_element() A.zero_element() deprecated in the doc; fully deprecated later. Cheers, Florent [1] sage/categories/monoids.py [2] http://trac.sagemath.org/sage_trac/wiki/CategoriesRoadMap -- 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: dream machine ideas
One should definitely look into possibility of buying a BladCenter. The support for InfiniBand and Server RAID, many storage options and highly configurable interfaces make this system an outstanding hardware to work on. There is always an opportunity for hardware diversity also. That makes possible even experiments with hardware. #Serge William Stein wrote: On Sun, Jan 24, 2010 at 7:42 AM, Joshua Herman zitterbeweg...@gmail.com wrote: Man i'm drooling over this thread already. What about some type of blade system like from IBM? http://www-03.ibm.com/systems/bladecenter/ I consider that approach last year (in late 2008). Then, without surprisingly expensive add-ons, blade systems appear like a bunch of separate machines with a (very) fast network. This is more work to manage for a sysadmin, and much more difficult to use for end users. It may be worth looking into this again. william On Sun, Jan 24, 2010 at 4:10 AM, Robert Bradshaw rober...@math.washington.edu wrote: On Jan 22, 2010, at 2:49 PM, Tom Boothby wrote: On Fri, Jan 22, 2010 at 1:48 PM, Simon King simon.k...@nuigalway.ie wrote: Would it be possible to have a faster disk system in *general* (i.e., in the /home part)? I don't know, I am no hardware expert, perhaps NFS==slow. But that would be a nice thing to have. Of course our disk server had other major issues recently, so I don't know if that's a good measure of how well NFS works. While we're dreaming, it would be nice if all the machines had a /scratch, and if we're looking at new ones maybe something better than a usb drive hanging out of the back (perhaps even local raid). Actually, for some applications, sage.math isn't the fastest. Excellent points! I'm definitely in favor of adding a few larger hard drives to the machines, because I really hate our current setup with USB drives cluttering up the rack. With regard to speed... there are faster processors out there, but this comes at the cost of cores. We could run 16 cores at 3.4GHz, which I could get behind. We could push this further, and cut down to 8 cores at 3.7GHz, but I don't think that's a worthwhile tradeoff. I like the idea of having a box with fewer but faster cores for the not-as-parallelizeable tasks. 16/3.4GHz seems like a nice compromise. (What is the speed of a new 24-core setup?) Of course well-used notebook servers like sagenb.org are very parallelizeable. By the way, I am -1 to having just two more identical machines. Why not foster some diversity? Because the hardware is a *dream* to work with. The design is modular with captive screws, the rails snap into the rack and slide out smoothly, the ILOM makes it possible to hard boot / diagnose hardware from a remote location (we can flash the BIOS from anywhere in the world!) I really like being able to switch between machines and use the same binaries, so that's a reason to reduce hardware diversity. - 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 -- 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: experimental spkg: CHomP -- call for votes
On Feb 26, 1:20 pm, Volker Braun vbraun.n...@gmail.com wrote: The p0 doesn't build for me on Fedora 12 gcc 4.4.3. Adding #include stdio.h fixes it. You can get the (trivially) patched src/include/ chomp/multiwork/mwdata.h from http://www.stp.dias.ie/~vbraun/mwdata.h With this change, it builds fine. Thanks for testing it out. I don't know much about compiling programs, but it looks like it's safe to make this change regardless of the platform. Does that seem right? (That would make the spkg-install file easy to change; otherwise, I don't know on which platforms to apply this patch...) An updated spkg (making your change on all platforms) is here: http://sage.math.washington.edu/home/palmieri/SPKG/chomp-20100213.p1.spkg It builds on my Mac, on sage.math, and on t2 (sparc). -- John -- 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: experimental spkg: CHomP -- call for votes
On Feb 26, 10:13 am, David Kirkby david.kir...@onetel.net wrote: I'd copyhttp://boxen.math.washington.edu/sage/solaris/sage-4.3.0.1-Solaris-10... to your home directory, and use 'p7zip -d filename' to decompress the binary. I believe you can then add your own package and test it. Thanks, I've done that, and it seems to work. I used sage -f chomp... and it built chomp just fine. I'm a little puzzled about why, when I just changed some Python files in the Sage library, running sage -br triggered a rebuild of all of the cython files, but anyway... -- John -- 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] Suggestion to add date+time to test.log
Nick Alexander wrote: On 26-Feb-10, at 10:41 AM, David Kirkby wrote: If one runs 'make test' it creates a file test.log in $HOME/.sage/tmp If would be useful if that file had the date and time in its name, or even the PID so one could test multiple versions of Sage on the same machine at the same time. +1. Could I suggest that the file itself include such information, if it does not already, and that test.log be a symlink to the latest version (caveat race conditions, etc, that the OS is intended to handle). Nick I think creating a link might not be such a good idea, as potentially one would test multiple versions of Sage on different hosts. I've created a ticket for this. http://trac.sagemath.org/sage_trac/ticket/8385 I think in addition to date and time, the hostname and sage version number would be useful too, though getting the sage version is less important, as it is stored in the file. It is also more difficult to get. Currently the file $SAGE_ROOT/local/bin/sage-maketest actually creates $HOME/.sage/tmp/test.log with this bit of code. SAGE_TEST_LOG=$SAGE_TESTDIR/test.log Adding to that the hostname, date and time would be trivial. Does anyone know where that file is stored? Any more comments on this? So far just one +1. 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] Suggestion to add date+time to test.log
+1 from me. David On Fri, Feb 26, 2010 at 1:41 PM, David Kirkby david.kir...@onetel.netwrote: If one runs 'make test' it creates a file test.log in $HOME/.sage/tmp If would be useful if that file had the date and time in its name, or even the PID so one could test multiple versions of Sage on the same machine at the same time. 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.comsage-devel%2bunsubscr...@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] Suggestion to add date+time to test.log
David Roe wrote: +1 from me. David Thanks. How many +1's do we need before it gets done? I can implement this easily and quickly, so don't mind doing it myself. I currently have two versions of Sage I'd like to test, but can't do them in parallel, despite the multiple processors I have. Dave On Fri, Feb 26, 2010 at 1:41 PM, David Kirkby david.kir...@onetel.net mailto:david.kir...@onetel.net wrote: If one runs 'make test' it creates a file test.log in $HOME/.sage/tmp If would be useful if that file had the date and time in its name, or even the PID so one could test multiple versions of Sage on the same machine at the same time. Dave -- To post to this group, send an email to sage-devel@googlegroups.com mailto:sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com mailto:sage-devel%2bunsubscr...@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 -- 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] Sanity check on objects, parents and elements
On Feb 26, 2010, at 12:59 PM, Florent Hivert wrote: Hi there, In order to sanitize the behavior of objects, parents and elements in sage, I'm about to add some tests to the framework. I think they are all reasonable but I may be asking to much. Please comment about the following: 1 - Any SageObject must have an equality methods such that self == self and self != None 2 - Element construction should be idempotent. More precisely, for any element e within parent P, the equality P(e) == e must hold. This is for example needed by the constructor of many Parent with a base ring, such as matrices. Elements of real interval fields don't satisfy the above two constraints (the notion of equality for intervals being that every element of the first interval is equal to every element in the second). - 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] Two numerical noise tickets for review
Robert Bradshaw wrote: GIven that this pops up again and again, and works on every other platform (these are not tests with lots of rounding), is there any way to get Solaris to compile the correct constant double for e? I rushed my previous email about this, since I had to leave to get a train. Linking with 'libmopt' with the Sun compiler will produce the correct value for e, but I don't know of any way to do this with gcc. The Sun compiler can not yet build Sage. As much as I know it is bit of a pain to change the doctest, and then to get some kind sole to review the changes, I believe that is insignificant compared to the amount of work needed to get all the packages in Sage to use another library. Using a quick check with grep, I do not believe there are any more tests in Sage that are failing as a result of this issue with 'e'. So hopefully those two tickets are the last that need to deal with 'e'. Dave libmopt On Feb 26, 2010, at 10:29 AM, David Kirkby wrote: If anyone has a spare minute, there are a coupler of tickets I created for numerical noise issues on Solaris. http://trac.sagemath.org/sage_trac/ticket/8375 http://trac.sagemath.org/sage_trac/ticket/8374 They should not take long to review. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] BipartiteGraph status
On Fri, Feb 26, 2010 at 9:05 AM, Ryan Hinton iob...@email.com wrote: ... OK, assume we solve (1) by requiring an indication of which partition a vertex belongs in and raising an exception otherwise. What about Graph algorithms that change the graph temporarily or just don't do the right thing for BipartiteGraph's? I see a few possibilities. I would strongly suggest this approach, i.e. option (C). As it currently stands, a BipartiteGraph is essentially a Graph, together with a bipartition and a few specialized functions. When you add a vertex to this kind of object, it only stays this kind of object if you specify which cell of the partition the vertex should go in. If you don't specify, it should raise an error. Otherwise a Bipartite Graph becomes something much more spooky and complicated, with limbo vertices etc. Imagine a graph theorist who didn't know internals trying to make sense of what was going on! Then for Graph algorithms that don't do the right thing for BipartiteGraphs, just override them all. If you don't feel like rewriting all of them, raise NotImplemented errors. Anything in Graphs that depend on BG's that don't do this properly will loudly and clearly raise errors and then they can get fixed. Any of the other approaches listed here seem prone to introduce a lot of bugs and suck up a lot of developer time, both now and later. C. Continue as we do now, i.e. BipartiteGraph is a subclass of Graph and overrides methods when necessary. This requires a thorough review of the current Graph code to see where bipartite-ness must be taken into account or can be exploited (optional). Back when #1941 was created, this thorough review was done. It may need to be updated. PRO: clean separation; perhaps a little less work initially. CON: future Graph methods most likely to break for BipartiteGraph instances; some duplication of code possible for similar but distinct BipartiteGraph algorithms. I want to say that the majority of algorithms will be untouched by this approach, and that using Python's advanced class-handling capabilities will minimize code duplication. -- 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] experimental spkg: CHomP -- call for votes
On Thu, Feb 18, 2010 at 4:00 PM, William Stein wst...@gmail.com wrote: We don't need a vote for experimental -- that's only for optional and standard. So, I've added chomp to experimental just now. Why don't we have a vote to make it optional? It seems like pretty solid code, much better than most of the other experimental packages. -- 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
[sage-devel] Procedure for experimental/optional/standard packages
On Feb 18, 6:00 pm, William Stein wst...@gmail.com wrote: We don't need a vote for experimental -- that's only for optional and standard. So, I've addedchompto experimental just now. Can you clarify this? My understanding was: 1) An experimental package addition should have a trac ticket, but anything reasonable should be allowed in. 2) An optional package should have a trac ticket, compile on supported platforms as much as possible, and at least work on the supported platforms. I suppose there are license issues as well as to what we can distribute. 3) A standard package should compile on all supported platforms, have a trac ticket, and if its new it should have a sort of probationary period as an optional package. Then a vote is taken here on sage- devel. I think having the CHomP package in is great, but perhaps there should have been a ticket for that? -Marshall On Feb 26, 7:06 pm, Robert Miller r...@rlmiller.org wrote: On Thu, Feb 18, 2010 at 4:00 PM, William Stein wst...@gmail.com wrote: We don't need a vote for experimental -- that's only for optional and standard. So, I've added chomp to experimental just now. Why don't we have a vote to make it optional? It seems like pretty solid code, much better than most of the other experimental packages. -- 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
