Re: [sage-devel] matrix output strangeness
On Sun, Nov 14, 2010 at 6:26 AM, John Cremona wrote: > Something is not quite right in the cleverness used to output matrices: > > sage: M > 76 x 58 dense matrix over Integer Ring (type 'print M.str()' to see > all of the entries) > sage: M.hermite_form() > 76 x 58 dense matrix over Integer Ring (type 'print > hnf-True-False.str()' to see all of the entries) > > John This is caused by trac 5174: http://trac.sagemath.org/sage_trac/ticket/5174 Maybe one of the contributors to that ticket has an idea. The relevant code is the __repr__ method in matrix/matrix0.pyx. William -- 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: "Why Sage?" Website Section
On Nov 14, 11:45 am, "Dr. David Kirkby" wrote: > > I asked RJF what languge he thought the interface should be. As 10 options I > consider might be viable choises where > Whether there should be a single language for implementation and user interface for a computer algebra system has occupied designers and students of such systems for about 50 years, and there are many papers on this topic. And there are many papers (phd theses, too) describing new and wonderful user interfaces. My advice is to look at the literature. As they say (more or less) a month of programming can save an hour in the library. RJF -- 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: "Why Sage?" Website Section
On 11/14/2010 10:37 PM, William Stein wrote:
On Sun, Nov 14, 2010 at 6:48 PM, Eviatar wrote:
I thought Python was strongly typed. Definition from Wikipedia:
"Most generally, "strong typing" implies that the programming language
places severe restrictions on the intermixing that is permitted to
occur, preventing the compiling or running of source code which uses
data in what is considered to be an invalid way. For instance, an
integer division operation may not be used upon strings; a procedure
which operates upon linked lists may not be used upon numbers.
However, the nature and strength of these restrictions is highly
variable."
What do you mean by saying it isn't?
FYI, I've learned from experience that even using the phrases
"strongly typed" and "weakly typed" is a bad idea.
The problem is that there aren't any good accepted definitions of
them, and it is easy to find reputable sources that flatly disagree
with the definition at Wikipedia, unfortunately.
The original poster probably meant that Python is not "statically
typed". (Another can of worms, but less of a problem.)
- William
I agree with William that the "strongly typed" question is a
(well, I can't bring myself to use the "can of worms" analogy
given my prior analogy chastizing :-) )
To illustrate an example, it is possible to define:
integer foo(integer x, integer y) {}
matrix foo(integer x, integer y) {}
and then write:
integer a := foo(3,4)
matrix b := foo(3,4)
The question of which foo to call requires function dispatching
on the return type of the function. Few existing languages do this.
One place where this is useful is the construction of canonical forms.
The question of which result is simplest depends on the result you
expect. Consider that
1 11
- x + --
7 13
is a polynomial with fractional coefficients and cannot be reduced. But
13x + 77
91
is a fraction of two polynomials with integer coefficients. They also
happen to represent the same value. Simplification of the value depends
on whether the desired result is a
Polynomial(Fraction(Integer))
or a
Fraction(Polynomial(Integer))
By specifying the target type you can define the simple form.
Tim Daly
--
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: "Why Sage?" Website Section
On Sun, Nov 14, 2010 at 6:48 PM, Eviatar wrote: > I thought Python was strongly typed. Definition from Wikipedia: > > "Most generally, "strong typing" implies that the programming language > places severe restrictions on the intermixing that is permitted to > occur, preventing the compiling or running of source code which uses > data in what is considered to be an invalid way. For instance, an > integer division operation may not be used upon strings; a procedure > which operates upon linked lists may not be used upon numbers. > However, the nature and strength of these restrictions is highly > variable." > > What do you mean by saying it isn't? FYI, I've learned from experience that even using the phrases "strongly typed" and "weakly typed" is a bad idea. The problem is that there aren't any good accepted definitions of them, and it is easy to find reputable sources that flatly disagree with the definition at Wikipedia, unfortunately. The original poster probably meant that Python is not "statically typed". (Another can of worms, but less of a problem.) - William > > On Nov 14, 3:17 pm, Tim Daly wrote: >> I am not the best person to ask as I have a vested interest. >> >> I find that mathematical notation is strongly context >> sensitive which gets translated into types when done >> as computational mathematics. Thus, I believe that a >> mathematical language needs to be strongly typed. >> Python is not strongly typed. >> >> Axiom has two levels of type-strength. The interpreter >> does its best to guess types so the user can give short >> and reasonable inputs. The compiler requires extremely >> strong typing to ensure that the algorithms match the >> intentions. The fact that the compiler does not make >> guesses makes it more challenging to develop library code >> but increases the chance that the algorithm is correct. >> Python does not compile. >> >> In addition, I believe that a computational mathematics >> language has to have a strong connection to the underlying >> mathematics. In Axiom's case, abstract algebra provides the >> mathematical framework for providing categories around which >> the algorithms are structured. Sage does not seem to have a >> strong scaffold for adding new packages. It appears to be >> growing by accretion. >> >> There are two extensions I would like to have which is >> the use of unicode and the use of two dimensional input. >> Sage/Python has a chance for a big win here. >> >> I think that unicode input which allows greek and other >> symbols would make the input closer to the original mathematics >> notation. Unfortunately, my thesis work showed me that >> mathematical notation is highly ambiguous. In fact, I have >> come to the conclusion that the equations in a book are >> pretty much content free. The real mathematics is actually >> contained in the surrounding text. To see this effect take >> your favorite textbook, remove everything but the equations >> and you'll find that you have lost the meaning of the symbols. >> Without context, E=MC^2 is a meaningless jumble of symbols. >> >> I think that two dimensional input is also a huge win. >> However, I worked on two dimensional input at IBM Research. >> I know of several attempts to do the same thing. The most >> recent attempt that I saw was at the University of Waterloo. >> I do not know what became of this effort but I know that >> two dimensional input is hard and very ambiguous. >> >> In any case, computational mathematics is more about the >> algorithms than about the notation. A strong mathematical >> framework and strong typing are more important than I/O. >> >> By the way, the Axiom Spad language is very much like Python. >> It uses indentation to group code. It has list comprehensions. >> It has many more data structures than Python. It dispatches >> not only on the types of the arguments but also on the type >> of the result (something few languages allow even today). >> >> Spad can be either interpreted or compiled. It can communicate >> with lisp (the implementation language), C (the whole graphics >> subsystem is written in C), javascript (the browser frontend >> is AJAX/Javascript/HTML), Fortran (the commercial version >> called the NAG fortran library routines), etc. The claim that >> Python is an exceptional language for computation mathematics >> or is exceptional as a "glue" language completely ignores >> history which tends to make us old people cranky. >> >> I think the Sage language designers could steal a few useful >> ideas from the Spad language. >> >> I also find the Python/Lisp debate useless. In Axiom, Lisp is >> the implementation language but you can use Axiom for years and >> not know that because Spad is the computational algorithm language. >> >> In Sage there is confusion about the implementation language of >> Python and the computational mathematics language built in Python >> which appears not to have a name. >> >> Tim Daly >> >> On 11/14/2010 2:45 PM, Dr. David Kirkby
[sage-devel] Re: "Why Sage?" Website Section
I thought Python was strongly typed. Definition from Wikipedia: "Most generally, "strong typing" implies that the programming language places severe restrictions on the intermixing that is permitted to occur, preventing the compiling or running of source code which uses data in what is considered to be an invalid way. For instance, an integer division operation may not be used upon strings; a procedure which operates upon linked lists may not be used upon numbers. However, the nature and strength of these restrictions is highly variable." What do you mean by saying it isn't? On Nov 14, 3:17 pm, Tim Daly wrote: > I am not the best person to ask as I have a vested interest. > > I find that mathematical notation is strongly context > sensitive which gets translated into types when done > as computational mathematics. Thus, I believe that a > mathematical language needs to be strongly typed. > Python is not strongly typed. > > Axiom has two levels of type-strength. The interpreter > does its best to guess types so the user can give short > and reasonable inputs. The compiler requires extremely > strong typing to ensure that the algorithms match the > intentions. The fact that the compiler does not make > guesses makes it more challenging to develop library code > but increases the chance that the algorithm is correct. > Python does not compile. > > In addition, I believe that a computational mathematics > language has to have a strong connection to the underlying > mathematics. In Axiom's case, abstract algebra provides the > mathematical framework for providing categories around which > the algorithms are structured. Sage does not seem to have a > strong scaffold for adding new packages. It appears to be > growing by accretion. > > There are two extensions I would like to have which is > the use of unicode and the use of two dimensional input. > Sage/Python has a chance for a big win here. > > I think that unicode input which allows greek and other > symbols would make the input closer to the original mathematics > notation. Unfortunately, my thesis work showed me that > mathematical notation is highly ambiguous. In fact, I have > come to the conclusion that the equations in a book are > pretty much content free. The real mathematics is actually > contained in the surrounding text. To see this effect take > your favorite textbook, remove everything but the equations > and you'll find that you have lost the meaning of the symbols. > Without context, E=MC^2 is a meaningless jumble of symbols. > > I think that two dimensional input is also a huge win. > However, I worked on two dimensional input at IBM Research. > I know of several attempts to do the same thing. The most > recent attempt that I saw was at the University of Waterloo. > I do not know what became of this effort but I know that > two dimensional input is hard and very ambiguous. > > In any case, computational mathematics is more about the > algorithms than about the notation. A strong mathematical > framework and strong typing are more important than I/O. > > By the way, the Axiom Spad language is very much like Python. > It uses indentation to group code. It has list comprehensions. > It has many more data structures than Python. It dispatches > not only on the types of the arguments but also on the type > of the result (something few languages allow even today). > > Spad can be either interpreted or compiled. It can communicate > with lisp (the implementation language), C (the whole graphics > subsystem is written in C), javascript (the browser frontend > is AJAX/Javascript/HTML), Fortran (the commercial version > called the NAG fortran library routines), etc. The claim that > Python is an exceptional language for computation mathematics > or is exceptional as a "glue" language completely ignores > history which tends to make us old people cranky. > > I think the Sage language designers could steal a few useful > ideas from the Spad language. > > I also find the Python/Lisp debate useless. In Axiom, Lisp is > the implementation language but you can use Axiom for years and > not know that because Spad is the computational algorithm language. > > In Sage there is confusion about the implementation language of > Python and the computational mathematics language built in Python > which appears not to have a name. > > Tim Daly > > On 11/14/2010 2:45 PM, Dr. David Kirkby wrote: > > > > > > > > > On 11/14/10 07:00 PM, Tim Daly wrote: > >> I find it amusing that mathematicians are being told that > >> a math-specific language is a liability. Mathematics is, > >> after all, a specialized language that took me years to > >> learn. > > > I asked RJF what languge he thought the interface should be. As 10 > > options I consider might be viable choises where > > > 1) Create an entirely new language. > > 2) Python > > 3) Maxima > > 4) A Mathematica like interface > > 5) A MATLAB like interface > > 6) A Maple-like interface > > 7) A Magma-like interf
Re: [sage-devel] Adding patch as a standard package
On Sun, Nov 14, 2010 at 3:39 PM, Dan Drake wrote: > On Sun, 14 Nov 2010 at 02:00PM +0100, Jeroen Demeyer wrote: >> There is some work being done at #9418 at make GNU patch a standard >> package such that, in the future, spkgs will be able to use "patch" >> instead of "cp" to apply patches. >> >> It is a very simple solution which allows for: >> * patching files depending on the system (e.g. if a patch needs to be >> applied only on OS X systems) >> * patching multiple files with one diff >> * patching the same file with multiple diffs >> * easily updating a spkg to a new upstream version >> * easily adding a new patch to a spkg >> * not being forced to update any spkgs, we can keep the old system if we >> want (if there is a reason to do that for a particular spkg). >> * low maintanance of the "patch" spkg: patch is a very stable program >> with essentially no dependencies. > > I dislike having complete files and patches in the patch/ directory, so > I'm in favor of somehow having patch available. > > One concern I have: let's say we have a patch spkg in Sage. Many people > installing Sage will have patch already available, and it is easy to > imagine, if we're not careful in our scripts, that sometimes the system > patch would be called, and sometimes Sage's patch -- and since these > might not be the same version, strange, difficult-to-debug behavior > could result. This is actually a really good argument for including our own version of patch. A related note -- mercurial has their own implementation of patch included in Mercurial. Recently, there was a trac ticket [1] where one sage developer could apply the patches without trouble and another got conflicts. It turned out that one peson was using Mercurial 1.6 and the other person was using Mercurial 1.3, and their patch command had changed from one version to the next! (Basically, in 1.3 it would accept the patch without reporting potential conflicts in this case, but in 1.6 it was more skeptical and didn't accept the patch.) William [1] http://trac.sagemath.org/sage_trac/ticket/8792 > > My questions: > > * Is patch stable and standard enough so that this won't be a problem? > For example, can we stick to POSIX-standard commandline switches and so > on, and expect everything to work on Linux, *BSD, OS X, Solaris, etc, > even if an errant script calls the system patch? > > * If the answer to the above question isn't a solid yes, how hard would > it be to rewrite spkg-install scripts to be very certain that we only > use "our" patch? (And to educate future spkg creators to do this as well?) > > I'm guessing the answers are "yes" and "not very", but I thought I would > raise the issue. > > Dan > > -- > --- Dan Drake > - http://mathsci.kaist.ac.kr/~drake > --- > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEARECAAYFAkzgc0MACgkQr4V8SljC5Lo2dgCfcv2AclBSFfuZOoMdCaTc8p41 > +wEAoNazV2t/jGdtce5iqcx+fGIqK8Dp > =Y4VJ > -END PGP SIGNATURE- > > -- 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 patch as a standard package
On 11/14/10 11:39 PM, Dan Drake wrote: On Sun, 14 Nov 2010 at 02:00PM +0100, Jeroen Demeyer wrote: There is some work being done at #9418 at make GNU patch a standard package such that, in the future, spkgs will be able to use "patch" instead of "cp" to apply patches. It is a very simple solution which allows for: * patching files depending on the system (e.g. if a patch needs to be applied only on OS X systems) * patching multiple files with one diff * patching the same file with multiple diffs * easily updating a spkg to a new upstream version * easily adding a new patch to a spkg * not being forced to update any spkgs, we can keep the old system if we want (if there is a reason to do that for a particular spkg). * low maintanance of the "patch" spkg: patch is a very stable program with essentially no dependencies. I dislike having complete files and patches in the patch/ directory, so I'm in favor of somehow having patch available. One concern I have: let's say we have a patch spkg in Sage. Many people installing Sage will have patch already available, and it is easy to imagine, if we're not careful in our scripts, that sometimes the system patch would be called, and sometimes Sage's patch -- and since these might not be the same version, strange, difficult-to-debug behavior could result. My questions: * Is patch stable and standard enough so that this won't be a problem? For example, can we stick to POSIX-standard commandline switches and so on, and expect everything to work on Linux, *BSD, OS X, Solaris, etc, even if an errant script calls the system patch? Historically the Sun patch command has not been compatible with the GNU one. Here's the man page for the Sun patch command User Commandspatch(1) NAME patch - apply changes to files SYNOPSIS patch [-blNR] [-c | -e | -n | -u] [-d dir] [-D define] [- i patchfile] [-o outfile] [-p num] [-r rejectfile] [file] DESCRIPTION The patch command reads a source (patch) file containing any and there's the POSIX defintion http://www.opengroup.org/onlinepubs/009695399/utilities/patch.html ie.. they are identical. But the GNU patch command has not been 100% compatible with the Sun one. Perhaps if the GNU option --posix to diff was used, then it might be ok. * If the answer to the above question isn't a solid yes, how hard would it be to rewrite spkg-install scripts to be very certain that we only use "our" patch? (And to educate future spkg creators to do this as well?) I'm guessing the answers are "yes" and "not very", but I thought I would raise the issue. Dan Since $SAGE_LOCAL/bin is in the path before anything else, we should should find the version in Sage before any oether version - irrespective of whether that other version is newer, older, better or broken. 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] Adding patch as a standard package
On Sun, 14 Nov 2010 at 02:00PM +0100, Jeroen Demeyer wrote: > There is some work being done at #9418 at make GNU patch a standard > package such that, in the future, spkgs will be able to use "patch" > instead of "cp" to apply patches. > > It is a very simple solution which allows for: > * patching files depending on the system (e.g. if a patch needs to be > applied only on OS X systems) > * patching multiple files with one diff > * patching the same file with multiple diffs > * easily updating a spkg to a new upstream version > * easily adding a new patch to a spkg > * not being forced to update any spkgs, we can keep the old system if we > want (if there is a reason to do that for a particular spkg). > * low maintanance of the "patch" spkg: patch is a very stable program > with essentially no dependencies. I dislike having complete files and patches in the patch/ directory, so I'm in favor of somehow having patch available. One concern I have: let's say we have a patch spkg in Sage. Many people installing Sage will have patch already available, and it is easy to imagine, if we're not careful in our scripts, that sometimes the system patch would be called, and sometimes Sage's patch -- and since these might not be the same version, strange, difficult-to-debug behavior could result. My questions: * Is patch stable and standard enough so that this won't be a problem? For example, can we stick to POSIX-standard commandline switches and so on, and expect everything to work on Linux, *BSD, OS X, Solaris, etc, even if an errant script calls the system patch? * If the answer to the above question isn't a solid yes, how hard would it be to rewrite spkg-install scripts to be very certain that we only use "our" patch? (And to educate future spkg creators to do this as well?) I'm guessing the answers are "yes" and "not very", but I thought I would raise the issue. Dan -- --- Dan Drake - http://mathsci.kaist.ac.kr/~drake --- signature.asc Description: Digital signature
Re: [sage-devel] Re: "Why Sage?" Website Section
On Sun, Nov 14, 2010 at 3:17 PM, Tim Daly wrote: > In addition, I believe that a computational mathematics > language has to have a strong connection to the underlying > mathematics. In Axiom's case, abstract algebra provides the > mathematical framework for providing categories around which > the algorithms are structured. Sage does not seem to have a > strong scaffold for adding new packages. It appears to be > growing by accretion. The Sage library does have a framework for providing categories around which algorithms are structured, thanks to work of David Kohel (back in 2005), Nicolas Thierny (last year), and many others over the years. There is also a coercion model that automates the construction of natural maps between different modules, rings, etc., which Robert Bradshaw, Craig Citro, David Roe, and others, designed and implemented.The categories framework and coercion model together provide said framework. Most of it didn't exist 3 years ago. > I think the Sage language designers could steal a few useful > ideas from the Spad language. I'm sure the design and implementation of Python is heavily influenced by other languages... > I also find the Python/Lisp debate useless. In Axiom, Lisp is > the implementation language but you can use Axiom for years and > not know that because Spad is the computational algorithm language. > > In Sage there is confusion about the implementation language of > Python and the computational mathematics language built in Python > which appears not to have a name. It is called "The Sage Library". It's a Python library that one gets by typing "import sage" at the Python prompt. > The claim that Python is an exceptional language for computation > mathematics or is exceptional as a "glue" language completely ignores > history which tends to make us old people cranky. The claim does not ignore history, since a big part of this claim is that there are a large number of Python users, and a big ecosystem of code that is usable easily from Python. That is the result of "history", i.e., things that happened in the past. Thank you history. If Python had few users and the set of libraries available for Python were tiny, then it would look very unattractive. -- William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: "Why Sage?" Website Section
I am not the best person to ask as I have a vested interest. I find that mathematical notation is strongly context sensitive which gets translated into types when done as computational mathematics. Thus, I believe that a mathematical language needs to be strongly typed. Python is not strongly typed. Axiom has two levels of type-strength. The interpreter does its best to guess types so the user can give short and reasonable inputs. The compiler requires extremely strong typing to ensure that the algorithms match the intentions. The fact that the compiler does not make guesses makes it more challenging to develop library code but increases the chance that the algorithm is correct. Python does not compile. In addition, I believe that a computational mathematics language has to have a strong connection to the underlying mathematics. In Axiom's case, abstract algebra provides the mathematical framework for providing categories around which the algorithms are structured. Sage does not seem to have a strong scaffold for adding new packages. It appears to be growing by accretion. There are two extensions I would like to have which is the use of unicode and the use of two dimensional input. Sage/Python has a chance for a big win here. I think that unicode input which allows greek and other symbols would make the input closer to the original mathematics notation. Unfortunately, my thesis work showed me that mathematical notation is highly ambiguous. In fact, I have come to the conclusion that the equations in a book are pretty much content free. The real mathematics is actually contained in the surrounding text. To see this effect take your favorite textbook, remove everything but the equations and you'll find that you have lost the meaning of the symbols. Without context, E=MC^2 is a meaningless jumble of symbols. I think that two dimensional input is also a huge win. However, I worked on two dimensional input at IBM Research. I know of several attempts to do the same thing. The most recent attempt that I saw was at the University of Waterloo. I do not know what became of this effort but I know that two dimensional input is hard and very ambiguous. In any case, computational mathematics is more about the algorithms than about the notation. A strong mathematical framework and strong typing are more important than I/O. By the way, the Axiom Spad language is very much like Python. It uses indentation to group code. It has list comprehensions. It has many more data structures than Python. It dispatches not only on the types of the arguments but also on the type of the result (something few languages allow even today). Spad can be either interpreted or compiled. It can communicate with lisp (the implementation language), C (the whole graphics subsystem is written in C), javascript (the browser frontend is AJAX/Javascript/HTML), Fortran (the commercial version called the NAG fortran library routines), etc. The claim that Python is an exceptional language for computation mathematics or is exceptional as a "glue" language completely ignores history which tends to make us old people cranky. I think the Sage language designers could steal a few useful ideas from the Spad language. I also find the Python/Lisp debate useless. In Axiom, Lisp is the implementation language but you can use Axiom for years and not know that because Spad is the computational algorithm language. In Sage there is confusion about the implementation language of Python and the computational mathematics language built in Python which appears not to have a name. Tim Daly On 11/14/2010 2:45 PM, Dr. David Kirkby wrote: On 11/14/10 07:00 PM, Tim Daly wrote: I find it amusing that mathematicians are being told that a math-specific language is a liability. Mathematics is, after all, a specialized language that took me years to learn. I asked RJF what languge he thought the interface should be. As 10 options I consider might be viable choises where 1) Create an entirely new language. 2) Python 3) Maxima 4) A Mathematica like interface 5) A MATLAB like interface 6) A Maple-like interface 7) A Magma-like interface 8) Lisp 9) Q - see http://en.wikipedia.org/wiki/Q_%28equational_programming_language%29 10) Pure http://code.google.com/p/pure-lang/ is another possibility, but that did not exist until 2008, but is based on Q, which existed prior to Sage He failed to response. (He would rather tell me on the Maxima list that I can create an infinite set of integers to do some testing.) But that is to be expected from Richard - a signal to noise ratio of about -30 dB. But what do you think is the ideal language for a user interface? There have been endless attempts at cleating new languages (#1 above). I've even done it myself, to the extent of writing a couple of hundred lines of code for lex and yacc. But it's a very difficult problem to get right, and quite honestly requires a set of sills I don't think a single Sage
Re: [sage-devel] Adding patch as a standard package
On 11/14/10 08:51 PM, William Stein wrote: On Sun, Nov 14, 2010 at 5:00 AM, Jeroen Demeyer wrote: Hello all, There is some work being done at #9418 at make GNU patch a standard package such that, in the future, spkgs will be able to use "patch" instead of "cp" to apply patches. It is a very simple solution which allows for: * patching files depending on the system (e.g. if a patch needs to be applied only on OS X systems) * patching multiple files with one diff * patching the same file with multiple diffs * easily updating a spkg to a new upstream version * easily adding a new patch to a spkg * not being forced to update any spkgs, we can keep the old system if we want (if there is a reason to do that for a particular spkg). * low maintanance of the "patch" spkg: patch is a very stable program with essentially no dependencies. I realize there have been other proposals to fix the patching, but in my opinion simply using "patch" is the best solution. Let me also point out that the spkg is already there (thanks to David Kirkby), so this is not a theoretical discussion: http://boxen.math.washington.edu/home/kirkby/patches/patch-2.6.1.spkg I have also created a proof-of-concept spkg using "patch": http://sage.math.washington.edu/home/jdemeyer/spkg/sphinx-1.0.4.p2.spkg (there is a corresponding .p1 which uses "cp") So I would mainly like to know if somebody is truly against this proposal (I would like to avoid posts of the form "but this other method is even better than patch!" because that will get us nowhere). I'm now not against the proposal of using patch in spkg's, assuming patch gets shipped with Sage. I just don't want to personally have to do the work, and don't want patch to be a prerequisite to build sage. Given that there is a patch spkg, that's not an issue. The work is done http://boxen.math.washington.edu/home/kirkby/patches/patch-2.6.1.spkg The package is up for review http://trac.sagemath.org/sage_trac/ticket/9418 I've agreed to maintain it for a couple of years, which to be honest is not a lot of work. There has been no updates at all in 2010, I somewhat doubt the upstream source will update very often. Even if it does, I doubt the benefits of updating patch will be as great as updating pari, gap, maxima or endless other packages. But it's an easy package to update. It has its own test suite. On my Xeon processor, I can build the package and run the test suite in under 4 seconds. Jeroen has created an example sphinx package on that ticket: http://sage.math.washington.edu/home/jdemeyer/spkg/sphinx-1.0.4.p2.spkg But we need to decide on a set of instructions for people to use. For example, if there are 3 files that need to be patched to work around a bug, does one create 3 patches, or one patch which patches all three files? One might chose to use a different approach if the files are very closely tied together - like 'configure.ac' and 'configure'. Those issues need resolving. I think once we have a package which has shown to build on all systems, we need to think carefully about how to be document creating and applying the patches. I've got a ticket up for that, but that needs some discussion and can wait until after we prove the package builds reliably on all systems. > > I am still against storing patch files in the patches/ subdirectory in > addition to the patched files. It's redundant and pointless. However, > with patch included in Sage, then we can store *only* patches in the > patches subdirectory, which makes lots of sense. > > - -William Like you, I can't see any point in storing both patch files and patched versions of files. But the process from using 'cp' to patch will have to be a gradual one. Create patch files when packages need to be upated. 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] ask.sagemath.org
On Sun, Nov 14, 2010 at 1:14 PM, wrote: > Hello! > Please excuse me if I'm asking a question that has already been > answered somewhere. :) > Does this service exist for asking the questions on certain > specific problems and algorithms or for some kind of generic questions? > For example, if I have some problem to solve, but I do not know how > to do that with Sage, may I ask how to do that? You can certainly give it a try. I think any question is fair game to post there. I think very specific questions, whose answer might be a snippet of sage code, are probably the best. > > Thanks. > Vladimir. > > On Sun, 14 Nov 2010 13:02:03 -0800 > William Stein wrote: > >> Hi, >> >> I just wanted to send a quick update about http://ask.sagemath.org. >> There are now nearly 200 participants, and also nearly 200 questions >> have been asked, with most answered. The person with the top karma >> for answering questions is Mike Hansen. So a big shout out to Mike. >> Also, Niles Johnson has been extremely helpful as well. >> >> Thanks to the help of Evgeny Fadeev (askbot author), it is also now >> possible to typeset mathematics pretty much anywhere on >> http://ask.sagemath.org. >> >> -- William >> >> -- >> William Stein >> Professor of Mathematics >> University of Washington >> http://wstein.org >> >> -- >> To post to this group, send an email to sage-devel@googlegroups.com >> To unsubscribe from this group, send an email to >> sage-devel+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/sage-devel >> URL: http://www.sagemath.org >> > > > - > > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- 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] ask.sagemath.org
Hello! Please excuse me if I'm asking a question that has already been answered somewhere. :) Does this service exist for asking the questions on certain specific problems and algorithms or for some kind of generic questions? For example, if I have some problem to solve, but I do not know how to do that with Sage, may I ask how to do that? Thanks. Vladimir. On Sun, 14 Nov 2010 13:02:03 -0800 William Stein wrote: > Hi, > > I just wanted to send a quick update about http://ask.sagemath.org. > There are now nearly 200 participants, and also nearly 200 questions > have been asked, with most answered. The person with the top karma > for answering questions is Mike Hansen. So a big shout out to Mike. > Also, Niles Johnson has been extremely helpful as well. > > Thanks to the help of Evgeny Fadeev (askbot author), it is also now > possible to typeset mathematics pretty much anywhere on > http://ask.sagemath.org. > > -- William > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > - -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] ask.sagemath.org
Hi, I just wanted to send a quick update about http://ask.sagemath.org. There are now nearly 200 participants, and also nearly 200 questions have been asked, with most answered. The person with the top karma for answering questions is Mike Hansen. So a big shout out to Mike. Also, Niles Johnson has been extremely helpful as well. Thanks to the help of Evgeny Fadeev (askbot author), it is also now possible to typeset mathematics pretty much anywhere on http://ask.sagemath.org. -- 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
[sage-devel] Re: experiment with a new version of the SageTeX package
Hi, First of all let me say that I am currently writing a math text book where I am using a lot of sagetex and I think it is a great package! Having said that as a "user" I am a bit concerned that the syntax of sagetex is going to change if I want to publish the latex sources or describe examples in a book as this would lead to frustration with outdated code examples (books do not tend to be as often updated as software unfortunately :-). I would think that other people writing books may have similar issues. Could I therefore suggest to either change the syntax really soon or not at all, I personally do not care how I am accessing sagetex functionality and it is at best irrelevant syntactic sugar to the user. regards Jens On Sep 27, 4:44 am, Dan Drake wrote: > On Sun, 26 Sep 2010 at 05:15AM -0700, Volker Braun wrote: > > As for the environment names, right now there is: > [...] > > I think ideally they would all be combined into a single "sage" > > environment, with options that determine whether to typeset the sage > > command, the sage output, and whether to doctest. By default, it would > > then behave like sagecommandline does now. > > After I wrote my message, I realized that yes, all the "sage*" > environments could perhaps be unified. Your idea of one environment that > takes options is a good one. > > Dan > > -- > --- Dan Drake > - http://mathsci.kaist.ac.kr/~drake > --- > > signature.asc > < 1KViewDownload -- 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] #10263: Headings of Sage library code files should state GPLv2+ instead of GPL without version
On Sun, Nov 14, 2010 at 5:29 AM, Jeroen Demeyer wrote: > In the developer documentation, in the section "Headings of Sage library > code files", there is an example heading stating > #* > # Copyright (C) 2008 YOUR NAME > # > # Distributed under the terms of the GNU General Public License (GPL) > # http://www.gnu.org/licenses/ > #* > > I think this should be changed to state the version of the GPL. The > current wording is maybe not technically wrong, but adding the version > would certainly clarify things. > > I have created a patch at #10263 (needs_review) changing this to > #* > # Copyright (C) 2010 YOUR NAME > # > # Distributed under the terms of the GNU General Public License (GPL) > # as published by the Free Software Foundation; either version 2 of > # the License, or (at your option) any later version. > # http://www.gnu.org/licenses/ > #* > > Note that this is NOT a policy change, just a clarification. +1. I certainly can't see any drawback to being clearly with our copyright statements in the way you suggest above. -- 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 patch as a standard package
On Sun, Nov 14, 2010 at 5:00 AM, Jeroen Demeyer wrote: > Hello all, > > There is some work being done at #9418 at make GNU patch a standard > package such that, in the future, spkgs will be able to use "patch" > instead of "cp" to apply patches. > > It is a very simple solution which allows for: > * patching files depending on the system (e.g. if a patch needs to be > applied only on OS X systems) > * patching multiple files with one diff > * patching the same file with multiple diffs > * easily updating a spkg to a new upstream version > * easily adding a new patch to a spkg > * not being forced to update any spkgs, we can keep the old system if we > want (if there is a reason to do that for a particular spkg). > * low maintanance of the "patch" spkg: patch is a very stable program > with essentially no dependencies. > > I realize there have been other proposals to fix the patching, but in my > opinion simply using "patch" is the best solution. Let me also point > out that the spkg is already there (thanks to David Kirkby), so this is > not a theoretical discussion: > http://boxen.math.washington.edu/home/kirkby/patches/patch-2.6.1.spkg > I have also created a proof-of-concept spkg using "patch": > http://sage.math.washington.edu/home/jdemeyer/spkg/sphinx-1.0.4.p2.spkg > (there is a corresponding .p1 which uses "cp") > > So I would mainly like to know if somebody is truly against this > proposal (I would like to avoid posts of the form "but this other method > is even better than patch!" because that will get us nowhere). I'm now not against the proposal of using patch in spkg's, assuming patch gets shipped with Sage. I just don't want to personally have to do the work, and don't want patch to be a prerequisite to build sage. Given that there is a patch spkg, that's not an issue. I am still against storing patch files in the patches/ subdirectory in addition to the patched files. It's redundant and pointless. However, with patch included in Sage, then we can store *only* patches in the patches subdirectory, which makes lots of sense. - -William > > > Jeroen. > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: "Why Sage?" Website Section
On 11/14/10 07:00 PM, Tim Daly wrote: I find it amusing that mathematicians are being told that a math-specific language is a liability. Mathematics is, after all, a specialized language that took me years to learn. I asked RJF what languge he thought the interface should be. As 10 options I consider might be viable choises where 1) Create an entirely new language. 2) Python 3) Maxima 4) A Mathematica like interface 5) A MATLAB like interface 6) A Maple-like interface 7) A Magma-like interface 8) Lisp 9) Q - see http://en.wikipedia.org/wiki/Q_%28equational_programming_language%29 10) Pure http://code.google.com/p/pure-lang/ is another possibility, but that did not exist until 2008, but is based on Q, which existed prior to Sage He failed to response. (He would rather tell me on the Maxima list that I can create an infinite set of integers to do some testing.) But that is to be expected from Richard - a signal to noise ratio of about -30 dB. But what do you think is the ideal language for a user interface? There have been endless attempts at cleating new languages (#1 above). I've even done it myself, to the extent of writing a couple of hundred lines of code for lex and yacc. But it's a very difficult problem to get right, and quite honestly requires a set of sills I don't think a single Sage developer processes. "Pure" seems an interesting language to me. It is headed by someone with both a a maths and a computer science background. But the number of developers can be counted on one hand I think. I agree with William, the best language does depend on the problem. I use both Mathematica and MATLAB and its pretty clear to me that they have their strengths and weaknesses, and one language is more suited to some problems than the other. There are some mathematical tasks that I think are best done with Labview - something totally different to Sage, Axiom, Mathematica, Maple, MATLAB and I assume Magma too, though I have never used Magma. The "glue" language is another issue altogether. The biggest benefit for Python has seemed to be the number of developers. I simply don't think that would exist if using Lisp, Pure or something else a bit more obscure. 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] Renaming the debugging function trace() to trace_execution()
On Sat, Nov 13, 2010 at 3:02 PM, Jeroen Demeyer wrote: > At #9704, there is a positively reviewed proposal to rename the > debugging function trace() to trace_execution() and to use trace() in > the mathematical sense. > > I have nothing to do with that ticket, but I would like to point it out > in case some people really think that it's a bad idea. > I already posted on the ticket that I'm against the current patch at 9704. I hate changing top-level functions in Sage willy-nilly with no major benefit. I want Sage to be stable. There is no way that changing "trace" to "trace_execution" (or the worse and wrong "backtrace", which makes no sense) results in major benefit. - William -- 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: "Why Sage?" Website Section
On Sun, Nov 14, 2010 at 11:00 AM, Tim Daly wrote: > I find it amusing that mathematicians are being told that > a math-specific language is a liability. Mathematics is, > after all, a specialized language that took me years to > learn. > > In any problem you wish to solve with a program there is always > an impedance mismatch (like hooking a soda straw to a firehose). > > You can choose a language close to the machine (e.g assembler) > and "port" your problem across the chasm. Or you can choose a > language close to the problem (e.g. APL) and let the machine do > the "port" across the chasm. Python is somewhere in the middle > where mathematics is concerned. > > Python is a poor match for the machine (interpreted) and it is a > poor match for the mathematics (needing lots of supporting > superstructure the user needs to learn). This is FUD, which tacitly assumes the world is black and white. For a *given problem and mathematician*, sometimes Python (or any language) is an excellent match and sometimes it is a poor match. > As a pragmatic choice for design-by-accretion it is excellent. > But as a selling point for developing mathematics I'm somewhat > more skeptical. > > What is the ultimate purpose of Sage (beyond competition)? The ultimate purpose of Sage is to provide a viable *alternative* to the Ma's. The goal of the Sage project is to create software that can be used by people to solve mathematical problems without them having to rely on closed commercial systems. > Is it a platform for doing computational mathematics? It is software for doing computational mathematics. > If so, why wouldn't I want a language close to my problem, > that is, a language that directly supports well-founded > mathematics? The language you might want depends on *your problem*. In my experience, there are a very, very wide range of problems that one confronts when being involved in mathematics. This ranges from creating webpages and databases, to grading homework, to enumerating all objects with some property, to multiplying polynomials, to experimenting with ideas for algorithms, to drawing pictures of elliptic curves for books and papers, and much more. > And what can that possibly have to do with Python? For some combinations of mathematician + problem, Python is a sufficiently good choice. > Python is the glue. Who chooses a workbench based on the glue? Arguments based on metaphor and analogy. Sigh. If it rhymes, it must be true... > > Tim Daly > > > On 11/13/2010 10:13 AM, rjf wrote: >> >> On Nov 13, 6:32 am, "Johan S. R. Nielsen" >> wrote: >> >>> two info boxes on this suggested "Why Sage"-page. >>> >>> I don't think that Python is the perfect language to write mathematics >>> software with; I would definitely vote on a much more functional >>> language here, e.g. OCaml or maybe even Haskell. However, this would >>> cut out so many potential developers, >> >> ... yada yada... >> >> excessive boosterism. >> >> Consider that symbolic software systems like Maxima/Macsyma, Reduce, >> Axiom, Jacal ... >> were written in Lisp, >> >> and that Mathematica and Maple were written in C dialects... >> >> and even YOU would prefer a different, more functional language. >> >> And then you say Python is still better. >> >> Certainly not for writing math software. Maybe for writing web >> applications? >> >> Because it has a coherent syntax Compared to Lisp or Haskell or >> OCaml? >> Because people who know little mathematics and little about >> programming >> can write/alter/debug applications for SAGE??? About which they >> presumably know >> nothing? And this is because Python is such a winner? >> >> And of course so much of SAGE is not even in Python, but C, Fortran, C+ >> +, Lisp, whatever, >> that even that is nonsense. >> >> excessive boosterism. >> >> At best, you might say, some features of Sage can be augmented by >> writing in Python, and >> the user interface looks like Python (actually it is not, but has to >> be pre-processed). >> >> RJF >> > > -- > 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: "Why Sage?" Website Section
On Nov 13, 4:13 pm, rjf wrote: > On Nov 13, 6:32 am, "Johan S. R. Nielsen" > wrote: > > > two info boxes on this suggested "Why Sage"-page. > > > I don't think that Python is the perfect language to write mathematics > > software with; I would definitely vote on a much more functional > > language here, e.g. OCaml or maybe even Haskell. However, this would > > cut out so many potential developers, > > ... yada yada... > > excessive boosterism. > > Consider that symbolic software systems like Maxima/Macsyma, Reduce, > Axiom, Jacal ... > were written in Lisp, > > and that Mathematica and Maple were written in C dialects... > > and even YOU would prefer a different, more functional language. > > And then you say Python is still better. > > Certainly not for writing math software. Maybe for writing web > applications? > > Because it has a coherent syntax Compared to Lisp or Haskell or > OCaml? > Because people who know little mathematics and little about > programming > can write/alter/debug applications for SAGE??? About which they > presumably know > nothing? And this is because Python is such a winner? > > And of course so much of SAGE is not even in Python, but C, Fortran, C+ > +, Lisp, whatever, > that even that is nonsense. > > excessive boosterism. > > At best, you might say, some features of Sage can be augmented by > writing in Python, and > the user interface looks like Python (actually it is not, but has to > be pre-processed). > > RJF Seems to me that either I completely failed at expressing my ideas clearly, or you failed at reading my post properly. Either way, I get no enjoyment out of discussing in that kind of mode and tone, so I'll just leave it at my last post. Johan -- 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: "Why Sage?" Website Section
I find it amusing that mathematicians are being told that a math-specific language is a liability. Mathematics is, after all, a specialized language that took me years to learn. In any problem you wish to solve with a program there is always an impedance mismatch (like hooking a soda straw to a firehose). You can choose a language close to the machine (e.g assembler) and "port" your problem across the chasm. Or you can choose a language close to the problem (e.g. APL) and let the machine do the "port" across the chasm. Python is somewhere in the middle where mathematics is concerned. Python is a poor match for the machine (interpreted) and it is a poor match for the mathematics (needing lots of supporting superstructure the user needs to learn). As a pragmatic choice for design-by-accretion it is excellent. But as a selling point for developing mathematics I'm somewhat more skeptical. What is the ultimate purpose of Sage (beyond competition)? Is it a platform for doing computational mathematics? If so, why wouldn't I want a language close to my problem, that is, a language that directly supports well-founded mathematics? And what can that possibly have to do with Python? Python is the glue. Who chooses a workbench based on the glue? Tim Daly On 11/13/2010 10:13 AM, rjf wrote: On Nov 13, 6:32 am, "Johan S. R. Nielsen" wrote: two info boxes on this suggested "Why Sage"-page. I don't think that Python is the perfect language to write mathematics software with; I would definitely vote on a much more functional language here, e.g. OCaml or maybe even Haskell. However, this would cut out so many potential developers, ... yada yada... excessive boosterism. Consider that symbolic software systems like Maxima/Macsyma, Reduce, Axiom, Jacal ... were written in Lisp, and that Mathematica and Maple were written in C dialects... and even YOU would prefer a different, more functional language. And then you say Python is still better. Certainly not for writing math software.Maybe for writing web applications? Because it has a coherent syntax Compared to Lisp or Haskell or OCaml? Because people who know little mathematics and little about programming can write/alter/debug applications for SAGE??? About which they presumably know nothing? And this is because Python is such a winner? And of course so much of SAGE is not even in Python, but C, Fortran, C+ +, Lisp, whatever, that even that is nonsense. excessive boosterism. At best, you might say, some features of Sage can be augmented by writing in Python, and the user interface looks like Python (actually it is not, but has to be pre-processed). RJF -- 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: Renaming the debugging function trace() to trace_execution()
Dear all, Students discover Sage for mathematical computations, and the functions are the most usual way to write mathematics. So I prefer a light interface with the matrix function "trace(...)". The determinant is a function and a method... but trace is only a method. And .methods() aren't fully complete in Sage : look at the previous discuss about sum (...) and .sum(). I don't understand why there is a function len(...) over lists, and NO method .len(). map is also a function, not a method. (the other way) I often doubt in Sage : is it a method ? is it a function ? I have less doubts in mathematics. It's always a function. [and in Maple I often doublt : is there a single quote in a calculus or not ?] After some years, students may know AND python AND mathematics, then it's possible to have only a method .trace() for matrix, and a system function trace for debuging... students become gurus ;-). I believe that Maple overwrite the debug function trace in linalg. My use of Sage prefers a system as near as possible to mathematics. François M. -- 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: self.sum() method on vector made of int is not defined
On Sun, Nov 14, 2010 at 5:31 AM, Dima Pasechnik wrote: > > > On Nov 14, 1:51 pm, William Stein wrote: >> Hi, >> >> This thread is about sum. >> >> 1. Dima said: >> >> > I don't think sum() method is needed. It's certainly a code bloat. >> >> This is a very, very misinformed comment. I want to address it, >> especially the statement "It's certainly a code bloat." > > Sorry if I sounded too categorical on this. > I suppose I meant two things: > > 1) self.sum() on vectors is not too useful. > A fast scalar product would be much more useful than .sum(). > > 2) wanting a fast sum (or a scalar product), that works faster than > Python's function sum(), yet does not require a handwritten code in > every vector*.pyx, one seems to be hitting the limitation of Cython, > which lacks generics. > > The code from TimeSeries: > > cpdef double sum(self): > ... > cdef double s = 0 > cdef Py_ssize_t i > for i from 0 <= i < self._length: > s += self._values[i] > return s > > is totally generic, except the type declaration. If Cython had > generics (aka templates) one would have written > > cpdef T sum(self): > ... > cdef T s = 0 > cdef Py_ssize_t i > for i from 0 <= i < self._length: > s += self._values[i] > return s > > in the parent class of a vector class over T, rather than in the > vector classes, for T=double, etc etc themselves. > (Perhaps something like this can still be accomplished within Sage, > but I don't see how.) There are at least two ways to do something generic with Cython to solve the above problem. 1) You could use templates in Cython, which now come via the new C++ support: http://docs.cython.org/src/userguide/wrapping_CPlusPlus.html This requires a snippet of C++ that's put in a header file somewhere. I.e., right now you have to combine a bunch of Cython code with a little C++ code. 2) One could use function pointers and/or typecasting in Cython (just like you would in C), but this is potentially extra dangerous. Though C++ does support generics well, try spend some time with the Linbox source code (say) to see how dangerous (to readability) this feature can be if not used sparingly. -- William -- 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: self.sum() method on vector made of int is not defined
On Nov 14, 1:51 am, William Stein wrote: > 1. Dima said: > > I don't think sum() method is needed. It's certainly a code bloat. > > Yes, the two methods accomplish the same thing. Actually, there is also a slight (but sometimes significant) functional difference between the two methods: sage: from __builtin__ import sum sage: x = vector(RDF, [1, 2, 3]) sage: y = vector(RDF, []) sage: print x.sum(), type(x.sum()) 6.0 sage: print sum(x), type(sum(x)) 6.0 sage: print y.sum(), type(y.sum()) 0.0 sage: print sum(y), type(sum(y)) 0 The builtin Python sum() returns the int 0 when summing an empty container, whereas self.sum() usually returns the zero of the base ring for empty containers. I've been bitten a few times by functions which unexpectedly return an int instead of an Integer, or a zero element with the wrong type; it's sometimes hard to debug, and always annoying! Mathieu -- 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: "Why Sage?" Website Section
Second +1 Jonathan On Nov 13, 9:07 pm, "Dr. David Kirkby" wrote: > On 11/14/10 02:54 AM, Eviatar wrote: > > > Anyway, I made an updated version (linking seems to work now): > > >http://oi55.tinypic.com/rclh5l.jpg > > I think that's better. At least the maths part is first. > > Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] matrix output strangeness
Something is not quite right in the cleverness used to output matrices: sage: M 76 x 58 dense matrix over Integer Ring (type 'print M.str()' to see all of the entries) sage: M.hermite_form() 76 x 58 dense matrix over Integer Ring (type 'print hnf-True-False.str()' to see all of the entries) 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: Adding patch as a standard package
On Nov 14, 9:00 pm, Jeroen Demeyer wrote: > Hello all, > > There is some work being done at #9418 at make GNU patch a standard > package such that, in the future, spkgs will be able to use "patch" > instead of "cp" to apply patches. > > It is a very simple solution which allows for: > * patching files depending on the system (e.g. if a patch needs to be > applied only on OS X systems) > * patching multiple files with one diff > * patching the same file with multiple diffs > * easily updating a spkg to a new upstream version > * easily adding a new patch to a spkg > * not being forced to update any spkgs, we can keep the old system if we > want (if there is a reason to do that for a particular spkg). > * low maintanance of the "patch" spkg: patch is a very stable program > with essentially no dependencies. > > I realize there have been other proposals to fix the patching, but in my > opinion simply using "patch" is the best solution. Let me also point > out that the spkg is already there (thanks to David Kirkby), so this is > not a theoretical > discussion:http://boxen.math.washington.edu/home/kirkby/patches/patch-2.6.1.spkg > I have also created a proof-of-concept spkg using > "patch":http://sage.math.washington.edu/home/jdemeyer/spkg/sphinx-1.0.4.p2.spkg > (there is a corresponding .p1 which uses "cp") > > So I would mainly like to know if somebody is truly against this > proposal (I would like to avoid posts of the form "but this other method > is even better than patch!" because that will get us nowhere). > Lang leve de Patch! :) > Jeroen. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: self.sum() method on vector made of int is not defined
On Nov 14, 1:51 pm, William Stein wrote: > Hi, > > This thread is about sum. > > 1. Dima said: > > > I don't think sum() method is needed. It's certainly a code bloat. > > This is a very, very misinformed comment. I want to address it, > especially the statement "It's certainly a code bloat." Sorry if I sounded too categorical on this. I suppose I meant two things: 1) self.sum() on vectors is not too useful. A fast scalar product would be much more useful than .sum(). 2) wanting a fast sum (or a scalar product), that works faster than Python's function sum(), yet does not require a handwritten code in every vector*.pyx, one seems to be hitting the limitation of Cython, which lacks generics. The code from TimeSeries: cpdef double sum(self): ... cdef double s = 0 cdef Py_ssize_t i for i from 0 <= i < self._length: s += self._values[i] return s is totally generic, except the type declaration. If Cython had generics (aka templates) one would have written cpdef T sum(self): ... cdef T s = 0 cdef Py_ssize_t i for i from 0 <= i < self._length: s += self._values[i] return s in the parent class of a vector class over T, rather than in the vector classes, for T=double, etc etc themselves. (Perhaps something like this can still be accomplished within Sage, but I don't see how.) Dima -- 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] #10263: Headings of Sage library code files should state GPLv2+ instead of GPL without version
In the developer documentation, in the section "Headings of Sage library code files", there is an example heading stating #* # Copyright (C) 2008 YOUR NAME # # Distributed under the terms of the GNU General Public License (GPL) # http://www.gnu.org/licenses/ #* I think this should be changed to state the version of the GPL. The current wording is maybe not technically wrong, but adding the version would certainly clarify things. I have created a patch at #10263 (needs_review) changing this to #* # Copyright (C) 2010 YOUR NAME # # Distributed under the terms of the GNU General Public License (GPL) # as published by the Free Software Foundation; either version 2 of # the License, or (at your option) any later version. # http://www.gnu.org/licenses/ #* Note that this is NOT a policy change, just a clarification. Jeroen. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Adding patch as a standard package
Hello all, There is some work being done at #9418 at make GNU patch a standard package such that, in the future, spkgs will be able to use "patch" instead of "cp" to apply patches. It is a very simple solution which allows for: * patching files depending on the system (e.g. if a patch needs to be applied only on OS X systems) * patching multiple files with one diff * patching the same file with multiple diffs * easily updating a spkg to a new upstream version * easily adding a new patch to a spkg * not being forced to update any spkgs, we can keep the old system if we want (if there is a reason to do that for a particular spkg). * low maintanance of the "patch" spkg: patch is a very stable program with essentially no dependencies. I realize there have been other proposals to fix the patching, but in my opinion simply using "patch" is the best solution. Let me also point out that the spkg is already there (thanks to David Kirkby), so this is not a theoretical discussion: http://boxen.math.washington.edu/home/kirkby/patches/patch-2.6.1.spkg I have also created a proof-of-concept spkg using "patch": http://sage.math.washington.edu/home/jdemeyer/spkg/sphinx-1.0.4.p2.spkg (there is a corresponding .p1 which uses "cp") So I would mainly like to know if somebody is truly against this proposal (I would like to avoid posts of the form "but this other method is even better than patch!" because that will get us nowhere). Jeroen. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Renaming the debugging function trace() to trace_execution()
On 2010-11-14 09:59, François Bissey wrote: > I like your general argument and I like the name backtrace rather than trace > as well. Let me point out that backtrace() usually means something else: it gives the stack of functions called (Python calls it Traceback and prints it when an exception occured). Jeroen. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Renaming the debugging function trace() to trace_execution()
On 14 November 2010 08:59, François Bissey wrote: >> Hi Jeroen! >> >> On 14 Nov., 00:02, Jeroen Demeyer wrote: >> > At #9704, there is a positively reviewed proposal to rename the >> > debugging function trace() to trace_execution() and to use trace() in >> > the mathematical sense. >> > >> > I have nothing to do with that ticket, but I would like to point it out >> > in case some people really think that it's a bad idea. >> >> My 0.02 Euros: >> >> Since Sage's user interface is based on Python, I find it generally a >> bad idea to have a *function* for computing mathematical data: It >> should rather be by calling a method! >> >> So, the computation of the trace of a matrix M, it should be >> M.trace(), not trace(M). I am "-1" to introducing a mathematical trace >> function. >> >> On the other hand, due to the lack of grammar in the English language, >> it is not clear whether "trace" is used as a noun or not. If you want >> "the trace" of a matrix, it is a noun. If it is "to trace" a >> computation, it is a verb. So, in order to avoid confusion between the >> two notions of trace, one might indeed consider to rename the non- >> mathematical trace. >> >> According to "LEO" (an online dictionary), the awkward German word >> "Ablaufverfolgung" is "trace" in the non-mathematical sense, and may >> also be translated as "tracing" or "backtrace". >> >> So, why not have a function "tracing" or "backtrace" in Sage for >> tracing a computation and getting a backtrace? >> > I like your general argument and I like the name backtrace rather than trace > as well. I guess a trace method and a trace function could cohabit but that's > not ideal. > > To add to Dave's comment if I remember correctly in Mathematica the > mathematical trace is "Tr". > > Francois Yes, I was not aware of that myself, but you are right. I personally think given trace() in the non-mathematical sense is already in Sage, and furthermore it is the same command as used in a package Sage aims to be a viable alternative to, we should stick with what we have. It should however be noted MATLAB uses 'trace' in the mathematical sense http://www.mathworks.com/help/techdoc/ref/trace.html To me at least, Sage has far more in common with Mathematica than it does MATLAB anyway 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] Example worksheets contest
I've offered to make worksheets for publication in the past, and I'll commit to submitting 3 worksheets to this contest. Make it happen! On Sun, Nov 14, 2010 at 1:35 AM, mmarco wrote: > I wrote a message in an old thread about the need of good examples in > the documentation, but, i don't know why, it didn't show up. So i > reproduce it here: > >> Sorry for bringing a thread back to life several months later, but >> reading some other threads about publicly available examples this one >> came to my mind. >> >> I have a (maybe crazy) suggestion to get those 30 example worksheets >> (and maybe more just to show everybody that sage is the best CAS in >> the worldwide world, which is a step in the world domination plan and >> so on): organize a contest. >> >> Anounce through every possible channel (the project web page, the >> notebooks, discussion groups...) it a month or two before the >> deadline. Select a jury. Check if there is some funding available for >> prices (maybe just a diploma and an anouncement of the winners in the >> web page would be good, but adding a t-shirt and/or a poster wouldn't >> hurt). And there you are: you would get a good amount of good example >> worksheets to include in the documentation. >> > > Any comments? > > -- > 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] Example worksheets contest
I wrote a message in an old thread about the need of good examples in the documentation, but, i don't know why, it didn't show up. So i reproduce it here: > Sorry for bringing a thread back to life several months later, but > reading some other threads about publicly available examples this one > came to my mind. > > I have a (maybe crazy) suggestion to get those 30 example worksheets > (and maybe more just to show everybody that sage is the best CAS in > the worldwide world, which is a step in the world domination plan and > so on): organize a contest. > > Anounce through every possible channel (the project web page, the > notebooks, discussion groups...) it a month or two before the > deadline. Select a jury. Check if there is some funding available for > prices (maybe just a diploma and an anouncement of the winners in the > web page would be good, but adding a t-shirt and/or a poster wouldn't > hurt). And there you are: you would get a good amount of good example > worksheets to include in the documentation. > Any comments? -- 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] preparser and from __future__ import problem
Hey Guys, Sorry for the repost. I have already posted this some months ago but it received no answer on sage-support. I am afraid this is a bug but the guidelines ask to first post here before reporting something on trac. Could you look into this (I have done the best to illustrate the problem): I am new to Sage and Python. I have encountered a problem with importing form __future__. The commands that I execute work perfectly on a pure python environment but apparently there is some kind of problem introduced by the preparser. The problem is that I cannot "from __future__ import print_function" that is I cannot import the more up-to-date functionality of print as a function. The only workaround is turning the SAGE preparser temporarily off. An other secondary bug appears to be the fact that it is impossible to evaluate preparser(False) and from __future__ import command in the same cell while doing it in two separate cells works perfectly. This was a filed bug in some previous SAGE version (cannot find the relevant ticket in the trac) but although marked as closed apparently is still present. A notebook that fully explains the problem is published at: http://www.sagenb.org/home/pub/2155 Can you look into this and tell me if I should file a bug report. Or maybe somebody more expert can do this. Best Regards, Gennady N. Uraltsev -- 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: Renaming the debugging function trace() to trace_execution()
> Hi Jeroen! > > On 14 Nov., 00:02, Jeroen Demeyer wrote: > > At #9704, there is a positively reviewed proposal to rename the > > debugging function trace() to trace_execution() and to use trace() in > > the mathematical sense. > > > > I have nothing to do with that ticket, but I would like to point it out > > in case some people really think that it's a bad idea. > > My 0.02 Euros: > > Since Sage's user interface is based on Python, I find it generally a > bad idea to have a *function* for computing mathematical data: It > should rather be by calling a method! > > So, the computation of the trace of a matrix M, it should be > M.trace(), not trace(M). I am "-1" to introducing a mathematical trace > function. > > On the other hand, due to the lack of grammar in the English language, > it is not clear whether "trace" is used as a noun or not. If you want > "the trace" of a matrix, it is a noun. If it is "to trace" a > computation, it is a verb. So, in order to avoid confusion between the > two notions of trace, one might indeed consider to rename the non- > mathematical trace. > > According to "LEO" (an online dictionary), the awkward German word > "Ablaufverfolgung" is "trace" in the non-mathematical sense, and may > also be translated as "tracing" or "backtrace". > > So, why not have a function "tracing" or "backtrace" in Sage for > tracing a computation and getting a backtrace? > I like your general argument and I like the name backtrace rather than trace as well. I guess a trace method and a trace function could cohabit but that's not ideal. To add to Dave's comment if I remember correctly in Mathematica the mathematical trace is "Tr". Francois -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Memory hits the roof when I divide a sage vector.
On Nov 13, 12:30 pm, Robert Bradshaw wrote: > On Fri, Nov 12, 2010 at 7:10 PM, Jason Grout > > > > > > wrote: > > On 11/12/10 8:48 PM, Jason Grout wrote: > > >> On 11/12/10 6:22 PM, Maxim wrote: > > >>> I get very high memory usage when I do something like: > >>> sage: get_memory_usage() > >>> -> 809.9453125 > >>> sage: A=vector(range(0,1))/1 > >>> sage: get_memory_usage() > >>> -> 5393.2734375 > > >>> Which is a whooping 4.5GB+ of memory to hold a 1 float vector... > > >>> I would have thought more of something along the lines of 24bytes/ > >>> float * 1 floats + some overhead for the vector object ~= 240KB. > > > The problem seems to stem from the lines > > > cdef Element x = X.an_element() > > cdef Element y = Y.an_element() > > > inside of the detect_element_action function in coerce_actions.pyx. Notice: > > > sage: v=vector(range(1)) > > sage: get_memory_usage() > > 206.84765625 > > sage: w=v.parent().an_element() > > sage: get_memory_usage() > > 3321.14453125 > > > I'm not sure why the coercion system *has* to construct an element, > > especially if such an element could potentially be expensive to compute and > > store. > > It only has to construct an element if it can't figure out what to do > after consulting the Parents themselves. > > > And then there's the matter you talk about; why is an element so big? > > The example above is quite strange. No idea why it should be so big. > (Note that these are are arbitrary precision integers, so the relative > overhead for small ones is still quite large). > > As for the original example, > > sage: type(vector(RR, range(100))) > > > Which means that each element is a full Python RealNumber, quite a bit > more than a double. Still doesn't explain the memory usage. For almost > any kind of linear algebra, you're better off using RDF, or even numpy > directly. > > There's something really fishy going on, as > > sage: get_memory_usage() > 222.671875 > sage: A=vector(range(0,1000)) > sage: get_memory_usage() > 222.671875 > sage: A=vector(range(0,1000))/1 > sage: get_memory_usage() # barely any more... > 253.67578125 > sage: A=vector(range(0,1))/1 > # eats up *tons* of memory, swapping like crazy. it goes on to construct a basis (and what not?) for A.parent(), that's why... See http://trac.sagemath.org/sage_trac/ticket/10262 Dima > > - 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
