[sage-combinat-devel] Re: Species: Seriell-parallel networks
Here is a try
Z=species.SingletonSpecies()
E2=species.SetSpecies(min=2)
P=CombinatorialSpecies()
S=CombinatorialSpecies()
P.define(E2.composition(Z+S))
S.define(E2.composition(Z+P))
N=Z+P+S
That seems to work :
sage: koko=N.generating_series().coefficients(8)
sage: [koko[i]*factorial(i) for i in range(len(koko))]
[0, 1, 2, 8, 52, 472, 5504, 78416]
compare with https://oeis.org/A006351
Frederic
On 25 juil, 13:12, Frank Zenter zent...@gmail.com wrote:
Dear combinat-developers,
for my research I would lik to study thespeciesof series-parallel
networks.
In EOIS as sloane.A006351 they propose the combstruct-code
spec := [ N, {N=Union(Z, S, P), S=Set(Union(Z, P), card=2),
P=Set(Union(Z, S), card=2)}, labeled ]:
How can I make that using sage-combinat?
A search in the reference manual did not help, so I hope you can help
me.
(by the way: there seems to be a typo in the manual. As operations onSpecies
the second item should read ProductSpecies and not SumSpecies)
Thank you for your help.
Frank
--
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-devel@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] Sage Pari
On 2011-07-25 21:57, Karim Belabas wrote: We badly need feedback at a higher level, from developpers or would-be developpers, regarding the features they think are lacking in Pari, and are preventing them from developping in Pari the way they would like to. I'm sorry to say this (I would certainly like it the other way) but it has happened at least twice to me that I wrote some code for PARI (not adding huge new features but some smaller things) and that the response from the developers was not really positive. So I personally do not feel very welcome. PARI days sounds like a very good idea. -- 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 Pari
Hi Simon, After reading what you wrote, I fully agree with you. Your distinction between citing a citation and citing the original work is a useful one. This would happen naturally if you focused on identifying the algorithm and understanding its limitations, as I recommended. But they way you have put it is more nuanced and sensible. Actually, regarding thin wrappers, nothing irritates me more than a programmer saying we have just implemented feature X in system Y when what they mean is they wrapped function W from external library Z and called it an implementation of feature X. [This issue actually grates on me a lot. I recently saw the most absurd example of this. Someone claimed they had implemented a C REPL. It turned out to be a Python program which took the C code you entered and passed it to GCC via the command line. It was completely and totally broken and didn't even preserve state. Now, it turned out that a group at CERN has actually been working on a real C++ REPL called Cling, for analysing data from the LHC (something like 25 petabytes of serialised C++ objects a year after filtering). I could imagine some miscreant wrapping the whole Cling project in Python and claiming they have implemented a C++ REPL. At least the Sage library has many new and interesting implementations of original algorithms which build on the functionality it wraps.] As for citation, unfortunately professional mathematicians rarely have time to learn anything about programming and so often you find less than adequate details when they cite computer software. I've been at a Pure Maths conference for a week and a half and I've seen computers mentioned twice. The first time no credit was given at all (though it was almost certainly Pari). The second time the entire credit was SAGE, although the speaker took care to acknowledge the help of John Cremona in helping them perform the computation. In that case I believe the computation was possibly done entirely in Pari via Sage. It looked to be computation of class numbers and unit groups of some number fields, although I am not 100% sure of this. The speaker was delighted that computers can do these things. Of course computers can't do anything. Better to cite the person who did the implementation. And did that speaker realise that the computation was subject to the GRH or worse? They may be excused for not going into great detail if the computation was as mundane as I thought it was. It seems to fall into the category of by a well known result The situation we really need to be worried about is where some special algorithm is used which makes a given computation possible where it was not otherwise. If my computation relied critically on multiply two large polynomials of degree ten billion, I might want to mention that I used flint via Sage, in case the reader haplessly tries to do this in Pari or some system that only supports polynomials of length up to 2^30. Of course properly citing Pari and the algorithm used and checking under what conditions the result is meaningful, etc, assumes that these things are well documented and accessible. So, a positive step the Pari developers could take is to make it easy to read the source code for a given function in Pari, much as Sage has done for Sage library code, and to document the algorithms used and where they are published and what their restrictions are. A lot of Pari code is especially difficult because it uses messy stack allocation all over the place. This is not thread safe and it is difficult to read and contribute to. If I wanted to make Pari really easy to contribute to and understand, I'd probably use garbage collection for all but the core arithmetic routines. I'd still make the core threadsafe though. I believe flint2 proves that this is possible in an efficient manner without messy stack allocation routines. The Pari developers might also like to consider people who wrote the Sage wrapper for Pari as contributing to Pari and credit them as such. It is in matters like these that Sage has taken a massive first step towards making Computational Number Theory a respectable sport. Whilst it doesn't address all the issues I raised in my earlier post, it has taken the field from being a mass of poorly documented, broken, non- portable, incompatible code lying around on people's hard drives or locked up in inscrutable closed implementations to being a unified distribution which meets some minimum standards. The code in the Sage library is open and easily accessible. Every function has a docstring and doctests (alright, that's a lie, but it's almost true). Library code is subjected to some kind of peer review. References to papers are provided. And moreover, Sage builds on multiple platforms and is tested regularly so it is more useful for some people. These are all very important first steps in bringing the field into good repute. None of these things seems to have hurt the popularity of Sage. Having said that,
[sage-devel] Re: Sage Pari
On Jul 26, 1:51 am, rjf fate...@gmail.com wrote: SNIP I hope that Bill was hoping to stir up some dissenting opinions. Yes, naturally. However, it looks to me that you have simply recorded the way things currently are. People will do whatever they feel like. That's true by definition. Regarding rigor, mathematics itself went through a phase where informal arguments were displaced with formal ones. Likewise, informal computer programs will eventually give way to formally verified ones, and this will naturally be embraced by mathematicians. You are right that this will not directly have an effect on Number Theory computations as they are currently done because people will continue to use computers as a tool to investigate conjectures and collect numerical evidence and so on. They care little about whether the program is correct. I'm also not talking about program proving in the sense that people usually mean it. I simply mean that compiler technology will give more confidence in implementations by virtue of the fact that they will check things currently left unchecked. This will obviously be picked up by serious mathematicians, namely the ones who are currently growing up with computers and who come to care about rigor, and will be made a formal part of doing mathematics with computers. I don't envision some centralised authority imposing conditions on published work. It will simply become part of mathematics de rigueur. Reearchers will not risk submitting papers that may be rejected on the grounds of inappropriate formal justification of their code for the standard of journal they are submitting to. When people begin justifying their programs in their papers, (which will of course also be electronic in the future), then the field will become more academically sound and eventually the problems it currently has will become a thing of the past. At the moment the field (if you can even call it that) has a serious image problem. People speak about working on computation in whispers as though it is sinful. This is possibly something you don't encounter as a computer scientist. 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] Re: Sage Pari
On Tue, Jul 26, 2011 at 9:00 AM, Bill Hart goodwillh...@googlemail.comwrote: Regarding rigor, mathematics itself went through a phase where informal arguments were displaced with formal ones. Likewise, informal computer programs will eventually give way to formally verified ones, and this will naturally be embraced by mathematicians. You are right that this will not directly have an effect on Number Theory computations as they are currently done because people will continue to use computers as a tool to investigate conjectures and collect numerical evidence and so on. They care little about whether the program is correct. When doing such investigations, we care greatly that the data we get is correct. We just don't care so much that the program producing it be *proven* correct in a formal and technically rigorous sense. When people begin justifying their programs in their papers, (which will of course also be electronic in the future), then the field will become more academically sound and eventually the problems it currently has will become a thing of the past. At the moment the field (if you can even call it that) has a serious image problem. People speak about working on computation in whispers as though it is sinful. There are other things happening in the world of mathematics that are helping with this image problem. For example, I was just at FoCM 2011 [1] and did not get this impression about computation, and there was a very wide range of mathematics represented (everything from numerical PDE's to Computational Topology to Number Theory). And there were certainly some well respected mathematicians among the participants (e.g., Steven Smale, Gunar Carlson, etc.). The people who build communities (major conference series / proceedings volumes) like the FoCM organizers are helping. [1] http://www.damtp.cam.ac.uk/user/na/FoCM11/workshops.html This is possibly something you don't encounter as a computer scientist. 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 -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Sage Pari
On Jul 26, 5:59 pm, William Stein wst...@gmail.com wrote: When doing such investigations, we care greatly that the data we get is correct. We just don't care so much that the program producing it be *proven* correct in a formal and technically rigorous sense. I understand that you qualified that with such investigations in reference to my example of investigating conjectures and gathering numerical evidence etc. And I agree with you in that context. However, I wish to emphasise the point I am making that the issues of correct data and rigorous programming methods are very much related. We are currently doing this ad hoc. It will in future be largely automated. And where it is not, it will be part of producing code to publication standard. I only wish to emphasise the point so that in a few decades time you will see how absolutely certain I was of that fact at this moment. That is to take nothing away from the important work of FoCM and similar ventures to improve attitudes. That is important too and I believe very relevant to Pari. 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] Re: Sage Pari
On Tue, 2011-07-26 at 08:30 -0700, Bill Hart wrote: Hi Simon, ...[snip]... Of course properly citing Pari and the algorithm used and checking under what conditions the result is meaningful, etc, assumes that these things are well documented and accessible. So, a positive step the Pari developers could take is to make it easy to read the source code for a given function in Pari, much as Sage has done for Sage library code, and to document the algorithms used and where they are published and what their restrictions are. A lot of Pari code is especially difficult because it uses messy stack allocation all over the place. This is not thread safe and it is difficult to read and contribute to. If I wanted to make Pari really easy to contribute to and understand, I'd probably use garbage collection for all but the core arithmetic routines. I'd still make the core threadsafe though. I believe flint2 proves that this is possible in an efficient manner without messy stack allocation routines. The Pari developers might also like to consider people who wrote the Sage wrapper for Pari as contributing to Pari and credit them as such. It is in matters like these that Sage has taken a massive first step towards making Computational Number Theory a respectable sport. Whilst it doesn't address all the issues I raised in my earlier post, it has taken the field from being a mass of poorly documented, broken, non- portable, incompatible code lying around on people's hard drives or locked up in inscrutable closed implementations to being a unified distribution which meets some minimum standards. The code in the Sage library is open and easily accessible. Every function has a docstring and doctests (alright, that's a lie, but it's almost true). Library code is subjected to some kind of peer review. References to papers are provided. And moreover, Sage builds on multiple platforms and is tested regularly so it is more useful for some people. These are all very important first steps in bringing the field into good repute. None of these things seems to have hurt the popularity of Sage. Having said that, I personally find it very difficult to trace through which algorithm is used in what regime in Sage. I once made some comments about which algorithms were used in Sage in a certain regime and someone lambasted me for getting it wrong. I subsequently carefully checked it through, following the rabbit warren of function calls across multiple interface boundaries through many files separated across vast reaches of the Sage directory tree and I am convinced I had the details substantially right. Of course if we just relied on Sage documentation to tell us what algorithm is being used in which package, we'd get it wrong much of the time, because that relies on the documentation having been maintained correctly. But at least Sage makes a step in the right direction. I've had similar issues trying to trace through the linbox package to figure out which algorithm is used. ...[snip]... To paraphrase your above comment, I believe that we need to raise the standards of computational mathematics further toward being a respectable sport. Consider your observation: Of course properly citing Pari and the algorithm used and checking under what conditions the result is meaningful, etc, assumes that these things are well documented and accessible. So, a positive step the Pari developers could take is to make it easy to read the source code for a given function in Pari, much as Sage has done for Sage library code, and to document the algorithms used and where they are published and what their restrictions are. In regular mathematics it is standard practice to fully document, that is, show the complete proof of your findings. In computational maths we do not do this. There is no particular reason why we don't except that it is not the expected behavior. We could raise the bar of expected behavior by having algorithms fully explained in the source code along with citations of theory sources. We could include a section on limitations, boundary conditions, examples, assumptions, and test cases. This is not as challenging as it sounds if it is done by the original author. It is extremely hard to recover or discover this information after the fact. Knuth proposed the idea of literate programs which combine the actual source code with the human language text as a single document. The document re-arranges the source code for ease of explanation and includes the usual paper sections on background, theory, along with a bibliography citing prior (literate) work. (See Queinnec, Christian ``Lisp in Small Pieces'' ISBN 0-521-56247-3 for a literate example) We could take small steps in this direction, possibly by hosting a literate program track at conferences or workshops to encourage the more literate among us to show examples and build up the technology. Raising the
[sage-devel] Re: Sage Pari
On 7/26/11 11:03 AM, William Stein wrote: (Sorry if anybody's favorite Sage component is missed in the attached diagram -- these were just the notes for my talk, and the diagram I actually drew was by hand with chalk and had ... below some spots to emphasize incompleteness.) Nice; I think it's funny how Jmol is pictured in the center, but not mentioned :). Matplotlib should also probably have been in the python list, as it's a well-used component of Sage. But all in all, this is a great diagram! 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] Vector space morphism equality
I've built a class for vector space morphisms, aka linear transformations. Mostly this just extends free module morphisms, while making a few distinctions between behavior for vector spaces versus modules over rings. Everything seems to be working fine, but I cannot get equality testing to work. Equality testing of free module morphisms ends up in a __cmp__() method for matrix morphisms. My vector space morphisms extend free module morphisms, which in turn extend matrix morphisms. If f and g are two free module morphisms, then f == g, f.__eq__(g), f.__cmp__(g) all employ the matrix morphism method __cmp__() and do the right thing. However, if f and g are two of my vector spaces morphisms, then f.__cmp__(g) does the right thing, but f == g and f.__eq__(g) give the wrong answer (False for equal morphisms) and never reach down to employ the __cmp__ method in the base matrix morphism class. Any hints, or places to look for guidance? No amount of searching the developers guide, reference manual, or forums has landed me in the right place. A 95%-complete patch is up at http://trac.sagemath.org/sage_trac/ticket/11556 which has all the details, but there is little point in wading through all that, unless you were interested in reviewing it once complete. ;-) Thanks, 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
Re: [sage-devel] Vector space morphism equality
On Tue, Jul 26, 2011 at 11:55 AM, Rob Beezer goo...@beezer.cotse.netwrote: I've built a class for vector space morphisms, aka linear transformations. Mostly this just extends free module morphisms, while making a few distinctions between behavior for vector spaces versus modules over rings. Everything seems to be working fine, but I cannot get equality testing to work. Equality testing of free module morphisms ends up in a __cmp__() method for matrix morphisms. My vector space morphisms extend free module morphisms, which in turn extend matrix morphisms. If f and g are two free module morphisms, then f == g, f.__eq__(g), f.__cmp__(g) all employ the matrix morphism method __cmp__() and do the right thing. However, if f and g are two of my vector spaces morphisms, then f.__cmp__(g) does the right thing, but f == g and f.__eq__(g) give the wrong answer (False for equal morphisms) and never reach down to employ the __cmp__ method in the base matrix morphism class. Any hints, or places to look for guidance? No amount of searching the developers guide, reference manual, or forums has landed me in the right place. A 95%-complete patch is up at http://trac.sagemath.org/sage_trac/ticket/11556 which has all the details, but there is little point in wading through all that, unless you were interested in reviewing it once complete. ;-) Did you overload *both* __cmp__ *and* __hash__? William Thanks, 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 -- 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] Adding new unit tests
On Mon, 25 Jul 2011 12:20:35 -0400 Michael Orlitzky mich...@orlitzky.com wrote: On 07/20/11 13:26, Burcin Erocal wrote: If you are adding tests only for integration, starting a new file sage/symbolic/tests.py might be better. ... Don't forget to mention the ticket number in the test. How's this looking? It is a good start. Here are some suggestions: - The code blocks should be preceeded with :: and indented. More information is available here: http://sagemath.org/doc/developer/conventions.html#documentation-strings - Since the file only contains integration tests, sage/symbolic/integration/tests.py is a better place for it IMHO. - I am not sure if a separate comment block is necessary for each test. I guess this makes sure that the test environment is always clean. It might add up to the time since it starts Sage so many times though. You can create a new ticket on trac and upload the patch there so it doesn't get lost. Thanks. Burcin -- 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: Vector space morphism equality
On Jul 26, 12:03 pm, William Stein wst...@gmail.com wrote: Did you overload *both* __cmp__ *and* __hash__? The matrix morphism class implements just __cmp__, with no __hash__. Existing free module morphism class implements neither, my new vector space morphism class implements neither. Free module morphisms behave properly with respect to equality (eg ==), making calls to the matrix morphism __cmp__ in the process. Vector space morphisms can see and use the matrix morphism __cmp__, but the == syntax won't behave properly. 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
Re: [sage-devel] Adding new unit tests
On 07/26/11 15:31, Burcin Erocal wrote: How's this looking? It is a good start. Here are some suggestions: - The code blocks should be preceeded with :: and indented. More information is available here: http://sagemath.org/doc/developer/conventions.html#documentation-strings - Since the file only contains integration tests, sage/symbolic/integration/tests.py is a better place for it IMHO. - I am not sure if a separate comment block is necessary for each test. I guess this makes sure that the test environment is always clean. It might add up to the time since it starts Sage so many times though. You can create a new ticket on trac and upload the patch there so it doesn't get lost. Thanks for the tips. I'll make the suggested changes, and re-export the patch with an associated ticket. -- 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: Vector space morphism equality
On 7/26/11 12:03 PM, William Stein wrote: On Tue, Jul 26, 2011 at 11:55 AM, Rob Beezer goo...@beezer.cotse.net mailto:goo...@beezer.cotse.net wrote: I've built a class for vector space morphisms, aka linear transformations. Mostly this just extends free module morphisms, while making a few distinctions between behavior for vector spaces versus modules over rings. Everything seems to be working fine, but I cannot get equality testing to work. Equality testing of free module morphisms ends up in a __cmp__() method for matrix morphisms. My vector space morphisms extend free module morphisms, which in turn extend matrix morphisms. If f and g are two free module morphisms, then f == g, f.__eq__(g), f.__cmp__(g) all employ the matrix morphism method __cmp__() and do the right thing. However, if f and g are two of my vector spaces morphisms, then f.__cmp__(g) does the right thing, but f == g and f.__eq__(g) give the wrong answer (False for equal morphisms) and never reach down to employ the __cmp__ method in the base matrix morphism class. Any hints, or places to look for guidance? No amount of searching the developers guide, reference manual, or forums has landed me in the right place. A 95%-complete patch is up at http://trac.sagemath.org/sage_trac/ticket/11556 which has all the details, but there is little point in wading through all that, unless you were interested in reviewing it once complete. ;-) Did you overload *both* __cmp__ *and* __hash__? To fill in some references, please see: http://docs.python.org/reference/datamodel.html?highlight=__hash__#object.__hash__ and http://docs.python.org/c-api/typeobj.html?highlight=__hash__#tp_compare in particular: This field is inherited by subtypes together with tp_richcompare and tp_hash: a subtypes inherits all three of tp_compare, tp_richcompare, and tp_hash when the subtype’s tp_compare, tp_richcompare, and tp_hash are all NULL. I thought there was a note in the Cython documentation about the relationship between inheriting __cmp__ and __hash__, but I can't seem to find anything in either the docs or the FAQ. 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: Vector space morphism equality
OK, maybe I figured this out. The parent of my vector space morphisms, a vector space homset, was not coercing a vector space morphism properly, so when trying to compare two vector space morphisms they had unequal parents. For the record, this was made obvious by calling canonical_coercion(f, g) on the two morphisms I wanted to compare, which raised an informative error. Thanks for the replies, William and Jason - the key bit was buried down in the vicinity of some comparison functions in sage.structure.element, which I might not have found without the hints. 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
[sage-devel] Re: Sage Pari
On Jul 26, 7:02 pm, daly d...@axiom-developer.org wrote: On Tue, 2011-07-26 at 08:30 -0700, Bill Hart wrote: SNIP my long blurb To paraphrase your above comment, I believe that we need to raise the standards of computational mathematics further toward being a respectable sport. Consider your observation: Of course properly citing Pari and the algorithm used and checking under what conditions the result is meaningful, etc, assumes that these things are well documented and accessible. So, a positive step the Pari developers could take is to make it easy to read the source code for a given function in Pari, much as Sage has done for Sage library code, and to document the algorithms used and where they are published and what their restrictions are. In regular mathematics it is standard practice to fully document, that is, show the complete proof of your findings. In computational maths we do not do this. There is no particular reason why we don't except that it is not the expected behavior. Unfortunately this is rarely true these days. In regular mathematics it is now very common for there to be large leaps between steps. Usually the more advanced the mathematician the less detail that is expected. Graduate students spend a lot of time filling it in. But your point regarding computational mathematics is spot on. It is very common to find code completely undocumented in any way. There is a substantial disparity in attitudes here. When I began my massive rewrite of flint from scratch I decided that each function would have a complete description and justification of the algorithm (if not well-known) in an associated text file, with references and proofs if necessary. Sebastian Pancratz came along and saw these text files and decided to write a parser that automatically turned them into pdf documentation! We could raise the bar of expected behavior by having algorithms fully explained in the source code along with citations of theory sources. We could include a section on limitations, boundary conditions, examples, assumptions, and test cases. This is not as challenging as it sounds if it is done by the original author. It is extremely hard to recover or discover this information after the fact. To a good extent this is done in most of the Sage library. I agree this should be the expected standard. Again I have to credit Sebastian Pancratz and Fredrik Johansson here for raising the standard in flint. I thought I had been producing beautiful code until Sebastian started rewriting some of it for me. :-) Knuth proposed the idea of literate programs which combine the actual source code with the human language text as a single document. The document re-arranges the source code for ease of explanation and includes the usual paper sections on background, theory, along with a bibliography citing prior (literate) work. (See Queinnec, Christian ``Lisp in Small Pieces'' ISBN 0-521-56247-3 for a literate example) My favourite example of this is Jonesforth. I highly recommend anyone who has not read this program to do so immediately. It is one of the most beautiful documents you can obtain for free. And you get yourself a Forth implementation at no extra cost. I don't personally do literate programming in the sense you intend it, with rearranged code so that it reads more naturally. But for very complex and touchy pieces of critical code I sometimes add formal justifications for every line of code. A good example of this is the bitpacking code in flint. We could take small steps in this direction, possibly by hosting a literate program track at conferences or workshops to encourage the more literate among us to show examples and build up the technology. I could certainly imagine a talk being constructed around an actual program. I might try this one day and see how it goes. Raising the standards for published mathematical software will help us all in the long run. We can look forward to a time when we can read, understand, and cite particular Pari and Sage algorithms which are their actual implementations in literate form. It's not the only important step that needs to be taken though. My epiphany regarding automated program checking came when I serendipitously encountered a fantastic book on Prolog on the exact same day that I sat down to implement Damas-Hindley-Milner type inference for an interpreter I have been writing. I marvel that a 20 line implementation of the unification algorithm saves me so much hassle. After this little epiphany I have not had any problems seeing the future. Type inference and unification have been around for ages, but I feel like someone who has been in a time machine and returned and who has to sit around and watch the inevitable development of the compiler technology that I have already seen. Progress feels like a slow motion replay. Bill. -- To post to this group, send an email to
Re: [sage-devel] Re: Sage Pari
...[snip]... In regular mathematics it is standard practice to fully document, that is, show the complete proof of your findings. In computational maths we do not do this. There is no particular reason why we don't except that it is not the expected behavior. Unfortunately this is rarely true these days. In regular mathematics it is now very common for there to be large leaps between steps. Usually the more advanced the mathematician the less detail that is expected. Graduate students spend a lot of time filling it in. But your point regarding computational mathematics is spot on. It is very common to find code completely undocumented in any way. There is a substantial disparity in attitudes here. What concerns me is the long run. We are at the very beginning of a new science of computational mathematics. The early systems are the newton's notebooks of this science. Most of them are locked up in companies (MMA, Maple, Derive, Macsyma, etc.). But companies die and take their software with them, for example, Macsyma. (For company deaths see the last few minutes of: http://www.ted.com/talks/geoffrey_west_the_surprising_math_of_cities_and_corporations.html If we are to have a firm foundation for computational mathematics it is necessary that we begin to build the citation trail of algorithms available in a public, published way. Why are we wasting time and effort reinventing algorithms? Why can't I find executable algorithms along with their theory? Why can't I attend a talk, download the literate paper, and execute the algorithm while the talk is ongoing? When I began my massive rewrite of flint from scratch I decided that each function would have a complete description and justification of the algorithm (if not well-known) in an associated text file, with references and proofs if necessary. Sebastian Pancratz came along and saw these text files and decided to write a parser that automatically turned them into pdf documentation! Excellent! Although I'd much rather follow Knuth and have a literate document I find it outstanding that you have created these. Can you point to a URL as an example? We could raise the bar of expected behavior by having algorithms fully explained in the source code along with citations of theory sources. We could include a section on limitations, boundary conditions, examples, assumptions, and test cases. This is not as challenging as it sounds if it is done by the original author. It is extremely hard to recover or discover this information after the fact. To a good extent this is done in most of the Sage library. I agree this should be the expected standard. I am unaware of this, which is clearly my fault. Can you point to an example you consider literate? Again I have to credit Sebastian Pancratz and Fredrik Johansson here for raising the standard in flint. I thought I had been producing beautiful code until Sebastian started rewriting some of it for me. :-) Knuth proposed the idea of literate programs which combine the actual source code with the human language text as a single document. The document re-arranges the source code for ease of explanation and includes the usual paper sections on background, theory, along with a bibliography citing prior (literate) work. (See Queinnec, Christian ``Lisp in Small Pieces'' ISBN 0-521-56247-3 for a literate example) My favourite example of this is Jonesforth. I highly recommend anyone who has not read this program to do so immediately. It is one of the most beautiful documents you can obtain for free. And you get yourself a Forth implementation at no extra cost. All page references to Jonesforth seem to time out. I am writing a similar document for the Clojure language. The literate document contains a full implementation of Clojure. Unpacking the document creates a Clojure REPL and a PDF of the documentation (well, as far as it has gotten at this point). source: http://daly.literatesoftware.com/clojure.pamphlet pdf : http://daly.literatesoftware.com/clojure.pdf I don't personally do literate programming in the sense you intend it, with rearranged code so that it reads more naturally. But for very complex and touchy pieces of critical code I sometimes add formal justifications for every line of code. A good example of this is the bitpacking code in flint. We could take small steps in this direction, possibly by hosting a literate program track at conferences or workshops to encourage the more literate among us to show examples and build up the technology. I could certainly imagine a talk being constructed around an actual program. I might try this one day and see how it goes. I would like to see Sage have some small step in this direction but I have no idea where to start. I know next to nothing about number theory so I couldn't begin to reverse engineer the algorithms. I am also not well versed in the Sage build process so I
[sage-devel] porting sage to OS X 10.7
Hi Sage Developers, To help with porting Sage to OS X 10.7, I bought 10.7, installed it, and setup a public-facing machine (actually, the old bsd.math.washington.edu) with OS X 10.7 and *XCode 4.1* installed on it.If you had an account on the old bsd.math.washington.edu computer, then you automatically still have an account on this computer. It's sqrt5.cs.washington.edu So try to build Sage! Report and fix issues. And if you're somebody upstream who wants to port something in Sage to OS X 10.7 (e.g., numpy?), you might want to use this computer for that purpose. We really need Sage to fully 100% work with XCode 4.x and 10.7. -- William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
