[sage-devel] Re: License of Wiki Content
On 7/7/07, David Joyner [EMAIL PROTECTED] wrote: I'm happy with the Attribution-ShareAlike Creative Commons license: http://creativecommons.org/licenses/by-sa/2.0/ I think there is also a GPL Documentation license which is similar. + On 7/7/07, Martin Albrecht [EMAIL PROTECTED] wrote: do we have a license on the SAGE Wiki content? I am not so firm when it comes to documentation licenses, but basically I would like it to be as open as possible, e.g. it should be possible to put Wiki content in a book (with proper credits). How about the documentation in general? Regarding the pdf documents, David Joyner is the principal author of the constructions documents, and he and I are the main authors of the tutorial. I'm the main author of the install guide and programming guide (though Ifti B. and others have done a lot of work improving the programming guide). I think it will be good if we do the following: (1) I propose that David and I explicitly license all the current paper documentation under the the Creative Commons license that David suggested above (though version 3.0, probably, since it's newer: http://creativecommons.org/licenses/by-sa/3.0/ -- this site doesn't work for me right now). (2) We do so by including a statement to this effect in some sort of page at the beginning of the tex file for each document, and this change be included in the (long overdue -- sorry!) SAGE-2.7 release. (3) We state also that by making an explicit contribution to the SAGE wiki or the SAGE documentation, that ones contribution is licensed under the Create Commons 3.0 license. This should be prominently displayed on the SAGE wiki home page. (4) Nonetheless, regarding (3), we still worry about getting explicit license statements, especially for large contributions. (5) We apply the same approach to JSAGE: http://www.sagemath.org/jsage/ Yes, JSAGE is currently dead, but I'm certain it will turn out to be very important in the long run, once I figure out how to really make it useful. In fact, I think perhaps the best thing would be something like this page: http://www.math.uiuc.edu/Macaulay2/Publications/ but for every publication there would be an additional 5 page (or so) paper that we have with additional code, examples, etc. I.e., JSAGE would be like an extremely annotated bibliography of the use of SAGE in mathematical research. By the way, the middle of this page: http://www.math.uiuc.edu/Macaulay2/ has a fascinating quote by 2006 Fields Medalist Andrei Okounkov calling for funding agencies to fund non-commercial math software. (David Joyner -- should we put that quote in our NSF white paper?) Thoughts? Martin Thanks for asking before it's too late. Now is a great time to clarify the situation. -- 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: predefined symbolic variable names
2007/7/8, Hamptonio [EMAIL PROTECTED]: My biases are probably based on using mathematica for 17 years, but I like the way it handles numerical vs symbolic computations. So at present, in sage, sin(1) is symbolic, and sin(1.0) is numerical, and +1, I like this behavior as well. And I like that currently you can mix both symbolic and numerical types (e.g. in polynomial expressions). this I think is good. What I think is bad is that something like 1.0*sin(1) is not numerical - in mathematica the sin(1) would be Some people like symbolic expression, some like numerical expressions for the above case :) . This is off-topic: given a floating-point number, I think it would be cool to have a way of telling users, BTW,34.0191213743 is quite close to 7*(pi + e - 1) in the field you're working with. This is probably very hard. 2007/7/7, William Stein [EMAIL PROTECTED]: So I propose that the only symbolic variables that are predefined are x (since it's so useful to have this predefined), I (=sqrt(-1)), and e (=2.7...). What about pi? :) . It seems to me that pi is as special as e. 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] axiom and sage
Hello all: Recently there as been a divisive discussion on the Axiom deveopers list which has led to an Axiom fork. Two lead developers, Martin Rubey and Waldek Hebisch quit. Both are extraordinarily talented programmers and Martin is the author of GUESS, a unique and important package which I described in http://www.sagemath.org:9001/Axiom_as_an_OSCAS The posts labels with fork or fricas at http://blog.gmane.org/gmane.comp.mathematics.axiom.devel/ contain some of the relevant threads. I'll leave it to others to summarize the discussion, I found it rather sad and somewhat shocking. I would like to open up a partnership with these and other Axiom developers and SAGE, in the hopes of eventually adding to SAGE the CAS functionality which is unique to Axiom. In the hopes of heading off any developer conflicts which echo the recent fork, I'd like to open up a discussion on how this might be structured. Some ideas: 1. Assuimg Axiom becomes part of SAGE, all Axiom patches are to be voted on democratically among the Axiom deveopers. (Majority rules.) 2. If/when there is an agreement in principal to begin a SAGE/Axiom partnership, hopefully including at least (in alphabetical order) Waldek Hebisch, Ralf Hemmecke, Bill Page, and Martin Rubey on the Axiom side, I could (or someone else could) start a sage-axiom googlegroups list. 3. Finally, thanks to google, I found a paper which states that Axiom is a trademark of NAG. Whether this is true or not, or whether this affects what this potential sage-axiom fork should be called, may be worth discussing. I have no strong opinions except that I think a partnership can be potentially very exciting and advantageous for both sides. If there is anything I can do, within my limited abilities, I'll be happy to help. Any comments on any of this? - David Joyner --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 2.7 alpha^2?
On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hey William, can you set up a mercurial server to serve up the branch that
you'll most likely release?
Yes, that's maybe a good idea, though this directory has *everything* needed
to upgrade to sage-2.7.alpha, along with a README.txt that describes what
to do. The issue is that certain spkg's have to be installed etc.,
it's not just
a matter of pulling from a single repo:
http://sage.math.washington.edu/home/was/sage2.7/
Also, what are you waiting for? Is there a todo list that other people can
help with?
My main wait right now is that I'm trying to force myself to go on
vacation for a few
days, since I really need a break! However, if you look at the
notes.txt file it lists the
main points, which I'll resummarize here:
(1) I need to make some clever hacks to get the Fortran stuff to work on
PowerPC OSX. Josh K and I figured these out last week, but they
are just sitting somewhere on Justin Walker's computer.
(2) There are some issues remaining with the new SAGE notebook:
(a) Auto-opening of next available port needs to be implemented
(b) I suspect running two SAGE notebooks from the same directory
might not correctly give a lock message.
(3) In the latest version only the symbolic variable x is
predefined -- nothing else.
Because of this, many doctests in calculus/* will break, and
need to be fixed
by putting explicit var('...') lines in.
(4) There are a number of other doctest failures elsewhere.
There are numerous patches I haven't applied yet, but they can wait
for SAGE-2.7.1.
Thus, somebody could help right now immensely by:
(1) posting to the list saying they are going to right now fix all
the calculus doctests (i.e., get a lock),
(2) apply the above patches then do sage -t in the calculus directory,
(3) fix all the problems,
(4) send me the resulting patch, which at least fixes most of them.
Something similar could be done for the doctests in rings, etc. Some
doctests might be
quite hard to fix, but most are probably very easy.
Somebody could also try to fix the notebook port issues. Basically,
one needs to figure
out how in Python to find the next port with number = n that is
available. This is a basic
Python question that has nothing to do with SAGE really. Once
somebody posts code
to do this, fixing that issue with the notebook is easy.
Once the above issues are resolved, I do sage -sdist 2.7.alpha, get
a source tarball,
and we build it on lots of test machines, then run all doctests again.
Then I release
sage-2.7.
-- William
The mozilla people have a nightly build that they suggest you download and
test before reporting a bug. Should we institute such a policy?
--
William Stein
Associate Professor of Mathematics
University of Washington
http://www.williamstein.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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: axiom and sage
On 7/8/07, Ralf Hemmecke [EMAIL PROTECTED] wrote: Some ideas: 1. Assuimg Axiom becomes part of SAGE, all Axiom patches are to be voted on democratically among the Axiom deveopers. (Majority rules.) Any comments on any of this? Do you work in sage like that majority rules? I know that I simply feel unable and therefore not very well if I have to vote on a patch that I don't understand. No. The way it works in SAGE is that you submit a patch. If it is your own work (eg, not a bug fix requested by William), he will send it to a referee http://www.sagemath.org/jsage/editors.html who checks it over, offers suggestions, etc. The goal is to have a refereeing job done within a week. All new code must have preworked examples in the docstring which are automatically run using a command sage -t filename. These examples must be representative of typical useage and must work (ie, must pass all doctests). Basicaly the referee checks these and perhaps perhaps makes suggestions for small improvements to the code. Once the patch is approved by the referee, the referee then sends it back to William and it is included. If it is not your own work (eg, a requested new feature), then some times a long discussion and voting takes place on sage-devel, after a call for comments-type email is posted. Of course, if you don't know or care about the feature then don't vote. However, William can over-rule votes. I can't remember the last time that happened. Something about a suggested implementation being inconsistent with a feature or goal of SAGE I think. I really think it was a case of William just knowing the system better than anyone else and making the proper decision, but I can't remember the details. I know that Waldek has done a lot of good work for Axiom, but I have not looked at even one of his patches. I somehow don't think that voting by majority is a good strategy. Does a referee-style system, perhaps in addition to a call for comments post to an email list, seem reasonable? I have seen that LYX developers need at least two OKs until a patch is accepted to trunk. That I find quite OK, but it is all a question of what policy should be accepted and how many developers are actually watching and contributing. Ralf --~--~-~--~~~---~--~~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: predefined symbolic variable names
2007/7/7, William Stein [EMAIL PROTECTED]:
So I propose that the only symbolic variables that are predefined
are x (since it's so useful to have this predefined), I (=sqrt(-1)),
and e (=2.7...).
I myself prefer to import everything by hand in Python. Thus the sage
module can have many things (even all letters) preloaded, because
there cannot be any confusion -- I want to use it like this:
from sage import e, I, sin, x
print I*sin(x)
and actually even the x is kind of confusing, in SymPy we need to
create it by hand, like x=Symbol('x'). Then there can be some very
limited environment, that imports some things automatically, for
example isympy (which is just ipython) in our project does
from sympy import *
x = Symbol(x)
y = Symbol(y)
z = Symbol(z)
at the beginning automatically, so that one can use it interactively.
But for any serious working, I prefer to do it by hand from my own
script. Like any other python library.
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: predefined symbolic variable names
Hi,
Thanks for all the feedback from everybody about symbolic variables,
special functions, etc. For now (i.e., the very near term), I think
the best thing to do is:
(1) remove all predefined *symbolic* variables except x,
leave in e, pi, and I:
-- everybody basically wants this.
(2) don't make any changes to how special functions behave.
-- doesn't seem necessary.
(3) don't make any changes to how floating point literals behave.
-- basically put making any changes here on hold, since
substantial discussion still hasn't revealed a
sufficiently good solution.
If one wants purely C-library float special functions,
doing, e.g.,
from math import sin, cos, tan
etc., works very well right now. And using float(2.5) or 2.5r
works fine now.
I'm intrigued by Marshall's remark about What I think is bad is
that something like 1.0*sin(1) is not numerical - in mathematica
the sin(1) would be forced into a numerical type.
Here's what Maxima/Mathematica/Maple/Mupad do:
sage: maxima.eval('2.5*sin(1)')
'2.5*sin(1)'
sage: mathematica.eval('2.5*Sin[1]')
2.10368
sage: maple.eval('2.5*sin(1)')
'2.5*sin(1)'
sage: mupad.eval('2.5*sin(1)')
2.5 sin(1)
Here's what SAGE does:
sage: 2.5*sin(1)
2.50*sin(1)
Here's what REDUCE does -- which is totally different
(and nuts, IMHO):
1: 2.5*sin(1);
5*sin(1)
--
2
So Mathematica is in fact the only system that makes sin(1)
symbolic but 2.5*sin(1) numerical. I.e., Maple, SAGE, Mupad,
and Reduce all tend toward 2.5*sin(1) being as symbolic as
possible for some reason.
From an implementation point of view, given the SAGE rules,
it makes way more sense for 2.5*sin(1) to remain symbolic,
since:
(1) this is what the backend simplification system (maxima) does,
and
(2) 2.5 * sin(1) in SAGE is computed by making 2.5 symbolic,
then doing the multiply formally.
I'm not saying we shouldn't find a way to make 2.5 * sin(1) possibly
be numerical. I'm just remarking that this is a complicated issue
and it definitely deserves further discussion.
-- 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
