[sage-devel] Problem building sage 3.1 on Debian lenny amd 64
Hi, I try to compile sage on my opteron machine. When compiling flint, I get the ld error message: /usr/bin/ld: cannot find -lstdc++ Th ld lines are: g++ -I/usr/local/sage-3.1/local/include/ -I/usr/local/sage-3.1/local/include -f PIC -funroll-loops -O3 -c NTL-interface.cpp -o NTL-interface.o gcc -std=c99 -fPIC -shared -Wl,-soname,lib`cat DIRNAME`.so -o lib`cat DIRNAME`.s o mpn_extras.o mpz_extras.o memory-manager.o ZmodF.o ZmodF_mul.o ZmodF_mul-tunin g.o fmpz.o fmpz_poly.o mpz_poly-tuning.o mpz_poly.o ZmodF_poly.o long_extras.o z mod_poly.o NTL-interface.o -L/usr/local/sage-3.1/local/lib/ -L/usr/local/sage-3.1/local/lib/ -lgmp -lpthread -lntl -lm -lstdc++ and so, we certainly try to find a libstdc++ in /usr/local/sage-3.1/local/lib/ and, actually, there is non stl lib installed there. The stl lib is system wide installed yours t. begin:vcard fn:Thierry Dumont n:Dumont;Thierry org;quoted-printable:CNRS - Universit=C3=A9 Lyon 1. / Villeurbanne France.;Institut Camille Jordan adr:;;43 Bd du 11 Novembre;Villeurbanne Cedex;F;69621;France email;internet:[EMAIL PROTECTED] title;quoted-printable:Ing=C3=A9nieur de Recherche/Research Ingeneer tel;work:(33) 4 72 44 85 23 x-mozilla-html:FALSE url:http://math.univ-lyon1.fr/~tdumont version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
[sage-devel] Proposal for inclusion of GINAC/pynac-0.1 in Sage.
Hi,
I propose that pynac be included in Sage.
Pynac is a rewrite of Ginac to seamlessly use native Python objects instead
of CLN -- for inclusion in Sage. Pynac is a C++ library plus extensive
Cython bindings. Pynac is about 30K lines, is very well documented and
commented, and as C++ code goes is extremely readable.
VOTE:
[ ] Yes, include Pynac in Sage
[ ] No, do not (please explain)
[ ] Hmm, I have questions (please ask).
MANY MORE DETAILS:
The idea to rewrite Ginac so it can manipulate native Python objects
directly appears to be new, and hasn't been tried before.
After thinking through all the options in detail, having experimented
with gfurnish's symbolics approach, watching how sympycore and sympy
have developed, and seeing what is possible using Maxima and Axiom,
I think Burcin's proposal to use a rewritten Ginac as the core symbolics
library for Sage is by far the best, given the goal of having a very solid
nearly-bug-free-well-documented-robust-fast symbolic system in literally
weeks from when we start. Absolutely all other approaches result in
something that either doesn't scale speedwise, is buggy, is slow, or
will take a long time to finish.I'm so convinced that Burcin is right
about the Ginac approach that I've invested most of my time during
the last two weeks in this.
The new Pynac:
(1) doesn't depend at all on (the heavy) CLN library,
(2) can manipulate Python objects instead of CLN classes,
(3) has Cython bindings that replicate roughly 50% (?) of the
functionality of the current Sage calculus, and at the same time
works with many more data types in Sage (e.g., interval arithmetic)
unlike the current calculus code which only works with types
that Maxima supports. Currently the new code is 100% independent
of the Maxima-base calculus code in sage, and in many cases
much faster and potentially more powerful.
To try it out:
(a) if you have an account on sage.math, just run the system-wide sage.
(b) To install yourself into sage-3.1.1, see
http://sage.math.washington.edu/home/was/pynac/
In particular, do
sage -i http://sage.math.washington.edu/home/was/pynac/pynac-0.1.spkg
The above build should take between 2 and 6 minutes depending on how fast
your computer is. On one of my test machines with export MAKE=make -j4
it takes 45 seconds realtime to build.
Then do:
sage: hg_sage.pull()
sage:
hg_sage.apply('http://sage.math.washington.edu/home/was/pynac/pynac.hg')
sage: hg_sage.merge() # possibly not needed
sage: hg_sage.ci() # possibly not needed
and exit and do:
sage -br
You can create symbolic expression in the new symbolic ring
by doing e.g.,
sage: var('x,y,z',ns=1)
(x, y, z)
sage: f = (x+y+sin(z)^x)^3
sage: f.expand()
3*sin(z)^x*x^2 + 3*sin(z)^x*y^2 + 3*(sin(z)^x)^2*x + ...[snip]
sage: f.[tab]
An example with interval coefficients:
sage: f = x^3 + x^RIF(1) + y*RIF(pi)
sage: f
x^3 + x^(1.?) + (3.141592653589794?)*y
sage: expand(f^2).diff(y)
(6.283185307179587?)*x^3 + (6.283185307179587?)*x + (19.73920880217872?)*y
Arithmetic with relations is fully supported, including squaring both
sides:
sage: f = (x^3 + x - 2/3 + y x^3)
sage: f^2
(x^3 + x + y - 2/3)^2 x^6
sage: f - x^3
x + y - 2/3 0
Arithmetic with formal functions -- something that Burcin was originally
very concerned about -- is well supported. Here's an example illustrating
applying a differential operator and extracting off coefficients of
it, a feature
that somebody recently wanted but the current Sage calculus didn't have:
sage: from sage.symbolic.function import function
sage: r, kappa = var('r,kappa', ns=1)
sage: psi = function('psi', 1)(r)
sage: g = 1/r^2*(2*r*psi.diff(r,1) + r^2*psi.diff(r,2)); g
(2*psi(1,r)*r + psi(2,r)*r^2)*r^(-2)
sage: g.coeff(psi.diff(r,2))
1
sage: g.coeff(psi.diff(r,1))
2*r^(-1)
See the directory SAGE_ROOT/devel/sage/sage/symbolic for nearly 500 lines of
input examples or point your browser here:
http://sage.math.washington.edu/home/was/d/sage/symbolic/
Let me know if you have any questions.
There are still a lot of questions that I didn't answer above. Including:
(a) who will do the actual work? (mainly Burcin at this point)
(b) what will the new design look like? How much
will change from the current symbolic calculus interface?
In particular, how are we ensuring that the many requests
from users in recent threads are addressed in this redesign?
(See http://wiki.sagemath.org/symbench)
(c) how does all this relate to the coercion model?
(That will help with, e.g., a symbolic complex number type.)
(d) what's the time frame for completely replacing the current calculus code?
(Two months?)
(e) how does this relate to sympy?
(I dont' know.
Sympy does several things Ginac doesn't, such as symbolic
integration and
sophisticated limits. I would like to find a way to somehow
reuse that code directly,
especially since
[sage-devel] Re: Problem building sage 3.1 on Debian lenny amd 64
2008/8/25 Thierry Dumont [EMAIL PROTECTED]: Hi, I try to compile sage on my opteron machine. What compiler version, exact operating sytem, etc.? When compiling flint, I get the ld error message: /usr/bin/ld: cannot find -lstdc++ Th ld lines are: g++ -I/usr/local/sage-3.1/local/include/ -I/usr/local/sage-3.1/local/include -f PIC -funroll-loops -O3 -c NTL-interface.cpp -o NTL-interface.o gcc -std=c99 -fPIC -shared -Wl,-soname,lib`cat DIRNAME`.so -o lib`cat DIRNAME`.s o mpn_extras.o mpz_extras.o memory-manager.o ZmodF.o ZmodF_mul.o ZmodF_mul-tunin g.o fmpz.o fmpz_poly.o mpz_poly-tuning.o mpz_poly.o ZmodF_poly.o long_extras.o z mod_poly.o NTL-interface.o -L/usr/local/sage-3.1/local/lib/ -L/usr/local/sage-3.1/local/lib/ -lgmp -lpthread -lntl -lm -lstdc++ and so, we certainly try to find a libstdc++ in /usr/local/sage-3.1/local/lib/ and, actually, there is non stl lib installed there. The stl lib is system wide installed yours t. -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Problem building sage 3.1 on Debian lenny amd 64
William Stein a écrit : 2008/8/25 Thierry Dumont [EMAIL PROTECTED]: Hi, I try to compile sage on my opteron machine. What compiler version, exact operating sytem, etc.? OS: Debian lenny, amd64 (up to date). gcc version 4.3.1 (Debian 4.3.1-2) t. When compiling flint, I get the ld error message: /usr/bin/ld: cannot find -lstdc++ Th ld lines are: g++ -I/usr/local/sage-3.1/local/include/ -I/usr/local/sage-3.1/local/include -f PIC -funroll-loops -O3 -c NTL-interface.cpp -o NTL-interface.o gcc -std=c99 -fPIC -shared -Wl,-soname,lib`cat DIRNAME`.so -o lib`cat DIRNAME`.s o mpn_extras.o mpz_extras.o memory-manager.o ZmodF.o ZmodF_mul.o ZmodF_mul-tunin g.o fmpz.o fmpz_poly.o mpz_poly-tuning.o mpz_poly.o ZmodF_poly.o long_extras.o z mod_poly.o NTL-interface.o -L/usr/local/sage-3.1/local/lib/ -L/usr/local/sage-3.1/local/lib/ -lgmp -lpthread -lntl -lm -lstdc++ and so, we certainly try to find a libstdc++ in /usr/local/sage-3.1/local/lib/ and, actually, there is non stl lib installed there. The stl lib is system wide installed yours t. begin:vcard fn:Thierry Dumont n:Dumont;Thierry org;quoted-printable:CNRS - Universit=C3=A9 Lyon 1. / Villeurbanne France.;Institut Camille Jordan adr:;;43 Bd du 11 Novembre;Villeurbanne Cedex;F;69621;France email;internet:[EMAIL PROTECTED] title;quoted-printable:Ing=C3=A9nieur de Recherche/Research Ingeneer tel;work:(33) 4 72 44 85 23 x-mozilla-html:FALSE url:http://math.univ-lyon1.fr/~tdumont version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
VOTE: [ ] Yes, include Pynac in Sage [ ] No, do not (please explain) [ ] Hmm, I have questions (please ask). I don't know if my vote counts, but I am of course +1. Thanks for pioneering the use of Python in C projects, I hope people will now try much more to reuse C/C++ code. (e) how does this relate to sympy? (I dont' know. Sympy does several things Ginac doesn't, such as symbolic integration and sophisticated limits. I would like to find a way to somehow reuse that code directly, especially since sympy is in sage already, and is already often better than using Sage's current maxima + pexpect symbolic manipulation. On the other hand, Burcin is I think driven mostly by his Ph.D. thesis research, and has told me he will only write GPL'd code, which means it can't go into Sympy.) I think porting the limits is quite easy, but unfortunately ginac series expansion is not sophisticated enough for more complicated limits (at least last time I tried, it was I think 2 years ago), so you will have to port the sympy's series expansion as well, or improve ginac series expansion. As to integration, that will be I think a little more difficult to port, but definitely doable as well. As to GPL vs BSD, I am sad that some people will not contribute to a BSD project and some other people will not use a GPL project. But my intuition says that the license is not the main reason. If sympy was as fast as ginac (as I hope it will be in not so distant future), I am sure it'd be ok, even if it's BSD. BTW, I told Burcin and William that if the license was the only reason, I am willing to consider switching to GPL (i.e. try to persuade all 44+ contributors), if that would mean more people would be developing sympy. Currently it seems to be the opposite, i.e. when we switched from GPL to BSD, people and developers seemed to like it, but I may well be mistaken. But as I said, I think the main problem of sympy is not the license, but speed. I myself like the way sympy is designed, e.g. pure python + now we are working on the Cython core (+possibly pynac if it's a better alternative, even though some sympy developers seems to prefer pure Cython solution if we can made it as fast as pynac), because that allows to use sympy easily in the google app engine, hopefully soon in pypy and jython, and also as a compiled library when we get the core in with exactly the same interface, i.e., whenever there is python, it should work on it. On the other hand, if you are willing to release and maintain pynac outside sage, so that it's easy to use and basically implement or port all sympy to it, I'll be more than happy that someone else will do my job and I can move to do some more advanced things. I really don't want to have two codebases for the same thing. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Templating engine for the Notebook
Hi, Regarding the Sage Notebook, I propose that we use a templating engine instead of using Python string templates class and writing HTML code in the Python code. I have converted the existing templates in Extcode to templates that use the Jinja engine, see http://trac.sagemath.org/sage_trac/ticket/3923. I also moved the HTML for the Account Settings page to a Jinja template, see http://trac.sagemath.org/sage_trac/ticket/3937. I think using Jinja makes the Python code more readable. In addition, I like be able to create a base template that other templates build upon. Plus it's nice to be able to use for loops and if statements in the templates. I use both in the templates at the two tickets. Jinja is a clone of the templating engine used in the most popular Python web framework Django. I am very interested in the possibility of migrating the Sage Notebook to Django. Moving all the Notebook's HTML to Jinja templates is the first step in migrating. If Sphinx, a documentation system, is distributed with Sage then Jinja would also be. See the sage-devel thread Sphinx and the Sage Documentation at http://groups.google.com/group/sage-devel/browse_thread/thread/7b0b2f0b34f1f892/ Timothy --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
On Mon, Aug 25, 2008 at 12:55 AM, Jason Merrill [EMAIL PROTECTED] wrote:
In hopes that it may be a useful reference during the current work on
symbolics, I wrote a toy Mathematica program for transforming a single
higher order ODE into a system of first order ODEs. Most of the free
numerical differential equation solvers I've seen want input in the
form y'[x] == f(y,x), so the purpose of a program like this is to take
more general input and turn it into something suitable for those
routines.
I'll use the Poisson-Boltzmann equation in spherical coordinates, a
second order ODE, as my test example, because I recently needed to
solve it numerically.
pbe = r^2 p''[r] + 2 r p'[r] == r^2 k^2 Sinh[p[r]]
The full form of the equation, which is useful for pattern matching,
is
FullForm[pbe]
Equal[Plus[Times[2,r,Derivative[1][p][r]],Times[Power[r,
2],Derivative[2][p][r]]],Times[Power[k,2],Power[r,2],Sinh[p[r
Notice how this looks a lot like Lisp?
First, I want to find out what the order of the equation is, so I will
match any terms of the form Derivative[o][p][r], and then find the
match with the maximum o:
diffEqOrder[eqn_, y_, x_] :=
Max[Cases[pbe, Derivative[o_][y][x] - o, Infinity]]
Cases produces a list of all the subexpressions in its first argument
that match the pattern specified in the second argument, optionally
with a replacement rule applied to the matches. By default, it only
looks at the top level of an expression, but setting the final
argument to Infinity forces it to look all the way down the tree. The
_ here is a wildcard that matches any expression, and writing o_ gives
that subexpression a name. Since o is the only part I care about, I
replace all the matches with just o.
diffEqOrder[pbe, p, r]
2
Now we're ready for the function that actually transforms equations:
firstOrderForm[eqn_, y_, x_] :=
Module[{rep, order = diffEqOrder[eqn, y, x]},
rep = Solve[
eqn /. {Derivative[o_][y][x] - y[o][x], y[x] - y[0][x]},
y[order][x]];
Join[Table[y'[o][x] == y[o + 1][x], {o, 0, order - 2}],
y'[order - 1][x] == y[order][x] /. rep]
]
The Module bit is just for keeping variables used in the definition
out of global scope. The important line is
eqn /. {Derivative[o_][y][x] - y[o][x], y[x] - y[0][x]}
where I use the replacement operator /. to replace all the derivatives
of y with respect to x by a new function of x, y[o][x], where o is
again the order of the derivative. Once I've done that, I solve the
equation for the highest order term. Then I make a list basically
just giving definitions of all the new functions as derivatives of the
next lower order functions, and stick the solved highest order
derivative equation on the end of the list.
Here's the result for the example equation
firstOrderForm[pbe, p, r]
{p'[0][r] == p[1][r], p'[1][r] == (k^2 r Sinh[p[0][r]] - 2 p[1][r])/r}
It's just a short shot from here to providing the input in a form that
would be accepted by the gsl solver, or scipy.
Hopefully this will be useful as one example of the kind of
manipulations that pattern matching makes possible. I'm happy to
answer any more questions about it.
Thanks for doing this. It is indeed very useful, I always wondered how
things like this are done in Mathematica.
Any ideas how this could be nicely translated to Python?
Ondrej
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
On Sun, 24 Aug 2008 15:55:25 -0700 (PDT) Jason Merrill [EMAIL PROTECTED] wrote: In hopes that it may be a useful reference during the current work on symbolics, I wrote a toy Mathematica program for transforming a single higher order ODE into a system of first order ODEs. Most of the free numerical differential equation solvers I've seen want input in the form y'[x] == f(y,x), so the purpose of a program like this is to take more general input and turn it into something suitable for those routines. snip Thank you for taking the time to write this. It is very useful indeed. The interface to pynac (William's modified version of GiNaC) doesn't support pattern matching yet, though it is not hard to add this. I'll add this functionality and try to reproduce your example in Sage once I finish reviewing the initial pynac interface patches (#3872). Cheers, Burcin --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 4:59 AM, William Stein [EMAIL PROTECTED] wrote: Hi, I propose that pynac be included in Sage. Pynac is a rewrite of Ginac to seamlessly use native Python objects instead of CLN -- for inclusion in Sage. Pynac is a C++ library plus extensive Cython bindings. Pynac is about 30K lines, is very well documented and commented, and as C++ code goes is extremely readable. VOTE: [x ] Yes, include Pynac in Sage [ ] No, do not (please explain) [ ] Hmm, I have questions (please ask). Looks very nice! MANY MORE DETAILS: ... I think with polish and proper refereeing, the code Burcin and I have already written should be included in Sage, so that others can start using it and developing it further. -- William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Templating engine for the Notebook
Hi On Aug 25, 1:39 pm, Timothy Clemans [EMAIL PROTECTED] wrote: I am very interested in the possibility of migrating the Sage Notebook to Django. Moving all the Notebook's HTML to Jinja templates is the first step in migrating. My comments on that are based on my experience with something similar - writing jsp and servlet code in java. But anyways, using templates has a lot of benefits. Faster development, easier maintenance and extensibility, i.e. extending basic templates with specialized functionality and so on. This is also useful for things like i18n internationalization of the interface, where just a middleware layer switches according to a language parameter and nobody has to poke around inside the current python code to replace strings. Another point is, that editing html content is more error prone since there is a better separation of code, logic and html. Also, the processing is faster since templates are only loaded once. according to the django- book website, there are also addons for authentication and administration that makes development easier and the interface more stable. h --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] missing imports for experimental module for Sage
Hi, i'am testing a Python module i wrote and placed it in one of the pathes visited by Sage's Python while importing. I try to do the necessary imports at the beginning of my module but it seem's to be an endless quest. I am not an experienced Python user. Can anybody give me a hint ? (rem : the classes defined in that module work fine if placed in a notebook cell) Philippe --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Comparing complex numbers
On Sat, Aug 23, 2008 at 7:09 PM, Nils Bruin [EMAIL PROTECTED] wrote: On Aug 23, 1:27 pm, William Stein [EMAIL PROTECTED] wrote: Did you read through the article Alfredo Portes posted, which also explains some of the gotchas and subtleties of disallowing comparisons? I'm curious what you thought of it. At the very least, should be transitive wherever it is allowed. The one example that David Mertz gives in favour of universal ordering is sorting, which completely hinges on transitivity of . As it stands at the moment with 1 None int(0), this is already violated. That means that any algorithm based on sorting can fail in unpredictable ways. [...] Just as another data point, since I happened to see it when reading source code, in the Ginac library (http://www.ginac.de) we find this comment: /** This method establishes a canonical order on all numbers. For complex * numbers this is not possible in a mathematically consistent way but we need * to establish some order and it ought to be fast. So we simply define it * to be compatible with our method csgn. * * @return csgn(*this-other) * @see numeric::csgn() */ I'm not making or suggesting any conclusions -- just adding another data point. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: missing imports for experimental module for Sage
On Mon, Aug 25, 2008 at 8:20 AM, Philippe Saade [EMAIL PROTECTED] wrote: Hi, i'am testing a Python module i wrote and placed it in one of the pathes visited by Sage's Python while importing. I try to do the necessary imports at the beginning of my module but it seem's to be an endless quest. I am not an experienced Python user. Can anybody give me a hint ? Did you add it to devel/sage/setup.py? (rem : the classes defined in that module work fine if placed in a notebook cell) Philippe --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
On Aug 25, 7:46 am, Ondrej Certik [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 12:55 AM, Jason Merrill [EMAIL PROTECTED] wrote: In hopes that it may be a useful reference during the current work on symbolics, I wrote a toy Mathematica program for transforming a single higher order ODE into a system of first order ODEs. Most of the free numerical differential equation solvers I've seen want input in the form y'[x] == f(y,x), so the purpose of a program like this is to take more general input and turn it into something suitable for those routines. snip Thanks for doing this. It is indeed very useful, I always wondered how things like this are done in Mathematica. Any ideas how this could be nicely translated to Python? Ondrej I thought you were going to tell me that sympy already does this. I believe I saw an example somewhere in the docs about matching derivatives, but I couldn't immediately find it again. JM --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage Notebook CSS
Found it. I was missing a div.worksheet_title.
regards
john perry
On Aug 22, 12:00 pm, john_perry_usm [EMAIL PROTECTED] wrote:
Hi,
I've been working with this recently and I'm wondering which CSS tag I
should change for the background color of the table whose id is
topbar. It doesn't have a class assigned to it and for the life of
me I can't find the class that affects it. My CSS is not the best; is
there a generic table class I could modify? The following doesn't seem
to do the trick
table {
background-color: rgb(224,224,224);
}
regards
john perry
On May 27, 9:57 am, William Stein [EMAIL PROTECTED] wrote:
Hi,
I've always wondered why nobody creates nice stylized skins, etc.
for the notebook.
It just occurred to me that though I made it trivial to change the
notebook css on the
fly, nobody knows how. If you would like to make your Sage notebook
look totally
different, here's a quick tutorial (assumes you are not using the
vmware version of
the notebook):
1. See attached screenshot.
2. Start your *own* notebook server running locally on your computer.
3. Make a new file $HOME/.sage/notebook.css with these contents:
textarea.cell_input {
color:#003300;
border: 0px;
font-family: monaco;
}
div.cell_not_evaluated {
border-left: 3px solid #ff;
}
td.cell_number_running {
border-left:20px solid orange;
}
4. Press refresh in your web browser and observe that the above css takes
effect thus changing the style of your notebook.
5. You can change a lot. To get a feel for the options
seehttp://localhost:8000/css/main.css
where 8000 is replaced by whatever port your notebook runs on.
This feature has been in Sage for two years, but I don't think anybody
has ever used it.
-- William
--
William Stein
Associate Professor of Mathematics
University of Washingtonhttp://wstein.org
Picture 2.png
45KViewDownload
On May 27, 9:57 am, William Stein [EMAIL PROTECTED] wrote:
Hi,
I've always wondered why nobody creates nice stylized skins, etc.
for the notebook.
It just occurred to me that though I made it trivial to change the
notebook css on the
fly, nobody knows how. If you would like to make your Sage notebook
look totally
different, here's a quick tutorial (assumes you are not using the
vmware version of
the notebook):
1. See attached screenshot.
2. Start your *own* notebook server running locally on your computer.
3. Make a new file $HOME/.sage/notebook.css with these contents:
textarea.cell_input {
color:#003300;
border: 0px;
font-family: monaco;
}
div.cell_not_evaluated {
border-left: 3px solid #ff;
}
td.cell_number_running {
border-left:20px solid orange;
}
4. Press refresh in your web browser and observe that the above css takes
effect thus changing the style of your notebook.
5. You can change a lot. To get a feel for the options
seehttp://localhost:8000/css/main.css
where 8000 is replaced by whatever port your notebook runs on.
This feature has been in Sage for two years, but I don't think anybody
has ever used it.
-- William
--
William Stein
Associate Professor of Mathematics
University of Washingtonhttp://wstein.org
Picture 2.png
45KViewDownload
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
Thanks for doing this. It is indeed very useful, I always wondered how things like this are done in Mathematica. Any ideas how this could be nicely translated to Python? Ondrej I thought you were going to tell me that sympy already does this. I believe I saw an example somewhere in the docs about matching derivatives, but I couldn't immediately find it again. We have something, but not exactly like in Mathematica. Here is sympy's implementation of deriv_degree http://hg.sympy.org/sympy/file/b4a6e225c34a/sympy/solvers/solvers.py#l377 and here are other examples of matching: http://hg.sympy.org/sympy/file/b4a6e225c34a/sympy/core/tests/test_match.py#l1 E.g. the thing that you were looking for is starting here: http://hg.sympy.org/sympy/file/b4a6e225c34a/sympy/core/tests/test_match.py#l153 some other docs are here: http://docs.sympy.org/tutorial.html#pattern-matching Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: missing imports for experimental module for Sage
On Mon, Aug 25, 2008 at 2:41 PM, David Joyner [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 8:20 AM, Philippe Saade [EMAIL PROTECTED] wrote: nybody give me a hint ? Did you add it to devel/sage/setup.py? No and honestly, i don't fully understand the way that file is structured. If you could give me an example of a line i should add... Sorry to bother Philippe (rem : the classes defined in that module work fine if placed in a notebook cell) Philippe --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage mentioned in American Scientist
On Aug 24, 4:45 pm, iSAGE [EMAIL PROTECTED] wrote: This is exciting news. Just curious about the debian package - it will probably not have many of the optional packages. What will be the procedure to install optional packages then? For example, I am interested in nauty, which I believe is not under GPL. So will it never be in the debian package? I included some of the optional packages already in Debian on the Recommends: line for the sagemath package, so that they will be installed automatically when one installs Sage (but the user can choose not to install them). One should be able to install optional sage spkgs using sage -i (as root) from the Debian installation. -Tim Abbott --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
I still do not understand why giac is not even mentionned in the symbolic discussion considering the fact that like ginac, it is a C++ library, but unlike ginac (Ginac Is Not A Cas), giac (Giac Is A Cas) has much more advanced calculus functions (either functionnalities like limits, integration) and good benchmarks. I thought sage was an effort to build a free alternative to maple or mathematica and that collaboration between projects having this goal would prevail, not competition (how much time lost duplicating the functionnalities already available in giac for pynac?). By the way, I installed in ~parisse on sage the 64 bits binaries version of giac (icas) and xcas so that everybody can test benchmarks. Unfortunately a few system libraries on sage have bad rights, e.g. libstdc++.so.6 is rw instead of rwx, hence one must run export LD_LIBRARY_PATH=~parisse before running ~parisse/icas For example g:=(x+y+z+1)^20; h:=(x-y+2z-2)^20; time(r:=normal(g*h)); time(factor(r)); --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 10:12 AM, parisse [EMAIL PROTECTED] wrote: I still do not understand why giac is not even mentionned in the symbolic discussion considering the fact that like ginac, it is a C++ library, but unlike ginac (Ginac Is Not A Cas), giac (Giac Is A Cas) has much more advanced calculus functions (either functionnalities like limits, integration) and good benchmarks. I thought sage was an effort to build a free alternative to maple or mathematica and that collaboration between projects having this goal would prevail, not competition (how much time lost duplicating the functionnalities already available in giac for pynac?). I can't speak for anyone else (hence I can't really answer your question) but I have had problems compiling giac for amd64 hardy heron. I'm fairly impatient though, and maybe if I tried harder I could have gotten something to compile. I did spend maybe 30 minutes on it and gave up. I also tried installing it on an intel macbook but the package refused to install on my firewire drive. It's actually the first application I've run across which has refused to install on my firewire drive (my tiny HD is full:-). Is it possible to fix this? Can you create a system for which someone using amd64 hardy heron (a very popular distribution) can compile it from source (at least after a specific number of dependencies are installed using apt-get). In other words, can you create the analog of http://modular.math.washington.edu/sage/doc/inst/node5.html ? If so, I'd be happy to test it out. Also, is there any documentation in English? (I mean something more than a 5 page tutorial.) Sorry if I seem to hijack your thread. Actually, giac seems potentially interesting but it is difficult for me to say more. By the way, I installed in ~parisse on sage the 64 bits binaries version of giac (icas) and xcas so that everybody can test benchmarks. Unfortunately a few system libraries on sage have bad rights, e.g. libstdc++.so.6 is rw instead of rwx, hence one must run export LD_LIBRARY_PATH=~parisse before running ~parisse/icas For example g:=(x+y+z+1)^20; h:=(x-y+2z-2)^20; time(r:=normal(g*h)); time(factor(r)); --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
Hi, On Mon, 25 Aug 2008 07:12:27 -0700 (PDT) parisse [EMAIL PROTECTED] wrote: I still do not understand why giac is not even mentionned in the symbolic discussion considering the fact that like ginac, it is a C++ library, but unlike ginac (Ginac Is Not A Cas), giac (Giac Is A Cas) has much more advanced calculus functions (either functionnalities like limits, integration) and good benchmarks. I think the only reason giac is not mentioned in the benchmarks is that it wasn't available. There are already interfaces to MMA and Maple from Sage, so they are easy to time. Sympy and sympycore are already in Python, so no trouble there. GiNaC was easy to build and understand, so I could create packages and write an interface in a matter of hours. There was already an attempt (by Ondrej) to make a package for giac, which is the first step to writing an interface. However, IIRC, it didn't succeed. There is also the question why use GiNaC and not giac as the symbolic arithmetic engine in Sage. The answer lies in the formulation of the question, and the word arithmetic. We already have a pretty good symbolic engine in Sage, maxima does quite a good job of solving integrals, limits, etc. The main problem with Maxima is that we cannot extend it. The situation would be the same if we adopted yet another system, such as giac. The point of the pynac effort (at least from my pov), is to acquire a fast and capable arithmetic and manipulation engine and write the higher level algorithms on top of that. This way Sage can advance from being a user interface to become a research environment. I thought sage was an effort to build a free alternative to maple or mathematica and that collaboration between projects having this goal would prevail, not competition (how much time lost duplicating the functionnalities already available in giac for pynac?). snip Pynac is a modification of GiNaC to use python objects as coefficients in its data types. This was a rather tricky, but well isolated change, since GiNaC already abstracts this functionality into a single class. I don't think this is duplicating any functionality already in giac. Cheers, Burcin --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
I've been trying to get an answer for this question for the last few weeks: Is the plan to extend ginac (write algorithms in C) or to extend sage (write new algorithms in Sage) using cython/python? This is very much a design related question, and in the hurry to get GiNaC through review I feel that design issues and questions have been very much ignored. To put the question somewhat differently, are algorithms using the new symbolics system going to be use GiNaC/pynac enough that switching to any other low level system will be very, very difficult (because new code such as sums may depend directly on GiNaC specific behavior)? If this is not intended, what will be done to try to prevent Sage from becoming overly dependent on GiNaC in the long term? --Bill On Mon, Aug 25, 2008 at 8:24 AM, Burcin Erocal [EMAIL PROTECTED] wrote: Hi, On Mon, 25 Aug 2008 07:12:27 -0700 (PDT) parisse [EMAIL PROTECTED] wrote: I still do not understand why giac is not even mentionned in the symbolic discussion considering the fact that like ginac, it is a C++ library, but unlike ginac (Ginac Is Not A Cas), giac (Giac Is A Cas) has much more advanced calculus functions (either functionnalities like limits, integration) and good benchmarks. I think the only reason giac is not mentioned in the benchmarks is that it wasn't available. There are already interfaces to MMA and Maple from Sage, so they are easy to time. Sympy and sympycore are already in Python, so no trouble there. GiNaC was easy to build and understand, so I could create packages and write an interface in a matter of hours. There was already an attempt (by Ondrej) to make a package for giac, which is the first step to writing an interface. However, IIRC, it didn't succeed. There is also the question why use GiNaC and not giac as the symbolic arithmetic engine in Sage. The answer lies in the formulation of the question, and the word arithmetic. We already have a pretty good symbolic engine in Sage, maxima does quite a good job of solving integrals, limits, etc. The main problem with Maxima is that we cannot extend it. The situation would be the same if we adopted yet another system, such as giac. The point of the pynac effort (at least from my pov), is to acquire a fast and capable arithmetic and manipulation engine and write the higher level algorithms on top of that. This way Sage can advance from being a user interface to become a research environment. I thought sage was an effort to build a free alternative to maple or mathematica and that collaboration between projects having this goal would prevail, not competition (how much time lost duplicating the functionnalities already available in giac for pynac?). snip Pynac is a modification of GiNaC to use python objects as coefficients in its data types. This was a rather tricky, but well isolated change, since GiNaC already abstracts this functionality into a single class. I don't think this is duplicating any functionality already in giac. Cheers, Burcin --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 5:24 PM, Burcin Erocal [EMAIL PROTECTED] wrote: Hi, On Mon, 25 Aug 2008 07:12:27 -0700 (PDT) parisse [EMAIL PROTECTED] wrote: I still do not understand why giac is not even mentionned in the symbolic discussion considering the fact that like ginac, it is a C++ library, but unlike ginac (Ginac Is Not A Cas), giac (Giac Is A Cas) has much more advanced calculus functions (either functionnalities like limits, integration) and good benchmarks. I think the only reason giac is not mentioned in the benchmarks is that it wasn't available. There are already interfaces to MMA and Maple from Sage, so they are easy to time. Sympy and sympycore are already in Python, so no trouble there. GiNaC was easy to build and understand, so I could create packages and write an interface in a matter of hours. There was already an attempt (by Ondrej) to make a package for giac, which is the first step to writing an interface. However, IIRC, it didn't succeed. It did: http://groups.google.com/group/sage-devel/browse_thread/thread/40abd4b2825c0331/ giac builds, but it takes 72, while pynac takes 2 minutes. Also noone has tried to write the Cython wrappers for it, I hoped Bernard would try it, but I really don't have time for this now. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
I can't speak for anyone else (hence I can't really answer your question) but I have had problems compiling giac for amd64 hardy heron. I'm fairly impatient though, and maybe if I tried harder I could have gotten something to compile. I did spend maybe 30 minutes on it and gave up. For a full-featured giac, you will need several packages. That's why I provide binaries. The binaries on sage should work on any amd64 (first install xcas_root.tgz (http://www-fourier.ujf-grenoble.fr/~parisse/ giac/xcas_root.tgz) to have the doc, then unarchive xcas64.tgz (ftp:// ftp-fourier.ujf-grenoble.fr/xcas/xcas64.tgz) in /usr/local/bin). For compilation, get the latest giac_unstable.tgz or try the spkg built by Ondrej which is in my directory on sage (it is up to date and compiles on sage). I also tried installing it on an intel macbook but the package refused to install on my firewire drive. It's actually the first application I've run across which has refused to install on my firewire drive (my tiny HD is full:-). Is it possible to fix this? There is perhaps some problem since a part of the installation goes in /usr/local. You are the first one reporting this and I'm not a mac expert therefore I can't answer right now:-( Can you create a system for which someone using amd64 hardy heron (a very popular distribution) can compile it from source (at least after a specific number of dependencies are installed using apt-get). In other words, can you create the analog ofhttp://modular.math.washington.edu/sage/doc/inst/node5.html? The INSTALL file from the source should help you compile giac. Where does it fail for you? If so, I'd be happy to test it out. Also, is there any documentation in English? (I mean something more than a 5 page tutorial.) There is a user guide in English for the xcas application. http://www-fourier.ujf-grenoble.fr/~parisse/giac/doc/en/casref_en/casref_en.html and a very short introduction on how to program with giac http://www-fourier.ujf-grenoble.fr/~parisse/giac_us.html --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] GIAC
On Monday 25 August 2008, parisse wrote: I still do not understand why giac is not even mentionned in the symbolic discussion considering the fact that like ginac, it is a C++ library, but unlike ginac (Ginac Is Not A Cas), giac (Giac Is A Cas) has much more advanced calculus functions (either functionnalities like limits, integration) and good benchmarks. I thought sage was an effort to build a free alternative to maple or mathematica and that collaboration between projects having this goal would prevail, not competition (how much time lost duplicating the functionnalities already available in giac for pynac?). By the way, I installed in ~parisse on sage the 64 bits binaries version of giac (icas) and xcas so that everybody can test benchmarks. Unfortunately a few system libraries on sage have bad rights, e.g. libstdc++.so.6 is rw instead of rwx, hence one must run export LD_LIBRARY_PATH=~parisse before running ~parisse/icas For example g:=(x+y+z+1)^20; h:=(x-y+2z-2)^20; time(r:=normal(g*h)); time(factor(r)); Hi there, I totally agree with you that it is annoying that your e-mails don't get addressed properly. Thus, I'm answering however I don't really use symbolics, so my expertice is very limited in that area. The official guidelines for inclusion of new packages are: = License = GPL version 2+ compatible license. (This will be publicly revisited around Jan 15, 2009.) GIAC seems to be GPL v3+ according to Michael Abshoff? = Build Support = The package must build on our supported architectures and compilers [and intended port targets]: * Linux: x86, x86_64, Itanium, ppc, ppc64, Sparc (gcc 3.4-4.3) * Apple Mac OS X: ppc, ppc64, x86, x86-64 (Xcode 2.5+) * Microsoft Windows: x86, x86_64 MSVC 2005/Intel Fortran [MinGW or Cygwin * support is insufficient!] * Solaris 10: Sparc, x86, x86_64 (Sun Forte 12) Remarks: Some Sage developers are willing to help you port to OSX, Solaris and Windows. But this is no guarantee and you or your project are expected to do the heavy lifting and also support those ports upstream if there is no Sage developer who is willing to share the burden. Potential future ports: FreeBSD: x86, x86-64 OpenBSD: x86, x86-64 HPUX: Itanium AIX: PPC64 ARM: OSX As far as I know there were a couple of build issues with GIAC in the past. But you replied fast to any issue brought up on this list. Michael Abshoff wrote about this on [sage-devel]: The code doesn't seem to have MSVC support and due to its size the size/benefit ratio doesn't look good. Since I will likely end up porting the code I am not too excited to have to deal with another 150k lines of code. I am not aware of any build issue with GINAC because I never tried. However, it seems that this issue was not addressed in William's proposal. William, can you clarify where you tried to build GINAC and how it worked? Also, since MSVC support is now a *requirement*, does Pynac compile with MSVC? Quality The package should be better than anything else (that passes the two above criteria) and an argument should be made for this. The comparison should be made to both Python and other software. Criteria in passing the quality test include: Speed As far as I understand it there is an issue defining what Speed is in that context. But both Ginac and Giac seem to do well overall. Someone else needs to address this in more detail Documentation Ginac seems to be fairly well documented from what I gather: Tutorial, reference manual. Same goes for Giac which also seems to have a tutorial and a reference manual. This seems to be focused on Xcas though, which is not what Sage could use. Is there any C++ level reference manual? Michael Abshoff wrote about this: The code is sparingly commented and seems to conform to its own coding style. We specifically looked at the Risch code and also infrastructure like vecteur - this is really a big issue since dealing with sparingly documented code in the past had proven to be a huge pain in case we had to fix bugs Usability I have no clue. However, Ginac seems to be extendible since it is designed as a C++ library rather than a full system. Libraries are obviously better for Sage since they are easier to integrate. Memory leaks No clue. Maintainable That seems to be an issue, since people complaint about the lack of code documentation, module separation and so on for Giac. I'm just repeating what others said already on this list, I personally never tried. Also Giac comes with a lot of stuff that is already in Sage, while Ginac only does stuff that is not there yet (fast symbolic arithmetic) Reasonable build time, size, dependencies Ondrej reported that building Giac required 72 minutes on sage.math which is way too long. Ginac builds in up to 6 minutes. Also Giac seems much larger than Ginac. Voting JSAGE vote (majority) A certain number of sage-devel +1 votes (and sage-support votes) Every spkg
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 4:59 AM, William Stein [EMAIL PROTECTED] wrote: Hi, I propose that pynac be included in Sage. VOTE: [ ] Yes, include Pynac in Sage [ ] No, do not (please explain) [ ] Hmm, I have questions (please ask). I have a question: what will happen to gfurnish's work? Is it going to be completely abandoned? didier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: 3 edits - [Re: [sage-devel] trivial typo on Help and Support page]
Hi Harald, On Sat, Aug 23, 2008 at 11:50 AM, Harald Schilly [EMAIL PROTECTED] wrote: This is a typo for you to fix... thx for the proofreading. I've uploaded your changes. Still a typo at the URL: http://www.sagemath.org/download.html The very last bold heading at the bottom of that page reads Utilites. I think you've only fixed the second occurrence of the typo utilites, but not the first occurrence. The diff below fixes the first occurrence of utilites: - Utilites Useful utilities when working with Sage + Utilities Useful utilities when working with Sage -- Regards Minh Van Nguyen Web: http://nguyenminh2.googlepages.com Blog: http://mvngu.wordpress.com --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GIAC
The official guidelines for inclusion of new packages are: = License = GPL version 2+ compatible license. (This will be publicly revisited around Jan 15, 2009.) GIAC seems to be GPL v3+ according to Michael Abshoff? I can re-license it to GPL 2 (maybe some optional libraries should not be linked with). As far as I understand it there is an issue defining what Speed is in that context. But both Ginac and Giac seem to do well overall. Someone else needs to address this in more detail It all depends on what you are benchmarking. For basic arithmetic, ginac and giac are probably on the same scale. I did not try ginac recently, but I don't think they have for example a modular GCD algorithm, they rely on heuristic GCD and subresultant. Documentation Ginac seems to be fairly well documented from what I gather: Tutorial, reference manual. Same goes for Giac which also seems to have a tutorial and a reference manual. This seems to be focused on Xcas though, which is not what Sage could use. Is there any C++ level reference manual? See above, there is a short introduction on how the library may be used. The user guide is focused on Xcas since that's where users currently are. It is anyway useful for writing code using giac, since (almost) every xcas function has an equivalent giac function with the same name + an initial _ and the same arguments (groupped in a vector) and sometimes a context argument (for thread-safe parallel execution). I'm waiting for interested contributors before writing a more complete guide. Usability I have no clue. However, Ginac seems to be extendible since it is designed as a C++ library rather than a full system. Libraries are obviously better for Sage since they are easier to integrate. Giac is also a C++ library unlike maxima or axiom. Also Giac comes with a lot of stuff that is already in Sage, while Ginac only does stuff that is not there yet (fast symbolic arithmetic) ??? What do you mean by fast symbolic arithmetic? Ginac does basic fast symbolic arithmetic (+,*), Giac does in addition gcd, factor, integration, etc. Of course, maxima or axiom can be called from inside sage to do these kinds of computations, but they will not benefit from speed or functionnality improvements from other libraries (e.g. maxima will not benefit from the inclusion of ginac or NTL or whatever will be in sage). Dismissing giac means that some sage developers will take time and efforts to duplicate what's already in giac from the ginac base. Ondrej reported that building Giac required 72 minutes on sage.math which is way too long. Ginac builds in up to 6 minutes. Also Giac seems much larger than Ginac. Of course, giac is much larger since it has much more calculus features. It is indeed long to build with -O2 but with -g it is about 10mn or less. I never build with -O2 for development, only for distributing final binaries. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
Also noone has tried to write the Cython wrappers for it, I hoped Bernard would try it, but I really don't have time for this now. Ondrej I don't have the time right now to learn how to write Cython wrappers. Unfortunately I may end up being obliged (once again) to do it myself to attract python developpers:-( It will most probably not be as good as if a true python developers write one. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GIAC
Also Giac comes with a lot of stuff that is already in Sage, while Ginac only does stuff that is not there yet (fast symbolic arithmetic) ??? What do you mean by fast symbolic arithmetic? Ginac does basic fast symbolic arithmetic (+,*), Giac does in addition gcd, factor, integration, etc. Of course, maxima or axiom can be called from inside sage to do these kinds of computations, but they will not benefit from speed or functionnality improvements from other libraries (e.g. maxima will not benefit from the inclusion of ginac or NTL or whatever will be in sage). Dismissing giac means that some sage developers will take time and efforts to duplicate what's already in giac from the ginac base. I meant stuff like this: Installing the required libraries from source (recommended) * CoCoA 0.99 (for faster Groebner basis). Sage already has faster Groebner bases since it included Singular. There is a lot of stuff like that in Xcas/Giac like that Sage already has. This makes sense since Giac/Xcas is a stand-alone system just like Sage. Ondrej reported that building Giac required 72 minutes on sage.math which is way too long. Ginac builds in up to 6 minutes. Also Giac seems much larger than Ginac. Of course, giac is much larger since it has much more calculus features. It is indeed long to build with -O2 but with -g it is about 10mn or less. I never build with -O2 for development, only for distributing final binaries. Sage is built from source by many people. One of the design goals was to enable each end user easily to contribute and thus there is no such stark distinction between development and final binaries. This might change eventually, but a build time of 72 minutes seems way too long. Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Templating engine for the Notebook
On Mon, Aug 25, 2008 at 4:39 AM, Timothy Clemans [EMAIL PROTECTED] wrote: Hi, Regarding the Sage Notebook, I propose that we use a templating engine instead of using Python string templates class and writing HTML code in the Python code. I have converted the existing templates in Extcode to templates that use the Jinja engine, see http://trac.sagemath.org/sage_trac/ticket/3923. I also moved the HTML for the Account Settings page to a Jinja template, see http://trac.sagemath.org/sage_trac/ticket/3937. Timothy, I strongly support your proposal to use Jinja to template the HTML generation code for the Sage notebook. Go for it! William I think using Jinja makes the Python code more readable. In addition, I like be able to create a base template that other templates build upon. Plus it's nice to be able to use for loops and if statements in the templates. I use both in the templates at the two tickets. Jinja is a clone of the templating engine used in the most popular Python web framework Django. I am very interested in the possibility of migrating the Sage Notebook to Django. Moving all the Notebook's HTML to Jinja templates is the first step in migrating. If Sphinx, a documentation system, is distributed with Sage then Jinja would also be. See the sage-devel thread Sphinx and the Sage Documentation at http://groups.google.com/group/sage-devel/browse_thread/thread/7b0b2f0b34f1f892/ Timothy -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: missing imports for experimental module for Sage
On Mon, Aug 25, 2008 at 5:41 AM, David Joyner [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 8:20 AM, Philippe Saade [EMAIL PROTECTED] wrote: Hi, i'am testing a Python module i wrote and placed it in one of the pathes visited by Sage's Python while importing. I try to do the necessary imports at the beginning of my module but it seem's to be an endless quest. What do you think the necessary imports are? Could you be way more precise? I am not an experienced Python user. Can anybody give me a hint ? Did you add it to devel/sage/setup.py? (rem : the classes defined in that module work fine if placed in a notebook cell) Philippe -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
On Mon, Aug 25, 2008 at 4:47 AM, Burcin Erocal [EMAIL PROTECTED] wrote:
On Sun, 24 Aug 2008 15:55:25 -0700 (PDT)
Jason Merrill [EMAIL PROTECTED] wrote:
In hopes that it may be a useful reference during the current work on
symbolics, I wrote a toy Mathematica program for transforming a single
higher order ODE into a system of first order ODEs. Most of the free
numerical differential equation solvers I've seen want input in the
form y'[x] == f(y,x), so the purpose of a program like this is to take
more general input and turn it into something suitable for those
routines.
snip
Thank you for taking the time to write this. It is very useful indeed.
The interface to pynac (William's modified version of GiNaC) doesn't
support pattern matching yet, though it is not hard to add this. I'll
add this functionality and try to reproduce your example in Sage once I
finish reviewing the initial pynac interface patches (#3872).
Burcin -- I did actually mostly implement pattern matching in Pynac.
Some examples:
sage: var('x,y,z,a,b,c,d,e,f',ns=1); S = parent(x)
(x, y, z, a, b, c, d, e, f)
sage: w0 = S.wild(0); w1 = S.wild(1); w2 = S.wild(2)
sage: ((x+y)^a).match((x+y)^a)
True
sage: ((x+y)^a).match((x+y)^b)
False
sage: (a^2 + b^2 + (x+y)^2).subs(w0^2 == w0^3)
(x + y)^3 + a^3 + b^3
sage: (a^4 + b^4 + (x+y)^4).subs(w0^2 == w0^3)
(x + y)^4 + a^4 + b^4
sage: (a^2 + b^4 + (x+y)^4).subs(w0^2 == w0^3)
(x + y)^4 + a^3 + b^4
sage: ((a+b+c)^2).subs(a+b==x)
(a + b + c)^2
sage: ((a+b+c)^2).subs(a+b+w0==x+w0)
(c + x)^2
sage: (a+2*b).subs(a+b==x)
a + 2*b
sage: (a+2*b).subs(a+b+w0 == x+w0)
a + 2*b
sage: (a+2*b).subs(a+w0*b == x)
x
sage: (a+2*b).subs(a+b+w0*b == x+w0*b)
a + 2*b
sage: (4*x^3-2*x^2+5*x-1).subs(x==a)
4*a^3 - 2*a^2 + 5*a - 1
sage: (4*x^3-2*x^2+5*x-1).subs(x^w0==a^w0)
4*a^3 - 2*a^2 + 5*x - 1
sage: (4*x^3-2*x^2+5*x-1).subs(x^w0==a^(2*w0)).subs(x==a)
4*a^6 - 2*a^4 + 5*a - 1
sage: sin(1+sin(x)).subs(sin(w0)==cos(w0))
cos(cos(x) + 1)
sage: (sin(x)^2 + cos(x)^2).subs(sin(w0)^2+cos(w0)^2==1)
1
sage: (1 + sin(x)^2 + cos(x)^2).subs(sin(w0)^2+cos(w0)^2==1)
sin(x)^2 + cos(x)^2 + 1
sage: (17*x + sin(x)^2 + cos(x)^2).subs(w1 +
sin(w0)^2+cos(w0)^2 == w1 + 1)
17*x + 1
sage: ((x-1)*(sin(x)^2 + cos(x)^2)^2).subs(sin(w0)^2+cos(w0)^2 == 1)
x - 1
Cheers,
Burcin
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
On Mon, Aug 25, 2008 at 5:56 AM, Jason Merrill [EMAIL PROTECTED] wrote:
On Aug 25, 7:46 am, Ondrej Certik [EMAIL PROTECTED] wrote:
On Mon, Aug 25, 2008 at 12:55 AM, Jason Merrill [EMAIL PROTECTED] wrote:
In hopes that it may be a useful reference during the current work on
symbolics, I wrote a toy Mathematica program for transforming a single
higher order ODE into a system of first order ODEs. Most of the free
numerical differential equation solvers I've seen want input in the
form y'[x] == f(y,x), so the purpose of a program like this is to take
more general input and turn it into something suitable for those
routines.
snip
Thanks for doing this. It is indeed very useful, I always wondered how
things like this are done in Mathematica.
Any ideas how this could be nicely translated to Python?
Ondrej
I thought you were going to tell me that sympy already does this. I
believe I saw an example somewhere in the docs about matching
derivatives, but I couldn't immediately find it again.
The new pynac code referred to elsewhere does this. See the example below:
sage: from sage.symbolic.function import function
sage: var('r,kappa', ns=1)
(r, kappa)
sage: psi = function('psi', 1)(r); psi
psi(r)
sage: g = 1/r^2*(2*r*psi.diff(r,1) + r^2*psi.diff(r,2)); g
(2*psi(1,r)*r + psi(2,r)*r^2)*r^(-2)
sage: g.expand()
psi(2,r) + 2*psi(1,r)*r^(-1)
sage: g.coeff(psi.diff(r,2))
1
sage: g.coeff(psi.diff(r,1))
2*r^(-1)
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Templating engine for the Notebook
On Aug 25, 4:39 am, Timothy Clemans [EMAIL PROTECTED] wrote: Hi, Regarding the Sage Notebook, I propose that we use a templating engine instead of using Python string templates class and writing HTML code in the Python code. I think this is a great idea. If Sphinx, a documentation system, is distributed with Sage then Jinja would also be. See the sage-devel thread Sphinx and the Sage Documentation athttp://groups.google.com/group/sage-devel/browse_thread/thread/7b0b2f... Unfortunately, Sphinx uses the original Jinja and you're using Jinja2; one of these will presumably have to change. (I like the idea of using Jinja2, which is billed as Jinja1 without the design mistakes; I don't know how hard it would be to change Sphinx to use Jinja2.) Carl --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Knoboo-devel] Templating engine for the Notebook
On Mon, Aug 25, 2008 at 4:39 AM, Timothy Clemans [EMAIL PROTECTED] wrote: Hi, Regarding the Sage Notebook, I propose that we use a templating engine instead of using Python string templates class and writing HTML code in the Python code. I have converted the existing templates in Extcode to templates that use the Jinja engine, see http://trac.sagemath.org/sage_trac/ticket/3923. I also moved the HTML for the Account Settings page to a Jinja template, see http://trac.sagemath.org/sage_trac/ticket/3937. I think using Jinja makes the Python code more readable. In addition, I like be able to create a base template that other templates build upon. Plus it's nice to be able to use for loops and if statements in the templates. I use both in the templates at the two tickets. Jinja is a clone of the templating engine used in the most popular Python web framework Django. I am very interested in the possibility of migrating the Sage Notebook to Django. This is something that I have considered a bit. Django has a lot of good stuff for templating, a good ORM, and the admin interface is seriously amazing. One argument against using Django for the notebook is that you might end up trying to code around a bunch of the abstractions that Django puts on top of what is really going on. Either way, this is definitely something to consider, because in my experience, Django is really good at what it does. -Alex Moving all the Notebook's HTML to Jinja templates is the first step in migrating. If Sphinx, a documentation system, is distributed with Sage then Jinja would also be. See the sage-devel thread Sphinx and the Sage Documentation at http://groups.google.com/group/sage-devel/browse_thread/thread/7b0b2f0b34f1f892/ Timothy --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Problem building sage 3.1 on Debian lenny amd 64
On Aug 25, 1:45 am, Thierry Dumont [EMAIL PROTECTED] wrote: Hi, Hi, I try to compile sage on my opteron machine. When compiling flint, I get the ld error message: /usr/bin/ld: cannot find -lstdc++ Th ld lines are: g++ -I/usr/local/sage-3.1/local/include/ -I/usr/local/sage-3.1/local/include -f PIC -funroll-loops -O3 -c NTL-interface.cpp -o NTL-interface.o gcc -std=c99 -fPIC -shared -Wl,-soname,lib`cat DIRNAME`.so -o lib`cat DIRNAME`.s o mpn_extras.o mpz_extras.o memory-manager.o ZmodF.o ZmodF_mul.o ZmodF_mul-tunin g.o fmpz.o fmpz_poly.o mpz_poly-tuning.o mpz_poly.o ZmodF_poly.o long_extras.o z mod_poly.o NTL-interface.o -L/usr/local/sage-3.1/local/lib/ -L/usr/local/sage-3.1/local/lib/ -lgmp -lpthread -lntl -lm -lstdc++ and so, we certainly try to find a libstdc++ in /usr/local/sage-3.1/local/lib/ and, actually, there is non stl lib installed there. The stl lib is system wide installed Odd to say the least and I am not sure why we even need to link libstdc ++ explicitly here. I assume your C++ compiler works since at that point we have already build NTL. libstdc++.so should be automatically picked up the compiler. To fix this I would remove that linker directive from FLINT. Does Lenny ship with gcc 4.3.1 or did you compile the compiler itself? yours t. Cheers, Michael tdumont.vcf 1KViewDownload smime.p7s 5KViewDownload --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 7:12 AM, parisse [EMAIL PROTECTED] wrote: I still do not understand why giac is not even mentionned in the symbolic discussion considering the fact that like ginac, it is a C++ I was able to very quickly get a good understanding of the Ginac codebase, and make fundamental changes that allowed me to modify it to work at its core throughout with Python objects instead of CLN. Every single question I have had about Ginac I have literally been able to answer for myself in minutes by reading the source code. And when I change things in Ginac I can rebuild the whole system in just over a minute. My experience with Giac is that: (a) I can't build it, (b) even on systems where I could, I'm not patient enough, and (c) looking at the source code from the point of view of doing what I want makes me dizzy and I get nowhere, (d) and Giac is HUGE -- about five times the size of Ginac, and much of that code in Giac overlaps with what Sage already does, and (e) my technical build guy tells me that Giac isn't a model of super high quality code. So to me Giac cannot solve any of our problems today, unless we want Sage to be bloated, and we want to take months or years rather than a few days to get this stuff done. Perhaps I could take code from Giac, e.g., for limits or symbolic integration, but (a) you're using GPLv3, so I can't, and (b) probably that would make you unhappy anyways, and (c) I would rather such functionality comes from the sympy project, since that is in Python. By the way, I installed in ~parisse on sage the 64 bits binaries version of giac (icas) and xcas so that everybody can test benchmarks. Unfortunately a few system libraries on sage have bad rights, e.g. libstdc++.so.6 is rw instead of rwx, hence one must run export LD_LIBRARY_PATH=~parisse before running ~parisse/icas For example g:=(x+y+z+1)^20; h:=(x-y+2z-2)^20; time(r:=normal(g*h)); Wow, that particular synthetic benchmark is really fast in Giac. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 8:54 AM, didier deshommes [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 4:59 AM, William Stein [EMAIL PROTECTED] wrote: Hi, I propose that pynac be included in Sage. VOTE: [ ] Yes, include Pynac in Sage [ ] No, do not (please explain) [ ] Hmm, I have questions (please ask). I have a question: what will happen to gfurnish's work? Is it going to be completely abandoned? If he clearly licenses it under GPLv2+ then hopefully it won't be, and somebody will find ways to use it. gfurnish -- are you willing to post a version of all your code with GPLv2+ headers? -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GIAC
On Mon, Aug 25, 2008 at 9:23 AM, parisse [EMAIL PROTECTED] wrote: The official guidelines for inclusion of new packages are: = License = GPL version 2+ compatible license. (This will be publicly revisited around Jan 15, 2009.) GIAC seems to be GPL v3+ according to Michael Abshoff? I can re-license it to GPL 2 (maybe some optional libraries should not be linked with). As far as I understand it there is an issue defining what Speed is in that context. But both Ginac and Giac seem to do well overall. Someone else needs to address this in more detail It all depends on what you are benchmarking. For basic arithmetic, ginac and giac are probably on the same scale. I did not try ginac recently, but I don't think they have for example a modular GCD algorithm, they rely on heuristic GCD and subresultant. I have already looked at the gcd algorithm in Ginac, and it would be easy to completely replace it by calls to Singular, so we could completely eliminate the GCD (etc.) code from pynac. In any case, we're using Ginac almost entirely as a foundation for fast basic arithmetic, and for not much else. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 8:35 AM, Gary Furnish [EMAIL PROTECTED] wrote: I've been trying to get an answer for this question for the last few weeks: Is the plan to extend ginac (write algorithms in C) or to extend sage (write new algorithms in Sage) using cython/python? The plan is definitely to extend sage (write new algorithms in Sage) using cython/python. To put the question somewhat differently, are algorithms using the new symbolics system going to be use GiNaC/pynac enough that switching to any other low level system will be very, very difficult (because new code such as sums may depend directly on GiNaC specific behavior)? Probably not. If this is not intended, what will be done to try to prevent Sage from becoming overly dependent on GiNaC in the long term? Make it so sympy also runs on top of GiNaC. This will force the creation of a clear interface specification. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: missing imports for experimental module for Sage
On Mon, Aug 25, 2008 at 6:45 PM, William Stein [EMAIL PROTECTED] wrote: i'am testing a Python module i wrote and placed it in one of the pathes visited by Sage's Python while importing. I try to do the necessary imports at the beginning of my module but it seem's to be an endless quest. What do you think the necessary imports are? Could you be way more precise? I wrote few classes to plot graphs in a special way. All the code worked fine if placed in a cell at the beginning of the worksheet. As far as it makes a very long cell, it is boring for the reader so i thought i could place all this in an external file and use : from FooBar import * but, naturally, the Sage commands i use in that file are unkown in the Module namespace. I started adding many import statements, one for each unknown command. But vector computation seemed to be needing a lot of imports. That's why i'am asking for advice. (and if it sounds like support, i am again on the wrong list...:-[) Philippe --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 2:42 AM, Ondrej Certik [EMAIL PROTECTED] wrote: VOTE: [ ] Yes, include Pynac in Sage [ ] No, do not (please explain) [ ] Hmm, I have questions (please ask). I don't know if my vote counts, but I am of course +1. Your vote counts. Thanks for pioneering the use of Python in C projects, I hope people will now try much more to reuse C/C++ code. (e) how does this relate to sympy? (I dont' know. Sympy does several things Ginac doesn't, such as symbolic integration and sophisticated limits. I would like to find a way to somehow reuse that code directly, especially since sympy is in sage already, and is already often better than using Sage's current maxima + pexpect symbolic manipulation. On the other hand, Burcin is I think driven mostly by his Ph.D. thesis research, and has told me he will only write GPL'd code, which means it can't go into Sympy.) I think porting the limits is quite easy, but unfortunately ginac series expansion is not sophisticated enough for more complicated limits (at least last time I tried, it was I think 2 years ago), so you will have to port the sympy's series expansion as well, or improve ginac series expansion. Or hopefully find a way to just directly use sympy's series expansion code? Could you give an example to illustrate where you maybe found shortcomings in Ginac's series code? It's pretty straightforward code for the most part, and I don't know how it could go wrong. As to integration, that will be I think a little more difficult to port, but definitely doable as well. By port I will take it to mean improve sympy so it can manipulate Pynac symbolic expressions in addition to its own. I.e., it's basically a duck typing thing, where as long as Pynac exports the right interface, sympy should be able to work with it. As to GPL vs BSD, I am sad that some people will not contribute to a BSD project and some other people will not use a GPL project. But my intuition says that the license is not the main reason. If sympy was as fast as ginac (as I hope it will be in not so distant future), I am sure it'd be ok, even if it's BSD. BTW, I told Burcin and William that if the license was the only reason, I am willing to consider switching to GPL (i.e. try to persuade all 44+ contributors), if that would mean more people would be developing sympy. Currently it seems to be the opposite, i.e. when we switched from GPL to BSD, people and developers seemed to like it, but I may well be mistaken. But as I said, I think the main problem of sympy is not the license, but speed. The GPL/BSD split in the mathematical Python community is unfortunate and a is very real problem. At scipy'08 it was the source of tension for some people... I myself like the way sympy is designed, e.g. pure python + now we are working on the Cython core (+possibly pynac if it's a better alternative, even though some sympy developers seems to prefer pure Cython solution if we can made it as fast as pynac), Why not both? Having the option of multiple pluggable cores is probably the best way to do a good job designing the right interface for the core. The only option for sympy is both or no pynac, since pynac is GPL'd (as was decided by the Ginac developers long ago). So I can imagine some sympy users using pynac as the core because it is maybe better for large problems, and other users using csympycore or something, because it is BSD licensed. Yet others would use the purepython core for portability (e.g., me on my cell phone ;-) ). because that allows to use sympy easily in the google app engine, hopefully soon in pypy and jython, and also as a compiled library when we get the core in with exactly the same interface, i.e., whenever there is python, it should work on it. On the other hand, if you are willing to release and maintain pynac outside sage, so that it's easy to use and basically implement or port all sympy to it, I'll be more than happy that someone else will do my job and I can move to do some more advanced things. I really don't want to have two codebases for the same thing. I definitely want to have a version of pynac outside sage. But keep in mind again that pynac is GPL'd, and given your mission statement for sympy, I think it is not an option for you to depend only on something GPL'd as the only option. As I see it, an important part of the sympy mission is to be the CAS for the we will only use BSD'd code side of the Python math software world, which is a very substantial important and well funded group of people. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org
[sage-devel] Re: GIAC
I meant stuff like this: Installing the required libraries from source (recommended) * CoCoA 0.99 (for faster Groebner basis). Sage already has faster Groebner bases since it included Singular. There is a lot of stuff like that in Xcas/Giac like that Sage already has. This makes sense since Giac/Xcas is a stand-alone system just like Sage. This is not a part of giac, it is an optional external library that is linked in giac. There are other parts of giac that might be interesting for sage or are fast inside giac. Like gcd, limit, integration, contexts... Sage is built from source by many people. One of the design goals was to enable each end user easily to contribute and thus there is no such stark distinction between development and final binaries. This might change eventually, but a build time of 72 minutes seems way too long. I don't see why it's a problem if the spkg_install script specifies CXXFLAGS=-g so that it compiles without optimization in less than 10 minutes by default. If you develop around giac, you will most likely want to use gdb, hence -O2 is bad even with -g. Optimization is only required from time to time when one needs to make benchmarks. Re: William My experience with Giac is that: (a) I can't build it, (b) even on systems where I could, I'm not patient enough, and (c) looking at the source code from the point of view of doing what I want makes me dizzy and I get nowhere, (d) and Giac is HUGE -- about five times the size of Ginac, and much of that code in Giac overlaps with what Sage already does, and (e) my technical build guy tells me that Giac isn't a model of super high quality code. (a) and (b) are bad excuses, since there is a spkg. (c) Did you first look at the giac.info page? (d) Yes, giac/xcas is large (maybe 100K lines for giac, you don't have to look at the interface code), but that's the price to have a CAS! (e) Perhaps. From my own experience, it is not easy to enter into a large library (e.g. cocoa, pari, etc.). So to me Giac cannot solve any of our problems today, unless we want Sage to be bloated, and we want to take months or years rather than a few days to get this stuff done. I can't believe it would take years to make sage and giac interoperate. Even if it take months, that should be compared to the time required to get the same level of functionnalities at a comparable speed over ginac. Perhaps I could take code from Giac, e.g., for limits or symbolic integration, but (a) you're using GPLv3, so I can't, and (b) probably that would make you unhappy anyways, and (c) I would rather such functionality comes from the sympy project, since that is in Python. (a) is not recevable since I could relicense it to GPL v2. Anyway, it is highly improbable that you could take code slices without taking almost all of the library. Higher level code depends on the low level routines and data structures (e.g. rational fraction integration from multivariate polynoms) + many parts are interconnected (e.g. integration requires linear algebra) which BTW makes modularization difficult. Ok, it's probably time lost for both parts, I'm afraid I won't convince you to use giac and you will certainly not convince me to abandon giac in favor of re-developing over ginac or inside sympy (which I find interesting, I wonder how the speed problem will be fixed). The real fight should be with closed-source systems. I will keep looking at symbolic threads, it's always interesting to test examples and benchmarks. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] small bug in multivariate comparison
Do people agree that the first False should be True?
{{{
sage: x, y = QQ['x', 'y'].gens()
sage: R.x, y = QQ[]
sage: (x / y)*y in R
False
sage: R((x / y)*y) == x
True
sage: R((x / y)*y) == (x/y)*y
True
}}}
For comparison:
{{{
sage: (2 / 3)*3 in ZZ
True
}}}
Nick
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] trac report for Tickets in which I have participated
Is there an easy way to create a trac report that lists all the tickets in which I have participated (e.g., created, commented on, in the CC list, am the editor, etc.). For me, this would serve as a Tickets on which I should follow up report... This request is trac ticket #3951 Thanks, Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
sage: from sage.symbolic.function import function
sage: var('r,kappa', ns=1)
(r, kappa)
sage: psi = function('psi', 1)(r); psi
psi(r)
sage: g = 1/r^2*(2*r*psi.diff(r,1) + r^2*psi.diff(r,2)); g
(2*psi(1,r)*r + psi(2,r)*r^2)*r^(-2)
sage: g.expand()
psi(2,r) + 2*psi(1,r)*r^(-1)
sage: g.coeff(psi.diff(r,2))
1
sage: g.coeff(psi.diff(r,1))
2*r^(-1)
I implemented the same interface to sympy:
http://code.google.com/p/sympy/issues/detail?id=979
In [1]: var('r, kappa')
Out[1]: (r, κ)
In [2]: psi = Function(psi)
In [3]: g = 1/r**2 * (2*r*psi(r).diff(r, 1) + r**2 * psi(r).diff(r, 2))
In [4]: g.coeff(psi(r).diff(r))
Out[4]:
2
─
r
In [5]: g.coeff(psi(r).diff(r, 2))
Out[5]: 1
It will be in the next release.
Ondrej
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Comparing complex numbers
On Aug 24, 12:02 pm, William Stein [EMAIL PROTECTED] wrote: [...] Just as another data point, since I happened to see it when reading source code, in the Ginac library (http://www.ginac.de) we find this comment: /** This method establishes a canonical order on all numbers. For complex * numbers this is not possible in a mathematically consistent way but we need * to establish some order and it ought to be fast. So we simply define it * to be compatible with our method csgn. [...] /pedantic ON It is, of course, possible to establish a total ordering on the complex numbers. In many ways. So it is not true to say otherwise. The issue is that cryptic phrase, in a mathematically consistent way. If all you are interested in is, say, topology, then every total ordering gives you an order topology on the set. Nothing mathematically inconsistent in this context. What is usually meant by the phrase is that one cannot have a total ordering on the complex numbers that simultaneously preserves the full range of cherished properties, including the algebraic ones, that we know and love about the usual ordering of the reals. For example, that the order on the complex numbers be an extension of the natural ordering of the reals, that ((0 a) and (0 b)) implies (0 ab), that the order topology be the same as that induced by the usual Euclidean metric, etc. /pedantic OFF Whether this last context is the appropriate one to drive the issue of whether there should be a default order implemented for complex numbers in Sage (or even Python, for that matter) is debatable. IMHO, if it is useful to programming to have a default comparison, such as for sorting lists, then I think it would be OK to have one. Document what it does, and if necessary, explain to your students the reason for it. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
Make it so sympy also runs on top of GiNaC. This will force the creation of a clear interface specification. If there is going to be a clear interface spec, then we should go and make a clear interface spec so that anyone, not just GiNaC can potentially conform to it. Perhaps this is the best long term solution? My symbolics code is already GPLv2+ so fixing the headers is just a technicality. On Mon, Aug 25, 2008 at 10:24 AM, William Stein [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 8:54 AM, didier deshommes [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 4:59 AM, William Stein [EMAIL PROTECTED] wrote: Hi, I propose that pynac be included in Sage. VOTE: [ ] Yes, include Pynac in Sage [ ] No, do not (please explain) [ ] Hmm, I have questions (please ask). I have a question: what will happen to gfurnish's work? Is it going to be completely abandoned? If he clearly licenses it under GPLv2+ then hopefully it won't be, and somebody will find ways to use it. gfurnish -- are you willing to post a version of all your code with GPLv2+ headers? -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: small bug in multivariate comparison
On Aug 25, 12:28 pm, Nick Alexander [EMAIL PROTECTED] wrote:
Do people agree that the first False should be True?
{{{
sage: x, y = QQ['x', 'y'].gens()
sage: R.x, y = QQ[]
sage: (x / y)*y in R
False
sage: R((x / y)*y) == x
True
sage: R((x / y)*y) == (x/y)*y
True
}}}
Yes.
Probably the fix is to just remove the __contains__ method from
multi_polynomial_ring_generic.pyx, so that the generic implementation
is used.
Carl
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: [sympy] Re: [sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
I think porting the limits is quite easy, but unfortunately ginac series expansion is not sophisticated enough for more complicated limits (at least last time I tried, it was I think 2 years ago), so you will have to port the sympy's series expansion as well, or improve ginac series expansion. Or hopefully find a way to just directly use sympy's series expansion code? I hope so too, see below. Could you give an example to illustrate where you maybe found shortcomings in Ginac's series code? It's pretty straightforward code for the most part, and I don't know how it could go wrong. Basically any more complicated limit. I put a print statement in sympy to print the series that needs to work: In [1]: limit(sqrt(x)/sqrt(x+sqrt(x+sqrt(x))),x,oo) 1/(((1/_w + _w**(-1/2))**(1/2) + 1/_w)**(1/2)*_w**(1/2)) _w Out[1]: 1 So you can try it in sympy: In [2]: e = sympify(1/(((1/_w + _w**(-1/2))**(1/2) + 1/_w)**(1/2)*_w**(1/2))) In [9]: e Out[9]: 1 ── ⎽ ╱ ⎽ ╱ ╱ 1 1 1 ╲╱ _w ⋅ ╱ ╱ ── + ── + ── ╱ ╱ _w _w ╲╱ ╲╱ ╲╱ _w In [5]: var(_w) Out[5]: _w In [6]: e.series(_w, 0, 2) Out[6]: _w ╲╱ _w 1 + ── - ── + O(_w**(3/2)) 8 2 In [8]: e.series(_w, 0, 3) Out[8]: 2 3/2 _w ╲╱ _w29⋅_w_w 1 + ── - ── - ── + ─ + O(_w**(5/2)) 8 2 128 8 Use a fixed width font or look here: http://paste.debian.net/15584/plain/15584 alternatively: In [10]: print e.series(_w, 0, 3) 1 + _w/8 - 1/2*_w**(1/2) - 29*_w**2/128 + 1/8*_w**(3/2) + O(_w**(5/2)) Now compare maxima: sage: var(_w) _w sage: e = 1/(((1/_w + _w**(-1/2))**(1/2) + 1/_w)**(1/2)*_w**(1/2)) sage: e.taylor(_w, 0, 2) 1 - sqrt(_w)/2 + _w/8 + _w^(3/2)/8 - 29*_w^2/128 which is the same as sympy, although without the O term. And compare pynac: sage: var(_w, ns=1) _w sage: e = 1/(((1/_w + _w**(-1/2))**(1/2) + 1/_w)**(1/2)*_w**(1/2)) sage: e.series(_w, 2) --- RuntimeError Traceback (most recent call last) /home/ondrej/ipython console in module() /home/ondrej/expression.pyx in sage.symbolic.expression.Expression.series (sage/symbolic/expression.cpp:3948)() RuntimeError: power::eval(): division by zero And there are many more like this. This was one of the reasons when I abandoned swiginac, because I really didn't want to fix this in C++, I rather wanted to play with these things in Python first, until we figure out what needs to work and how. At that time I didn't know how to call maxima from python, nor how to fix ginac easily, so I just wrote everything in Python. But now it may be easier to just go through all the limits and fix all the series in ginac itself. Btw I believe Bernard fixed all of these in giac, didn't you? How difficult was it? This situation reminds me a year ago when Pearu wrote sympycore and it was about 100x faster, just like ginac is now 10x to 100x faster than sympy. So we massively switched to it, and then I had to fix all these series problems and many other things, it's a lot of work. And I am almost 100% sure we could (=should) have sped up sympy iteratively. So you can imagine, I myself am not really keen on absolving the same thing again, especially if we think we can speedup sympy to the level of ginac (or very close) in matter of months from now. However, if Burcin or others come up and help us with it, I am all for it. I believe ginac is in a better state than our new core was. Also the pynac core will be optional, so I think it could work. As to integration, that will be I think a little more difficult to port, but definitely doable as well. By port I will take it to mean improve sympy so it can manipulate Pynac symbolic expressions in addition to its own. I.e., it's basically a duck typing thing, where as long as Pynac exports the right interface, sympy should be able to work with it. Yes, I believe it is worthy to do it. As to GPL vs BSD, I am sad that some people will not contribute to a BSD project and some other people will not use a GPL project. But my intuition says that the license is not the main reason. If sympy was as fast as ginac (as I hope it will be in not so distant future), I am sure it'd be ok, even if it's BSD. BTW, I told Burcin and William that if the license was the only reason, I am willing to consider switching to GPL (i.e. try to persuade all 44+ contributors), if that would mean more people would be developing sympy. Currently it seems to be the opposite, i.e. when we switched from GPL to BSD, people and developers seemed to like it, but I may well be mistaken. But as I said, I think the main problem of sympy is not the license, but speed. The GPL/BSD split in the
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 10:41 PM, Gary Furnish [EMAIL PROTECTED] wrote: Make it so sympy also runs on top of GiNaC. This will force the creation of a clear interface specification. If there is going to be a clear interface spec, then we should go and make a clear interface spec so that anyone, not just GiNaC can potentially conform to it. Perhaps this is the best long term solution? My symbolics code is already GPLv2+ so fixing the headers is just a technicality. Exactly. Especially if you believe you can be way faster than ginac. It'd be really awesome. Maybe William has some ideas how to do it the best, I think it just needs to be done iteratively. We will have 2 production cores soon -- pynac and sympy. Then there is sympycore and your symbolics, so that should give us enough data to see what all the cores have in common and what is different. BTW, one important warning: ginac and sympycore are missing assumptions and sympy only has very trivial ones, like positive, negative, integer, even, odd, etc. This is really important for any nontrivial things in a CAS and I changes to the core may be needed. I really want to have assumptions in sympy first before saying -- yes, this approach to do the core is the best. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
On 26/08/2008, at 2:50 AM, William Stein wrote: Burcin -- I did actually mostly implement pattern matching in Pynac. Is there documentation? A bit of google turned up nothing. sage: sin(1+sin(x)).subs(sin(w0)==cos(w0)) cos(cos(x) + 1) In Mathematica, the result would be cos(sin(x) + 1), since having matched the outer expression, the replacement algorithm moves on rather than in. One would obtain cos(cos(x) + 1) by making the substitution rule sin==cos. Can you do that? Can you evaluate code during the matching of your patterns? Can you nest patterns? I think these are highly desirable, even if they are suitably carefully hidden from the casual user. On 26/08/2008, at 1:24 AM, in a different thread, Burcin Erocal wrote: We already have a pretty good symbolic engine in Sage, maxima does quite a good job of solving integrals, limits, etc. The main problem with Maxima is that we cannot extend it. Is not extending of Maxima a concrete policy? I understand that maxima sucks in some circumstances, but it seems quite the beast here. I am quite confused about a lot of the pattern matching discussion. AFAICT, that is the problem for which lisp rocks, and the best way to do it is probably to write maxima code for it. And the best way to make it accessible from python is to provide pretty python methods to call lisp. Any other suitably general form of pattern mathematical matching will involve the proverbial reimplementation of lisp. D p.s. this is obviously from my fairly basic lisp is more or less mathematica understanding of lisp. == David J Philp Postdoctoral Fellow National Centre for Epidemiology and Population Health Building 62, cnr Mills Rd Eggleston Rd The Australian National University Canberra ACT 0200 Australia T: +61 2 6125 8260 F: +61 2 6125 0740 M: 0423 535 397 W: http://nceph.anu.edu.au/ CRICOS Provider #00120C --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [sympy] Re: [sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
I definitely want to have a version of pynac outside sage. But keep in mind again that pynac is GPL'd, and given your mission statement for sympy, I think it is not an option for you to depend only on something GPL'd as the only option. As I see it, an important part of the sympy mission is to be the CAS for the we will only use BSD'd code side of the Python math software world, which is a very substantial important and well funded group of people. As far as I know we don't have anything about BSD vs GPL in our missing statement. But to make this clear: Yes, if it's at least a bit possible, I'd like to stay BSD, because clearly the BSD market is good. But if staying BSD means that people will not help with sympy but rather help with a GPLed package, I think that getting the job done (=good symbolics in python) is more important than BSD vs GPL flamewar. We had the discussion BSD/GPL here: http://groups.google.com/group/sympy/browse_thread/thread/e5f77a57874d2135/ a good summary is for example this email: http://groups.google.com/group/sympy/msg/183cad529117b758 Ondrej But also I think it's good to say my own opinion on this, and that is, that I personally think that given that I am paid from tax payers money (i.e. grants, stipends, etc.), which are individuals or companies (in my case mostly Czech and European and soon hopefully US), I really think it's fair if the companies can use the work that was produced by their money in the way they want. I.e. BSD fits nice, GPL doesn't. LGPL is somewhere shady, but many companies don't like it either. But I understand that those are complicated questions and and one argument for (L)GPL is the fear that someone will take the code and close it, improve it, sell it and make a lot of money with BSD, while with GPL he is forced to open it and that is better over all, because it brings the code back to the project, that otherwise would not be available. I believe though that less restrictions are better in the long term, i.e. if people and companies can do things that they want and use code as they want, it is better for all of us in the end. But I am not fundamental on this, as I said above, getting the job done and getting people to work together is way more important for me. If you have opposite opinion than I do, I'd love if you could oppose, but please no flamewars. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
Is not extending of Maxima a concrete policy? I understand that maxima sucks in some circumstances, but it seems quite the beast here. I am quite confused about a lot of the pattern matching discussion. AFAICT, that is the problem for which lisp rocks, and the best way to do it is I think it's just about getting people to fix it. There are many people around who can fix Python/Cython and a little less (I guess) who can fix C++ and C. But a lot less who can fix lisp. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: GIAC
On Mon, Aug 25, 2008 at 12:34 PM, parisse [EMAIL PROTECTED] wrote: I meant stuff like this: Installing the required libraries from source (recommended) * CoCoA 0.99 (for faster Groebner basis). Sage already has faster Groebner bases since it included Singular. There is a lot of stuff like that in Xcas/Giac like that Sage already has. This makes sense since Giac/Xcas is a stand-alone system just like Sage. This is not a part of giac, it is an optional external library that is linked in giac. There are other parts of giac that might be interesting for sage or are fast inside giac. Like gcd, limit, integration, contexts... Sage is built from source by many people. One of the design goals was to enable each end user easily to contribute and thus there is no such stark distinction between development and final binaries. This might change eventually, but a build time of 72 minutes seems way too long. I don't see why it's a problem if the spkg_install script specifies CXXFLAGS=-g so that it compiles without optimization in less than 10 minutes by default. If you develop around giac, you will most likely want to use gdb, hence -O2 is bad even with -g. Optimization is only required from time to time when one needs to make benchmarks. Re: William My experience with Giac is that: (a) I can't build it, (b) even on systems where I could, I'm not patient enough, and (c) looking at the source code from the point of view of doing what I want makes me dizzy and I get nowhere, (d) and Giac is HUGE -- about five times the size of Ginac, and much of that code in Giac overlaps with what Sage already does, and (e) my technical build guy tells me that Giac isn't a model of super high quality code. (a) and (b) are bad excuses, since there is a spkg. Even at 10 minutes with no optimization that seriously tests my patience. And 72 minutes with optimization is real deal breaker. (c) Did you first look at the giac.info page? I don't know what that is. However, I expect to be able to cd to the source directory, start looking around, and make progress. I was very pleasantly surprised by how well this worked with ginac, which certainly passes that test. (d) Yes, giac/xcas is large (maybe 100K lines for giac, you don't have to look at the interface code), but that's the price to have a CAS! True. I'm not saying giac is at all bad -- I just don't think it is the right tool for the problem that I need to solve. (e) Perhaps. From my own experience, it is not easy to enter into a large library (e.g. cocoa, pari, etc.). I don't know what you mean here. Pari is also a fairly unpleasant library to work with. Ginac is one of the better ones I've seen, similar maybe to NTL which is also quite good as far as usability goes. PARI is terrible to use as a library. So to me Giac cannot solve any of our problems today, unless we want Sage to be bloated, and we want to take months or years rather than a few days to get this stuff done. I can't believe it would take years to make sage and giac interoperate. Even if it take months, that should be compared to the time required to get the same level of functionnalities at a comparable speed over ginac. Perhaps I could take code from Giac, e.g., for limits or symbolic integration, but (a) you're using GPLv3, so I can't, and (b) probably that would make you unhappy anyways, and (c) I would rather such functionality comes from the sympy project, since that is in Python. (a) is not recevable since I could relicense it to GPL v2. Anyway, it is highly improbable that you could take code slices without taking almost all of the library. Higher level code depends on the low level routines and data structures (e.g. rational fraction integration from multivariate polynoms) + many parts are interconnected (e.g. integration requires linear algebra) which BTW makes modularization difficult. This nicely illustrates issues with using giac for sage. Again, it is not to say that giac is bad; just that it isn't suitable for my purposes. Ok, it's probably time lost for both parts, I'm afraid I won't convince you to use giac and you will certainly not convince me to abandon giac in favor of re-developing over ginac or inside sympy (which I find interesting, I wonder how the speed problem will be fixed). I am not at all trying to convince you to do anything differently. The real fight should be with closed-source systems. I will keep looking at symbolic threads, it's always interesting to test examples and benchmarks. I'm not even trying to fight with closed source systems. I just want to get Sage's symbolic manipulation capabilities to be up to snuff for research level work, which is something they are not right now, except for say calculus teaching. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 1:41 PM, Gary Furnish [EMAIL PROTECTED] wrote: Make it so sympy also runs on top of GiNaC. This will force the creation of a clear interface specification. If there is going to be a clear interface spec, then we should go and make a clear interface spec so that anyone, not just GiNaC can potentially conform to it. Perhaps this is the best long term solution? It will not be clear what that spec should be until 2 systems use it. In my opinion, specs should not be written by committee, but by abstracted away from an actual working solution. When Sage and Sympy can both run on top of a Pynac core, we'll see how it works and have a clear interface as a result. My symbolics code is already GPLv2+ so fixing the headers is just a technicality. Please do so and make an official release as a tarball or something. On Mon, Aug 25, 2008 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] a new language
Hi all, I am not a computer scientist and nor I have much experience like you. So my question may not be too much meaningful, but I want to ask it :) All I see in the opensource industry that people do many good programs, but most of them are some duplicate and much of them are not too much functional and promising ones. So, I think bringing the same goaled projects under same umbrella is according to my opinion very crucial. And as I see (if I understand correct, please correct me if I am wrong) all the programs are written in different languages and they do not fully communicate each other perfectly. So people need to reimplement some of the codes which is time consuming and tedious. So, can't someone develop a new programming language that could interact all the properties of the most widely used languages? Again sorry if the question is not meaningful :) Thanks with Best Regards AAP... --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [sympy] Re: [sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
For example pynac uses sin(x).seires(x, 5) Actually, more precisely pynac uses: sin(x).series(x == 3, 5) to get a taylor expansion about x = 3. I did this only for consistency with GiNaC, since that is what GiNaC does. sympy uses sin(x).series(x, 0, 5) and sage uses sin(x).taylor(x, 0, 5) Using taylor is really dumb. It is inconsistent with every other system and is confusion since it can give Laurent series. and this is unfortunate. I would like to use just one interface. Yep. That's precisely what we'll have to have in order to have a sympy + pynac system. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: a new language
Hello, So, can't someone develop a new programming language that could interact all the properties of the most widely used languages? Again sorry if the question is not meaningful :) I think creating a new language would hurt the problem more than help it since you have yet another language to support, find developers for, build up a critical mass, maintain, etc. Plus, most of the developers here would probably rather use a language rather than write one. Sage uses Python for these reasons. A better solution might be to work on tools to allow better interaction within the existing languages. Examples of this include Cython or getting Maxima to run on ECL. --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
On 26/08/2008, at 8:15 AM, Ondrej Certik wrote: Is not extending of Maxima a concrete policy? I understand that maxima sucks in some circumstances, but it seems quite the beast here. I am quite confused about a lot of the pattern matching discussion. AFAICT, that is the problem for which lisp rocks, and the best way to do it is I think it's just about getting people to fix it. There are many people around who can fix Python/Cython and a little less (I guess) who can fix C++ and C. But a lot less who can fix lisp. I think that could change. There must be a few experienced mathematica users who would happily enough pick up lisp as part of their transition to sage. Mathematica - lisp - sage is surely easier than mathematica - python - sage. Anyway, it is always better to learn the right tool for the job, than to rewrite it yourself. It will be less effort for sage people to learn lisp than to design and implement a pattern matching language / domain-specific-language / library. http://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule Any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp. D == David J Philp Postdoctoral Fellow National Centre for Epidemiology and Population Health Building 62, cnr Mills Rd Eggleston Rd The Australian National University Canberra ACT 0200 Australia T: +61 2 6125 8260 F: +61 2 6125 0740 M: 0423 535 397 W: http://nceph.anu.edu.au/ CRICOS Provider #00120C --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
BTW, one important warning: ginac and sympycore are missing assumptions and sympy only has very trivial ones, like positive, negative, integer, even, odd, etc. This is really important for any nontrivial things in a CAS and I changes to the core may be needed. I really want to have assumptions in sympy first before saying -- yes, this approach to do the core is the best. Ondrej Why are assumptions really important for any nontrivial things in a CAS? In my entire life I've only ever used assumptions to get maxima to do a symbolic integration. I've never used them in any other context. Can you please educate me on why they are so important? Thanks. william --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: a new language
#include 0.014 e On Aug 25, 2008, at 3:17 PM, ahmet alper parker wrote: Hi all, I am not a computer scientist and nor I have much experience like you. So my question may not be too much meaningful, but I want to ask it :) All I see in the opensource industry that people do many good programs, but most of them are some duplicate and much of them are not too much functional and promising ones. So, I think bringing the same goaled projects under same umbrella is according to my opinion very crucial. And as I see (if I understand correct, please correct me if I am wrong) all the programs are written in different languages and they do not fully communicate each other perfectly. So people need to reimplement some of the codes which is time consuming and tedious. So, can't someone develop a new programming language that could interact all the properties of the most widely used languages? Again sorry if the question is not meaningful :) It's always tempting to consider a new language, and a complete rewrite of a major system, but the reality can be pretty harsh. I think it's tantamount to saying the highway system in the U.S. is pretty bad; let's start over and do it right. The dislocation, startup costs, and general headaches that come with this idea are overwhelming. No one would seriously consider rebuilding a major highway system, or, say, New York City, from the ground up. The associated problems tend to be obvious, so the subject rarely comes up. Software seems to be easy, so rebuilding can appear easy, but, if the system is large and complex, as is Sage or a new language, the issues are similar to the hardware situation. We have several languages right now that are quite useful and more than adequate for the needs of Sage (Python and C, in particular). As Mike says, the better solution is to make the pieces play together well (and, of course, to manage the development so that it doesn't get out of hand :-}). Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds If you're not confused, You're not paying attention --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: a new language
thanks for your comments :) I think you all are right... :) On Tue, Aug 26, 2008 at 2:08 AM, Justin C. Walker [EMAIL PROTECTED] wrote: #include 0.014 e On Aug 25, 2008, at 3:17 PM, ahmet alper parker wrote: Hi all, I am not a computer scientist and nor I have much experience like you. So my question may not be too much meaningful, but I want to ask it :) All I see in the opensource industry that people do many good programs, but most of them are some duplicate and much of them are not too much functional and promising ones. So, I think bringing the same goaled projects under same umbrella is according to my opinion very crucial. And as I see (if I understand correct, please correct me if I am wrong) all the programs are written in different languages and they do not fully communicate each other perfectly. So people need to reimplement some of the codes which is time consuming and tedious. So, can't someone develop a new programming language that could interact all the properties of the most widely used languages? Again sorry if the question is not meaningful :) It's always tempting to consider a new language, and a complete rewrite of a major system, but the reality can be pretty harsh. I think it's tantamount to saying the highway system in the U.S. is pretty bad; let's start over and do it right. The dislocation, startup costs, and general headaches that come with this idea are overwhelming. No one would seriously consider rebuilding a major highway system, or, say, New York City, from the ground up. The associated problems tend to be obvious, so the subject rarely comes up. Software seems to be easy, so rebuilding can appear easy, but, if the system is large and complex, as is Sage or a new language, the issues are similar to the hardware situation. We have several languages right now that are quite useful and more than adequate for the needs of Sage (Python and C, in particular). As Mike says, the better solution is to make the pieces play together well (and, of course, to manage the development so that it doesn't get out of hand :-}). Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for the Absorption of Federal Funds If you're not confused, You're not paying attention --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
On Aug 25, 12:50 pm, William Stein [EMAIL PROTECTED] wrote:
On Mon, Aug 25, 2008 at 4:47 AM, Burcin Erocal [EMAIL PROTECTED] wrote:
On Sun, 24 Aug 2008 15:55:25 -0700 (PDT)
Jason Merrill [EMAIL PROTECTED] wrote:
In hopes that it may be a useful reference during the current work on
symbolics, I wrote a toy Mathematica program for transforming a single
higher order ODE into a system of first order ODEs. Most of the free
numerical differential equation solvers I've seen want input in the
form y'[x] == f(y,x), so the purpose of a program like this is to take
more general input and turn it into something suitable for those
routines.
snip
Burcin -- I did actually mostly implement pattern matching in Pynac.
Some examples:
sage: var('x,y,z,a,b,c,d,e,f',ns=1); S = parent(x)
(x, y, z, a, b, c, d, e, f)
sage: w0 = S.wild(0); w1 = S.wild(1); w2 = S.wild(2)
sage: ((x+y)^a).match((x+y)^a)
True
sage: ((x+y)^a).match((x+y)^b)
False
sage: (a^2 + b^2 + (x+y)^2).subs(w0^2 == w0^3)
(x + y)^3 + a^3 + b^3
sage: (a^4 + b^4 + (x+y)^4).subs(w0^2 == w0^3)
(x + y)^4 + a^4 + b^4
sage: (a^2 + b^4 + (x+y)^4).subs(w0^2 == w0^3)
(x + y)^4 + a^3 + b^4
sage: ((a+b+c)^2).subs(a+b==x)
(a + b + c)^2
sage: ((a+b+c)^2).subs(a+b+w0==x+w0)
(c + x)^2
sage: (a+2*b).subs(a+b==x)
a + 2*b
sage: (a+2*b).subs(a+b+w0 == x+w0)
a + 2*b
sage: (a+2*b).subs(a+w0*b == x)
x
sage: (a+2*b).subs(a+b+w0*b == x+w0*b)
a + 2*b
sage: (4*x^3-2*x^2+5*x-1).subs(x==a)
4*a^3 - 2*a^2 + 5*a - 1
sage: (4*x^3-2*x^2+5*x-1).subs(x^w0==a^w0)
4*a^3 - 2*a^2 + 5*x - 1
sage: (4*x^3-2*x^2+5*x-1).subs(x^w0==a^(2*w0)).subs(x==a)
4*a^6 - 2*a^4 + 5*a - 1
sage: sin(1+sin(x)).subs(sin(w0)==cos(w0))
cos(cos(x) + 1)
sage: (sin(x)^2 + cos(x)^2).subs(sin(w0)^2+cos(w0)^2==1)
1
sage: (1 + sin(x)^2 + cos(x)^2).subs(sin(w0)^2+cos(w0)^2==1)
sin(x)^2 + cos(x)^2 + 1
sage: (17*x + sin(x)^2 + cos(x)^2).subs(w1 +
sin(w0)^2+cos(w0)^2 == w1 + 1)
17*x + 1
sage: ((x-1)*(sin(x)^2 + cos(x)^2)^2).subs(sin(w0)^2+cos(w0)^2 ==
1)
x - 1
Awesome. Thanks for making all this happen. I'm really excited about
where Sage is going. I've only been watching for a couple weeks now,
but I think I chose a fun time to find out about it.
Is the syntax for this stuff set in stone? I'm not sure I like the
equality inside the subs call. Equality is reflexive, but
substitution is a one way operation. What about a dictionary, sage: (a
+2*b).subs({a+b:x}), or even just a single equal sign, like keyword
args, sage: (a+2*b).subs(a+b=x). The double equals would work too,
but now is probably a better time for discussion than later.
JM
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: missing imports for experimental module for Sage
On Mon, Aug 25, 2008 at 9:33 AM, Philippe Saade [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 2:41 PM, David Joyner [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 8:20 AM, Philippe Saade [EMAIL PROTECTED] wrote: nybody give me a hint ? Did you add it to devel/sage/setup.py? No and honestly, i don't fully understand the way that file is structured. If you could give me an example of a line i should add... Sorry to bother You only need to modify that file if you are adding a file to sage/devel somewhere and want sage to auto-load your python module. Since William's suggestion helped you, it seems you are doing something different, so you can leave setup.py alone. Philippe (rem : the classes defined in that module work fine if placed in a notebook cell) Philippe --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
On Aug 24, 6:55 pm, Jason Merrill [EMAIL PROTECTED] wrote:
In hopes that it may be a useful reference during the current work on
symbolics, I wrote a toy Mathematica program for transforming a single
higher order ODE into a system of first order ODEs. Most of the free
numerical differential equation solvers I've seen want input in the
form y'[x] == f(y,x), so the purpose of a program like this is to take
more general input and turn it into something suitable for those
routines.
I'll use the Poisson-Boltzmann equation in spherical coordinates, a
second order ODE, as my test example, because I recently needed to
solve it numerically.
pbe = r^2 p''[r] + 2 r p'[r] == r^2 k^2 Sinh[p[r]]
The full form of the equation, which is useful for pattern matching,
is
FullForm[pbe]
Equal[Plus[Times[2,r,Derivative[1][p][r]],Times[Power[r,
2],Derivative[2][p][r]]],Times[Power[k,2],Power[r,2],Sinh[p[r
Notice how this looks a lot like Lisp?
First, I want to find out what the order of the equation is, so I will
match any terms of the form Derivative[o][p][r], and then find the
match with the maximum o:
diffEqOrder[eqn_, y_, x_] :=
Max[Cases[pbe, Derivative[o_][y][x] - o, Infinity]]
Cases produces a list of all the subexpressions in its first argument
that match the pattern specified in the second argument, optionally
with a replacement rule applied to the matches. By default, it only
looks at the top level of an expression, but setting the final
argument to Infinity forces it to look all the way down the tree. The
_ here is a wildcard that matches any expression, and writing o_ gives
that subexpression a name. Since o is the only part I care about, I
replace all the matches with just o.
diffEqOrder[pbe, p, r]
2
Now we're ready for the function that actually transforms equations:
firstOrderForm[eqn_, y_, x_] :=
Module[{rep, order = diffEqOrder[eqn, y, x]},
rep = Solve[
eqn /. {Derivative[o_][y][x] - y[o][x], y[x] - y[0][x]},
y[order][x]];
Join[Table[y'[o][x] == y[o + 1][x], {o, 0, order - 2}],
y'[order - 1][x] == y[order][x] /. rep]
]
The Module bit is just for keeping variables used in the definition
out of global scope. The important line is
eqn /. {Derivative[o_][y][x] - y[o][x], y[x] - y[0][x]}
where I use the replacement operator /. to replace all the derivatives
of y with respect to x by a new function of x, y[o][x], where o is
again the order of the derivative. Once I've done that, I solve the
equation for the highest order term. Then I make a list basically
just giving definitions of all the new functions as derivatives of the
next lower order functions, and stick the solved highest order
derivative equation on the end of the list.
Here's the result for the example equation
firstOrderForm[pbe, p, r]
{p'[0][r] == p[1][r], p'[1][r] == (k^2 r Sinh[p[0][r]] - 2 p[1][r])/r}
It's just a short shot from here to providing the input in a form that
would be accepted by the gsl solver, or scipy.
Hopefully this will be useful as one example of the kind of
manipulations that pattern matching makes possible. I'm happy to
answer any more questions about it.
Regards,
Jason Merrill
I'm afraid I'm straying off topic, but I thought I'd use the above
code as a jumping off point to say a few more things about pattern
matching and Mathematica, since there seems to be at least some
interesting in hearing about this kind of thing. First, I should
point out that there was a bug in my definition of diffEqOrder:
diffEqOrder[eqn_, y_, x_] :=
Max[Cases[pbe, Derivative[o_][y][x] - o, Infinity]]
should be
diffEqOrder[eqn_, y_, x_] :=
Max[Cases[eqn, Derivative[o_][y][x] - o, Infinity]] (*Changed pbe
to eqn on this line*)
Pattern matching is one of the fundamental underpinnings of
Mathematica--more than is obvious at first pass. I used it
conspicuously to play with derivative terms, but it is used
inconspicuously in every function definition. Remember how _ is a
wildcard, and o_ gives the match a name so it can be used again
later? Well that's what's going on in function definitions. In its
definition, each of the arguments of diffEqOrder is a named pattern,
which is why we can use the names eqn, y, and x later in the
definition. So function definitions are just replacement rules that
are applied globally after they are defined.
You can be more restrictive with the argument patterns than just using
wildcards. For instance, say I wanted to allow the first argument to
just be an expression, with an implied == 0 at the end. I could have
done
Clear[diffEqOrder] (*just gets rid of the old definition*)
diffEqOrder[eqn_Equal,y_,x_] :=
Max[Cases[eqn, Derivative[o_][y][x] - o, Infinity]]
diffEqOrder[expr_,y_,x_] := diffEqOrder[expr == 0, y, x]
The eqn_Equal is a more restrictive pattern that only matches
expressions whose head is Equal, i.e. Equal[_,_] which is the same as
_ == _ . Here's a factorial definition in the same
[sage-devel] Re: Changing line() and text() to not generate 3d objects
On Aug 21, 6:54 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Thu, 21 Aug 2008, Jason Grout wrote: What do people think of changing line() and text() to only give 2d graphics. Currently, the behavior for line() seems to be something like, passing in a list of coordinates: 1. if the list has 3-dimensional coordinates, make a 3d line 2. if the list has more than 3-dimensional coordinates, silently strip off the first two and make a 2d line 3. if the list has 2-dimensional coordinates, Since there is not feature-parity between the 2d and 3d backends, the current setup also means that options become valid or invalid depending on how line() interprets its coordinates. That sounds like a very bad thing. There is a patch up at #3853 which makes line() and text() only do 2d stuff, leavingline3dand text3d for the 3d things. I've also fixed some other places that assumed the current behavior (which broke some doctests; hooray for doctests). Are there any comments about making this change? -1 I also don't like this change. It seems pretty unambiguous what I want to do if I pass line() a list with three dimensional coordinates. I want a 3D line. I don't really understand the rationale for this change. 1. and 3. above seem like correct behavior. 2. should throw an error, until there is a 4D plotting backed ;-). Is there more specific data on the problem with options not being the same between 2D and 3D? Could the options be fixed to be the same? Or to fail in a sensible way? JM --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
Tim Lahey wrote: 3. Somewhat related to #1, is the ability to make new variables/ function names from old ones. For example, when in the Calculus of Variations, I'll create the variation function with a name based on the function to be varied (e.g., v(x,y,z,t) to \delta v(x,y,z,t)). I also need this to carry out my EulerLagrange calculation. To illustrate this, my Maple code for this is: Dunno if it really matters, but I couldn't resist the opportunity to translate the function in question to Maxima ... euler_lagrange (Lagrangian, variables) := block ([num_list, qv_name, vel_var, qv_subs, qv_unsubs, Lagrange_subs1, Lagrange_subs2, dL_dqv1, dL_dqv2, dL_dqv, dL_dqvt, dL_dq, dL_dq1, dL_dq2, dL_dq3, q_name, q_subs, q_unsubs], /* guessing here that nops = length */ num_list : makelist (i, i, 1, length (variables)), qv_name : map (concat, qv, num_list), q_name : map (concat, q, num_list), vel_var : map (lambda ([x], 'diff (x, t)), variables), /* guessing here that * zip(f, a, b) = [f(a[1], b[1]), ..., f(a[n], b[n]) */ qv_subs : map (=, vel_var, qv_var), qv_unsubs : map (=, qv_var, vel_var), q_subs : map (=, variables, q_name), q_unsubs : map (=, q_name, variables), /* guessing here that subs = subst */ Lagrange_subs1 : subst (qv_subs, Lagrangian), Lagrange_subs2 : subst (q_subs, Lagrange_subs1), dL_dqv1 : map (lambda ([x], diff (Lagrange_subs2, x)), qv_name), dL_dq1 : map (lambda ([x], diff (Lagrange_subs2, x)), q_name), /* not sure why original has map2(subs(...)) here; * why not just subs ? stagger ahead anyway */ dL_dq2 : subst (qv_unsubs, dL_dq1), dL_dqv2 : subst (qv_unsubs, dL_dqv1), dL_dqv : subst (q_unsubs, dL_dqv2), dL_dq : subst (q_unsubs, dL_dq2), dL_dqvt : map (lambda ([u], diff (u, t)), dL_dqv), [dL_dqvt, dL_dq]); The above is untested. As you can see from the comments I'm not sure what some (maybe most) of the Maple functions do. What does this prove? Maybe not much, except that in this case it's possible to do some useful expression hacking without writing new code for Sage. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
On Mon, Aug 25, 2008 at 3:08 PM, David Philp [EMAIL PROTECTED] wrote: On 26/08/2008, at 2:50 AM, William Stein wrote: Burcin -- I did actually mostly implement pattern matching in Pynac. Is there documentation? A bit of google turned up nothing. (1) Let me clarify -- I *wrapped* the pattern matching already in Pynac. (2) I made up the name pynac about 3 days ago, and released the first version 15 hours ago. This is code that will be included in Sage. There was a long sage-devel post about this last night. So I doubt Google will find anything.Incidentally, Pynac = Ginac + Python - CLN, and you can read about Ginac at the Ginac website: http://www.ginac.de/ sage: sin(1+sin(x)).subs(sin(w0)==cos(w0)) cos(cos(x) + 1) In Mathematica, the result would be cos(sin(x) + 1), since having matched the outer expression, the replacement algorithm moves on rather than in. One would obtain cos(cos(x) + 1) by making the substitution rule sin==cos. Can you do that? Can you evaluate code during the matching of your patterns? Can you nest patterns? I think these are highly desirable, even if they are suitably carefully hidden from the casual user. I didn't implement the pattern matching. I wrapped the pattern matching that is provided by GiNaC. It is certainly not identical to the pattern matching in Mathematica, at present. I'm glad you're pointing out some of the differences between what is in Mathematica and what is in Ginac. Thanks! We already have a pretty good symbolic engine in Sage, maxima does quite a good job of solving integrals, limits, etc. The main problem with Maxima is that we cannot extend it. Is not extending of Maxima a concrete policy? Maxima is definitely not the future of symbolic manipulation *in Sage*: (1) Maxima cannot manipulate native Python objects (e.g., real interval field elements, number field elements, finite field elements); both Pynac and sympy can. (2) Maxima is written in Lisp. This is a total show stopper for most Sage developers, including me. Both apply to Axiom, too, by the way. I understand that maxima sucks in some circumstances, but it seems quite the beast here. I am quite confused about a lot of the pattern matching discussion. AFAICT, that is the problem for which lisp rocks, and the best way to do it is probably to write maxima code for it. And the best way to make it accessible from python is to provide pretty python methods to call lisp. Any other suitably general form of pattern mathematical matching will involve the proverbial reimplementation of lisp. That would be a waste of time for Sage. No matter how good Maxima is or its pattern matching is, Maxima is still working in it's own world of objects and data types, which have nothing much to do with Python's. Maxima/Axiom live on a totally different planet than Python/C/C++. This is just a fact we have to deal with. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
On Mon, Aug 25, 2008 at 3:43 PM, David Philp [EMAIL PROTECTED] wrote: On 26/08/2008, at 8:15 AM, Ondrej Certik wrote: Is not extending of Maxima a concrete policy? I understand that maxima sucks in some circumstances, but it seems quite the beast here. I am quite confused about a lot of the pattern matching discussion. AFAICT, that is the problem for which lisp rocks, and the best way to do it is I think it's just about getting people to fix it. There are many people around who can fix Python/Cython and a little less (I guess) who can fix C++ and C. But a lot less who can fix lisp. As I mentioned before, another big problem is that lisp doesn't manipulate native Python objects efficiently. Python *is* just a C library -- Python and C/C++ play very well together, especially because of Cython. The same is not the case with lisp/maxima. I think that could change. There must be a few experienced mathematica users who would happily enough pick up lisp as part of their transition to sage. Mathematica - lisp - sage is surely easier than mathematica - python - sage. In four years not a single such person has ever appeared on sage-devel. Anyway, it is always better to learn the right tool for the job, than to rewrite it yourself. [...] Yes, but Maxima is not the right tool for this job. -- william --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
I'm afraid I'm straying off topic, but I thought I'd use the above
code as a jumping off point to say a few more things about pattern
Given the topic which is Mathematica pattern matching, this email
is 100% on topic, and I *definitely* appreciate it!
matching and Mathematica, since there seems to be at least some
interesting in hearing about this kind of thing. First, I should
point out that there was a bug in my definition of diffEqOrder:
diffEqOrder[eqn_, y_, x_] :=
Max[Cases[pbe, Derivative[o_][y][x] - o, Infinity]]
should be
diffEqOrder[eqn_, y_, x_] :=
Max[Cases[eqn, Derivative[o_][y][x] - o, Infinity]] (*Changed pbe
to eqn on this line*)
Pattern matching is one of the fundamental underpinnings of
Mathematica--more than is obvious at first pass. I used it
conspicuously to play with derivative terms, but it is used
inconspicuously in every function definition. Remember how _ is a
wildcard, and o_ gives the match a name so it can be used again
later? Well that's what's going on in function definitions. In its
definition, each of the arguments of diffEqOrder is a named pattern,
which is why we can use the names eqn, y, and x later in the
definition. So function definitions are just replacement rules that
are applied globally after they are defined.
You can be more restrictive with the argument patterns than just using
wildcards. For instance, say I wanted to allow the first argument to
just be an expression, with an implied == 0 at the end. I could have
done
Clear[diffEqOrder] (*just gets rid of the old definition*)
diffEqOrder[eqn_Equal,y_,x_] :=
Max[Cases[eqn, Derivative[o_][y][x] - o, Infinity]]
diffEqOrder[expr_,y_,x_] := diffEqOrder[expr == 0, y, x]
The eqn_Equal is a more restrictive pattern that only matches
expressions whose head is Equal, i.e. Equal[_,_] which is the same as
_ == _ . Here's a factorial definition in the same style
fac[n_Integer] := n*fac[n - 1]
fac[1] := 1
Part of what allows pattern matching to be so powerful is that
*everything* has a full form that is just an expression tree tree,
like
FullForm[pbe]
Equal[Plus[Times[2,r,Derivative[1][p][r]],Times[Power[r,
2],Derivative[2][p][r]]],Times[Power[k,2],Power[r,2],Sinh[p[r
Even plots have this form
FullForm[Plot[Sin[x], {x, -Pi, Pi}]]
Graphics[List[List[List[],List[],List[Hue[0.67`,0.6`,
0.6`],Line[List[List[-3.1415925253615216`,-1.2822827167891634`*^-7],
...,List[3.1415925253615216`,
1.2822827167891634`*^-7]],List[Rule[AspectRatio,Power[GoldenRatio,-1]],Rule[Axes,True],Rule[AxesOrigin,List[0,0]],
Rule[PlotRange,List[List[Times[-1,Pi],Pi],List[-0.998782112116`,
0.998592131705`]]],
Rule[PlotRangeClipping,True],Rule[PlotRangePadding,List[Scaled[0.02`],Scaled[0.02`]
Not that friendly to look at, but this form lets me manipulate plots
just like any other data. If I want to see just the points that are
evaluated for the plot, omitting the line connecting them, I can do
Plot[Sin[x],{x,-Pi,Pi}] /. Line-Point
This gets to the reason that I think Mathematica is actually a
beautiful language. First, it has the Lisp thing going for it--
everything is an expression, and programs are data. Given that
foundation, it uses pattern matching to do basically all of the work
with expressions, which makes things feel really unified once you get
it. It also provides powerful functional programming constructs: Map,
Nest, Fold, Thread, and variations on these themes.
Mathematica is nominally multi-paradigm: it has For loops and other
procedural stuff; it also has objects, sort of, though I've never seen
much done with them. But really, functional programming and pattern
matching are the beautiful part, and they let you do everything. If
you've tried to program Mathematica a different way, you probably
thought it was ugly. But then, you were doing it wrong.
Thanks for all that explanation. I really appreciate it.
-- William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Changing line() and text() to not generate 3d objects
-1 I also don't like this change. It seems pretty unambiguous what I want to do if I pass line() a list with three dimensional coordinates. I want a 3D line. I don't really understand the rationale for this change. 1. and 3. above seem like correct behavior. 2. should throw an error, until there is a 4D plotting backed ;-). Is there more specific data on the problem with options not being the same between 2D and 3D? Could the options be fixed to be the same? Or to fail in a sensible way? The patch at #3853 will dispatch to line3d if line2d (same for point) fails. This is the same behavior as was there before. It needs to be reviewed. --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
Jason Merrill wrote:
pbe = r^2 p''[r] + 2 r p'[r] == r^2 k^2 Sinh[p[r]]
diffEqOrder[eqn_, y_, x_] :=
Max[Cases[pbe, Derivative[o_][y][x] - o, Infinity]]
firstOrderForm[eqn_, y_, x_] :=
Module[{rep, order = diffEqOrder[eqn, y, x]},
rep = Solve[
eqn /. {Derivative[o_][y][x] - y[o][x], y[x] - y[0][x]},
y[order][x]];
Join[Table[y'[o][x] == y[o + 1][x], {o, 0, order - 2}],
y'[order - 1][x] == y[order][x] /. rep]
]
OK --- here is some more or less equivalent Maxima code.
Maxima's pattern construction functions are more verbose.
There isn't any built-in function to get a list of subexpressions
but it's easy to create one.
matchdeclare ([aa, bb], symbolp, ii, integerp);
defrule (r1, 'diff (aa, bb, ii), ii);
defrule (r2, 'diff (aa, bb, ii), aa[ii]);
subexprs (e) := if mapatom(e) then e else [e, map (subexprs, args
(e))];
first_order_form (e, y, x) := block ([n],
n : apply (max, subst (false=minf, map (r1, flatten (subexprs
(e),
ev (subst (y=y[0], apply1 (e, r2)), opsubst=false),
solve (%%, y[n]),
append
(makelist ('diff (y[i], x) = y[i + 1], i, 0, n - 2),
['diff (y[n - 1], x) = rhs (%%[1])]));
firstOrderForm[pbe, p, r]
{p'[0][r] == p[1][r], p'[1][r] == (k^2 r Sinh[p[0][r]] - 2 p[1][r])/r}
pbe : r^2 * 'diff (p, r, 2) + 2 * r * 'diff (p, r) = r^2 * k^2 * sinh
(p);
first_order_form (pbe, p, r);
= ['diff(p[0],r,1) = p[1],
'diff(p[1],r,1) = (sinh(p[0])*k^2*r-2*p[1])/r]
It's just a short shot from here to providing the input in a form that
would be accepted by the gsl solver, or scipy.
Yes. I believe a combination of symbolic and numerical problem
solving is very powerful.
FWIW
Robert Dodier
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
Tim Lahey wrote: I presume that Sage can't take a derivative with respect to a function (Maple can't which is why this code is written this way). By the way, what do you mean by that? What is the operation that you would like to do, but fails? Thanks for the info. Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
Robert, Taking the derivative with respect to a function is something like diff(L,u(x,t)); and also diff(L,diff(u(x,t),t)); where L may contain terms with u(x,t) and diff(u(x,t),t). So, u(x,t) is a function, not just a symbolic variable. These terms pop up in the Euler-Lagrange equation which is at the heart of Calculus of Variations. I haven't tried to do it in Sage, but I haven't seen any examples that use it and I couldn't find any Maxima examples either. Cheers, Tim. smime.p7s Description: S/MIME cryptographic signature
[sage-devel] Re: Things I miss from Maple in Sage
On Aug 25, 2008, at 8:05 PM, Robert Dodier wrote: Tim Lahey wrote: I presume that Sage can't take a derivative with respect to a function (Maple can't which is why this code is written this way). By the way, what do you mean by that? What is the operation that you would like to do, but fails? Thanks for the info. You could use automatic differentiation, but that has yet to be implemented in Sage. http://en.wikipedia.org/wiki/ Automatic_differentiation - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
On 26/08/2008, at 12:42 PM, William Stein wrote: 1) Let me clarify -- I *wrapped* the pattern matching already in Pynac. ... and you can read about Ginac at the Ginac website: http://www.ginac.de/ Thanks for the clarification. Sorry I missed the post about pynac--- I'm fairly quick to delete stuff. In the spirit of clarification, I should say that I am not particularly batting for Lisp, Maxima or Mathematica, nor do I want to make sage look like Mathematica. But this area of pattern matching is one where the Mathematica / Lisp way of doing things is extremely instructive. That is the only reason I am rabbitting on about it. sage: sin(1+sin(x)).subs(sin(w0)==cos(w0)) cos(cos(x) + 1) In Mathematica, the result would be cos(sin(x) + 1), since having matched the outer expression, the replacement algorithm moves on rather than in. One would obtain cos(cos(x) + 1) by making the substitution rule sin==cos. Can you do that? Can you evaluate code during the matching of your patterns? Can you nest patterns? I think these are highly desirable, even if they are suitably carefully hidden from the casual user. I didn't implement the pattern matching. I wrapped the pattern matching that is provided by GiNaC. It is certainly not identical to the pattern matching in Mathematica, at present. I'm glad you're pointing out some of the differences between what is in Mathematica and what is in Ginac. Thanks! I see. (Sorry for sounding like I was jumping down your throat.) I was actually asking what capabilities you envisage. From looking at ginac, I think there's a good chance that it does all those things. We already have a pretty good symbolic engine in Sage, maxima does quite a good job of solving integrals, limits, etc. The main problem with Maxima is that we cannot extend it. Is not extending of Maxima a concrete policy? Maxima is definitely not the future of symbolic manipulation *in Sage*: I don't know maxima well enough to have opinions on that, (except that it looked like a good idea at the time.) (2) Maxima is written in Lisp. This is a total show stopper for most Sage developers, including me. In the spirit of learning a new programming paradigm makes you a better programmer I strongly recommend this page: http://www.defmacro.org/ramblings/lisp.html In any case, ginac might just be a good, non-buggy, reimplementation of just that part of lisp we need, and one that is more efficient for the problem at hand. I understand that maxima sucks in some circumstances, but it seems quite the beast here. I am quite confused about a lot of the pattern matching discussion. AFAICT, that is the problem for which lisp rocks, and the best way to do it is probably to write maxima code for it. And the best way to make it accessible from python is to provide pretty python methods to call lisp. Any other suitably general form of pattern mathematical matching will involve the proverbial reimplementation of lisp. That would be a waste of time for Sage. No matter how good Maxima is or its pattern matching is, Maxima is still working in it's own world of objects and data types, which have nothing much to do with Python's. Maxima/ Axiom live on a totally different planet than Python/C/C++. This is just a fact we have to deal with. I actually don't understand this. For both pynac and the existing maxima link, I think you must already have some method of transforming a python object to and from lisp-like expressions. I suppose it might be problematically inefficient. At any rate, I am not after implementation details at the moment, sorry for bringing that furphy up. D == David J Philp Postdoctoral Fellow National Centre for Epidemiology and Population Health Building 62, cnr Mills Rd Eggleston Rd The Australian National University Canberra ACT 0200 Australia T: +61 2 6125 8260 F: +61 2 6125 0740 M: 0423 535 397 W: http://nceph.anu.edu.au/ CRICOS Provider #00120C --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
On Aug 25, 2008, at 11:45 PM, William Stein wrote: The chain rule from calculus says that if f(x) = g(h(x)) then df/dx = (dg/dh) * (dh/dx). Dividing both sides by dh/dx we see that dg / dh = (df /dx) / (dh/dx). I thus suspect that when you say differentiate g(h(x)) with respect to h you might mean to compute dg/dh, as defined by the chain rule above. Yes, but that's a) a horribly inefficient way of doing that and b) in my case, impossible. I don't know h(x) because I'm trying to solve for it. It's the whole point of the system of PDEs. But, dg/dh is easily computable if you have g which I have. The point is that differentiation with respect to a function or a variable should be equivalent. Cheers, Tim. smime.p7s Description: S/MIME cryptographic signature
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
On Mon, Aug 25, 2008 at 8:55 PM, David Philp [EMAIL PROTECTED] wrote:
On 26/08/2008, at 12:42 PM, William Stein wrote:
1) Let me clarify -- I *wrapped* the pattern matching already in
Pynac.
...
and you
can read about Ginac at the Ginac website: http://www.ginac.de/
Thanks for the clarification. Sorry I missed the post about pynac---
I'm fairly quick to delete stuff.
In the spirit of clarification, I should say that I am not
particularly batting for Lisp, Maxima or Mathematica, nor do I want to
make sage look like Mathematica. But this area of pattern matching is
one where the Mathematica / Lisp way of doing things is extremely
instructive. That is the only reason I am rabbitting on about it.
I do greatly appreciate it.
I was actually asking what capabilities you envisage. From looking at
ginac, I think there's a good chance that it does all those things.
It does a lot, but there's no reason to not make it better, and there's every
reason to understand its shortcomings.
That would be a waste of time for Sage. No matter how good Maxima
is or its pattern matching is, Maxima is still working in it's own
world of objects
and data types, which have nothing much to do with Python's. Maxima/
Axiom
live on a totally different planet than Python/C/C++. This is just
a fact
we have to deal with.
I actually don't understand this. For both pynac and the existing
maxima link, I think you must already have some method of transforming
a python object to and from lisp-like expressions.
Pynac works with objects that are simply expression trees constructed
directly from native Python objects. Literally, if you type, e.g.,
sage: S = var('x',ns=1).parent() # new symbolic ring
sage: foo = S(any_crazy_element_you_can_think_of_in_Sage)^3 + 17
then Pynac constructs an expression tree with a *pointer* in memory
to that any_crazy_element_you_can_think_of_in_Sage. This pointer
setting takes a few nanoseconds. Moreover, because of the extreme
flexibility of any_crazy_element_you_can_think_of_in_Sage, you
can do awesome things from this point of view, which are impossible
in maxima via Sage.
Interestingly, today a colleague asked me a computational research
problem, involving computing a bunch of powers series defined
by a recurrence with coefficients in a rational function field.
They were using Magma with quotients of polynomial rings by
powers of ideals over fraction fields, and suffering greatly just
trying to extract off coefficients, etc., and of course in trying
to visualize the result. I just wrote code in a couple minutes
to do what they want using the new Pynac symbolic stuff,
and it uses just the point I'm making above to feel right and
be faster.I can make parts of the symbols appearing
in the computation be singular-based multivariate polynomials,
and other parts by Ginac formal symbols. It's very very nice.
This is one of the key things Sage has been missing for
a long time to feel complete.
-- William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
On 26/08/2008, at 2:12 PM, William Stein wrote:
I actually don't understand this. For both pynac and the existing
maxima link, I think you must already have some method of
transforming
a python object to and from lisp-like expressions.
Pynac works with objects that are simply expression trees constructed
directly from native Python objects. Literally, if you type, e.g.,
sage: S = var('x',ns=1).parent() # new symbolic ring
sage: foo = S(any_crazy_element_you_can_think_of_in_Sage)^3 + 17
then Pynac constructs an expression tree with a *pointer* in memory
to that any_crazy_element_you_can_think_of_in_Sage. This pointer
setting takes a few nanoseconds.
If shared memory is important to you then lisp won't do. Fair.
Moreover, because of the extreme
flexibility of any_crazy_element_you_can_think_of_in_Sage, you
can do awesome things from this point of view, which are impossible
in maxima via Sage.
Cool. I will try to have a play with ginac and the combination and
see if I can bend it to my Mathematica-will.
D
==
David J Philp
Postdoctoral Fellow
National Centre for Epidemiology and Population Health
Building 62, cnr Mills Rd Eggleston Rd
The Australian National University
Canberra ACT 0200 Australia
T: +61 2 6125 8260
F: +61 2 6125 0740
M: 0423 535 397
W: http://nceph.anu.edu.au/
CRICOS Provider #00120C
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
On Mon, Aug 25, 2008 at 8:58 PM, Tim Lahey [EMAIL PROTECTED] wrote: On Aug 25, 2008, at 11:45 PM, William Stein wrote: The chain rule from calculus says that if f(x) = g(h(x)) then df/dx = (dg/dh) * (dh/dx). Dividing both sides by dh/dx we see that dg / dh = (df /dx) / (dh/dx). I thus suspect that when you say differentiate g(h(x)) with respect to h you might mean to compute dg/dh, as defined by the chain rule above. Yes, but that's a) a horribly inefficient way of doing that and b) in my case, impossible. I don't know h(x) because I'm trying to solve for it. It's the whole point of the system of PDEs. But, dg/dh is easily computable if you have g which I have. The point is that differentiation with respect to a function or a variable should be equivalent. I only meant it as a definition to help clarify the discussion, not as an algorithm. Many thanks for your additional clarification. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
On Aug 26, 2008, at 12:23 AM, William Stein wrote: I only meant it as a definition to help clarify the discussion, not as an algorithm. Many thanks for your additional clarification. William Oh, I misunderstood. If Sage can't take the derivative with respect to a function, I wouldn't be surprised since it isn't a common feature of the various CAS packages I've tried. The Maple code I posted at the start of the thread runs in well less than a second while the built-in Maple code takes about 10s for the same problem because of a poor decision the implementers made. Their code always tries to integrate as the last step even when the DEs can't be integrated so it has to wait for the integration to fail. I think the new pynac code might make implementing some of the things I do easier. I'll see. Cheers, Tim. smime.p7s Description: S/MIME cryptographic signature
[sage-devel] Re: Things I miss from Maple in Sage
On Mon, Aug 25, 2008 at 9:34 PM, Tim Lahey [EMAIL PROTECTED] wrote: On Aug 26, 2008, at 12:23 AM, William Stein wrote: I only meant it as a definition to help clarify the discussion, not as an algorithm. Many thanks for your additional clarification. William Oh, I misunderstood. If Sage can't take the derivative with respect to a function, I wouldn't be surprised since it isn't a common feature of the various CAS packages I've tried. The Maple code I posted at the start of the thread runs in well less than a second while the built-in Maple code takes about 10s for the same problem because of a poor decision the implementers made. Their code always tries to integrate as the last step even when the DEs can't be integrated so it has to wait for the integration to fail. I think the new pynac code might make implementing some of the things I do easier. I'll see. Well I really hope that you implement a bunch of stuff for inclusion in Sage! So far we have very very very few developers working on symbolic differential equations stuff in Sage. (I.e., none, as far as I know.) William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
On Aug 26, 2008, at 12:37 AM, William Stein wrote: Well I really hope that you implement a bunch of stuff for inclusion in Sage! So far we have very very very few developers working on symbolic differential equations stuff in Sage. (I.e., none, as far as I know.) Besides the code I already posted, I have written other variational calculus code. However, I need to work with things on a term-by-term basis so I need access to the expression tree which I couldn't find out how to work with based upon the Sage documentation (e.g., commands like Maple's op allow one to pull apart the symbolic expression term by term). Plus, based upon how integration and differentiation is currently implemented (as I understand it), I'd have to drop into Maxima to do that manipulation. That Euler-Lagrange code is simple example. It consists basically of: 1) Replacing all functions specified with placeholder symbols. 2) Differentiation with respect to those symbols. 3) Reversing the replacement. 4) Differentiation of one expression with respect to time. Since you don't know the number of functions in advance, you need to programmatically create the replacement list and reverse subs list. Both Maple and Maxima can do it fairly simply. Based upon how Sage works, I'm not exactly clear on how to do step 1 which is this Maple code: # create a list of indices from 1 to the number of variables # used in the formulation num_list := [seq(i,i=1..nops(variables))]: # Define a list of generalized velocity and position variables qv_name := map2(cat,qv,num_list): q_name := map2(cat,q,num_list): # Equate the time derivatives of the system variable to the # generalized velocities and also define the reverse mapping vel_var := map(diff,variables,t): qv_subs := zip(equate,vel_var,qv_name): qv_unsubs := zip(equate,qv_name,vel_var): # Equate the generalized positions to the system variables # and define the reverse mapping q_subs := zip(equate,variables,q_name): q_unsubs := zip(equate,q_name,variables): Can I programmatically create a symbolic variable name and use that to replace a symbolic function name? If it's possible, I probably can code the rest in Sage fairly quickly. Then, I'll just be waiting on some of the expression manipulation tools. Cheers, Tim. smime.p7s Description: S/MIME cryptographic signature
[sage-devel] Re: Things I miss from Maple in Sage
You have done a great job highlighting some of the things that are
easy in mathematica and hard in sage. I don't see any answer to your
points in the comments below. I suspect that a fairly serious rewrite
of symbolic expressions will be necessary at some point to help this
situation, but I don't think that it is un-doable in python.
Cheers,
M. Hampton
On Aug 22, 8:21 am, David Philp [EMAIL PROTECTED] wrote:
On 22/08/2008, at 5:27 PM, William Stein wrote:
On Thu, Aug 21, 2008 at 11:28 PM, David Philp
[EMAIL PROTECTED] wrote:
I hope one can't own such things but I don't want a legal fight.
If I were afraid, then Sage would be nowhere today.
I just don't think Mathematica reimplementation is a worthy enough
thing that it's worth risking a legal fight with Wolfram. There are
other ways to make Sage really good.
Otherwise, I agree. A mathematica-like parser would be useful.
Though I'd be surprised if the concepts map across well enough for it
to be anything other than an ugly hack.
Why?
I don't think it's useful for me to keep going much more until I know
more about sage. But I will explain where the bad feeling came from:
All the explanations that sage can do that have involved python
lists, because I used names and examples like 'data = {1, 2, 3}'. But
the power of ReplaceAll (the /. operator) is that it places no
requirements on the form of the 'data' argument.
I.e. the example:
[(0 if d 0 else d) for d in data]
is an illustration of how to write a for-each expression in python,
but it has nothing much to do with ReplaceAll. The difference is that
ReplaceAll is used for transforming 'data' not 'the elements of data'.
E.g.
x + a*y + z[w + v] /. Plus - List
yields {x, a y, z[{v, w}]} (That sort of manipulation has been useful
to me sometimes.)
It reads much the same as before: expr, but with sums replaced by lists.
If someone proposes an implementation I can try and shoot it down or
improve it. But I don't know sage well enough to know whether there
is an obvious way to do it all. My guess is that this is a natural
task for Lisp and the wrong task for Python.
D
==
David J Philp
Postdoctoral Fellow
National Centre for Epidemiology and Population Health
Building 62, cnr Mills Rd Eggleston Rd
The Australian National University
Canberra ACT 0200 Australia
T: +61 2 6125 8260
F: +61 2 6125 0740
M: 0423 535 397
W:http://nceph.anu.edu.au/
CRICOS Provider #00120C
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
Tim Lahey wrote:
\frac{d}{d t}\left(\frac{\partial L}{\partial \dot{q_i}}\right)
= \left(\frac{\partial L}{\partial q_i}\right)
where i=1,...,n and L(q_i,\dot{q_i},t). Note that q_i
is a function of at least t. This is the Euler-Lagrange
equation. It's the basis for most advanced dynamics.
So, I want to differentiate L with respect to \dot{q_i) and
q_i as if they were just x and t in a normal derivative.
This is why my code replaces the functions with symbols and
then takes the derivative with respect to these placeholder
symbols and then reverses it.
FWIW Maxima likes to see dy/dx in formulations of
differential equations instead of dy(x)/dx so I think maybe
this problem of whether y is a variable or a function doesn't
really come into play; Maxima can always handle y as a
variable. You could ask on the Maxima mailing list to see
if anyone has worked with Lagrangian mechanics in Maxima.
Robert Dodier
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
On Aug 26, 2008, at 1:24 AM, Robert Dodier wrote: FWIW Maxima likes to see dy/dx in formulations of differential equations instead of dy(x)/dx so I think maybe this problem of whether y is a variable or a function doesn't really come into play; Maxima can always handle y as a variable. You could ask on the Maxima mailing list to see if anyone has worked with Lagrangian mechanics in Maxima. Robert Dodier Thanks. However, It's not y(x) that's the problem, it's that the x may be a function and I need the derivative carried out. However, the code you translated should handle it. Cheers, Tim. smime.p7s Description: S/MIME cryptographic signature
[sage-devel] Re: Things I miss from Maple in Sage
On Aug 26, 2008, at 1:14 AM, William Stein wrote:
Sounds good. Unfortunately I don't understand precisely what
you're asking for. Do you want to do this?
sage: x = var('x', ns=1)
sage: from sage.symbolic.function import function
sage: foo = function('foo',1)
sage: expr = foo(x)^2 + foo(x)-1
sage: expr
foo(x) + foo(x)^2 - 1
sage: y = var('y')
sage: expr.subs(foo(x)==y)
y^2 + y - 1
This *already* works in the new pynac symbolics. I just typed it in.
Of course, I'm skipping the programatically part...
It's the programatically part that makes it a bit more difficult.
so imagine doing this with foo1 through foon and y1 through yn. So,
I need to create y1 through yn as needed. I'm not sure how to do
that since n is only known when the list of foo is read.
Cheers,
Tim.
smime.p7s
Description: S/MIME cryptographic signature
[sage-devel] Re: Things I miss from Maple in Sage
On Mon, Aug 25, 2008 at 10:28 PM, Tim Lahey [EMAIL PROTECTED] wrote:
On Aug 26, 2008, at 1:14 AM, William Stein wrote:
Sounds good. Unfortunately I don't understand precisely what
you're asking for. Do you want to do this?
sage: x = var('x', ns=1)
sage: from sage.symbolic.function import function
sage: foo = function('foo',1)
sage: expr = foo(x)^2 + foo(x)-1
sage: expr
foo(x) + foo(x)^2 - 1
sage: y = var('y')
sage: expr.subs(foo(x)==y)
y^2 + y - 1
This *already* works in the new pynac symbolics. I just typed it in.
Of course, I'm skipping the programatically part...
It's the programatically part that makes it a bit more difficult.
so imagine doing this with foo1 through foon and y1 through yn. So,
I need to create y1 through yn as needed. I'm not sure how to do
that since n is only known when the list of foo is read.
What is the list of foo? Is n just the length of a list? Do you
want to do something like this?
sage: y = [var('y%s'%i) for i in range(10)]
sage: y
[y0, y1, y2, y3, y4, y5, y6, y7, y8, y9]
sage: expr.subs(foo(x) == y[3])
y3^2 + y3 - 1
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
On Aug 26, 2008, at 1:43 AM, William Stein wrote:
On Mon, Aug 25, 2008 at 10:28 PM, Tim Lahey [EMAIL PROTECTED]
wrote:
It's the programatically part that makes it a bit more difficult.
so imagine doing this with foo1 through foon and y1 through yn. So,
I need to create y1 through yn as needed. I'm not sure how to do
that since n is only known when the list of foo is read.
What is the list of foo? Is n just the length of a list? Do you
want to do something like this?
sage: y = [var('y%s'%i) for i in range(10)]
sage: y
[y0, y1, y2, y3, y4, y5, y6, y7, y8, y9]
sage: expr.subs(foo(x) == y[3])
y3^2 + y3 - 1
Basically, there will be a list of foo_i(x). It looks like the above
will work because you can get the length of the list. Then, you just
need to make a list of substitutions of foo_i(x) == y[i].
I think I can make it work. I might get around to trying it tomorrow.
Thanks,
Tim.
smime.p7s
Description: S/MIME cryptographic signature
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Aug 25, 2008, at 1:59 AM, William Stein wrote: Hi, I propose that pynac be included in Sage. Pynac is a rewrite of Ginac to seamlessly use native Python objects instead of CLN -- for inclusion in Sage. Pynac is a C++ library plus extensive Cython bindings. Pynac is about 30K lines, is very well documented and commented, and as C++ code goes is extremely readable. VOTE: [x] Yes, include Pynac in Sage [ ] No, do not (please explain) [ ] Hmm, I have questions (please ask). Very enthusiastic about this! --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Manipulating diff. eqs. in Mathematica using pattern matching
On Mon, Aug 25, 2008 at 7:42 PM, William Stein [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 3:08 PM, David Philp [EMAIL PROTECTED] wrote: On 26/08/2008, at 2:50 AM, William Stein wrote: Burcin -- I did actually mostly implement pattern matching in Pynac. Is there documentation? A bit of google turned up nothing. (1) Let me clarify -- I *wrapped* the pattern matching already in Pynac. (2) I made up the name pynac about 3 days ago, and released the first version 15 hours ago. This is code that will be included in Sage. There was a long sage-devel post about this last night. So I doubt Google will find anything.Incidentally, Pynac = Ginac + Python - CLN, and you can read about Ginac at the Ginac website: http://www.ginac.de/ sage: sin(1+sin(x)).subs(sin(w0)==cos(w0)) cos(cos(x) + 1) In Mathematica, the result would be cos(sin(x) + 1), since having matched the outer expression, the replacement algorithm moves on rather than in. One would obtain cos(cos(x) + 1) by making the substitution rule sin==cos. Can you do that? Can you evaluate code during the matching of your patterns? Can you nest patterns? I think these are highly desirable, even if they are suitably carefully hidden from the casual user. I didn't implement the pattern matching. I wrapped the pattern matching that is provided by GiNaC. It is certainly not identical to the pattern matching in Mathematica, at present. I'm glad you're pointing out some of the differences between what is in Mathematica and what is in Ginac. Thanks! We already have a pretty good symbolic engine in Sage, maxima does quite a good job of solving integrals, limits, etc. The main problem with Maxima is that we cannot extend it. Is not extending of Maxima a concrete policy? Maxima is definitely not the future of symbolic manipulation *in Sage*: (1) Maxima cannot manipulate native Python objects (e.g., real interval field elements, number field elements, finite field elements); both Pynac and sympy can. (2) Maxima is written in Lisp. This is a total show stopper for most Sage developers, including me. Both apply to Axiom, too, by the way. Tim Daly just wrote to me off list about this remark: Users [of axiom] never see Lisp code. I realize you don't like Axiom and don't plan to use it in Sage. But I would ask you to at least keep your facts straight when criticizing Axiom in public. -- Tim (a) I'm not criticizing Axiom. I'm saying that it doesn't have two properties that are relevant to it being used for a certain aspect of symbolic manipulation in Sage itself, since the original poster seemed to not understand what the issues are.I do not think this makes Axiom (or Maxima) in any way bad -- it's just that they aren't the right tool to solve a certain problem. (b) I do not dislike Axiom. In fact, I really like a wide range of software, including Axiom. (c) I made two claims above which you seem to dispute: (1) Axiom cannot manipulate native Python objects. [[I think this is true]] (2) Axiom is written in Lisp. [[I think there is some truth to this.]] In (2) I didn't say that users use Lisp to work with Axiom, just like they don't use Lisp to program Maxima. But the discussion is about extending the core functionality of the system rather than just writing user-level code, so I thought that was justified. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Things I miss from Maple in Sage
On Mon, Aug 25, 2008 at 10:48 PM, Tim Lahey [EMAIL PROTECTED] wrote:
On Aug 26, 2008, at 1:43 AM, William Stein wrote:
On Mon, Aug 25, 2008 at 10:28 PM, Tim Lahey [EMAIL PROTECTED] wrote:
It's the programatically part that makes it a bit more difficult.
so imagine doing this with foo1 through foon and y1 through yn. So,
I need to create y1 through yn as needed. I'm not sure how to do
that since n is only known when the list of foo is read.
What is the list of foo? Is n just the length of a list? Do you
want to do something like this?
sage: y = [var('y%s'%i) for i in range(10)]
sage: y
[y0, y1, y2, y3, y4, y5, y6, y7, y8, y9]
sage: expr.subs(foo(x) == y[3])
y3^2 + y3 - 1
Basically, there will be a list of foo_i(x). It looks like the above
will work because you can get the length of the list. Then, you just
need to make a list of substitutions of foo_i(x) == y[i].
I think I can make it work. I might get around to trying it tomorrow.
Do complain if you can't. Also, let meknow if you have trouble installing
pynac -- it's very new (1 day old!) so installation might not just work yet
on all Sage-supported platforms.
-- William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Aug 25, 2008, at 8:35 AM, Gary Furnish wrote: I've been trying to get an answer for this question for the last few weeks: Is the plan to extend ginac (write algorithms in C) or to extend sage (write new algorithms in Sage) using cython/python? I don't think this was addressed in the email, but my understanding is that the plan is very much the latter. Perhaps (I hope) that much of this will not be re-implementation so much as porting SymPy algorithms/getting SymPy to run on top of GiNaC. This is very much a design related question, and in the hurry to get GiNaC through review I feel that design issues and questions have been very much ignored. To put the question somewhat differently, are algorithms using the new symbolics system going to be use GiNaC/pynac enough that switching to any other low level system will be very, very difficult (because new code such as sums may depend directly on GiNaC specific behavior)? If this is not intended, what will be done to try to prevent Sage from becoming overly dependent on GiNaC in the long term? --Bill --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
