[sage-devel] Re: emacs support
On Jul 6, 8:38 pm, iSAGE [EMAIL PROTECTED] wrote: (load /usr/local/bin/sage) Try changing this back to (load sage) (Doing (load /usr/local/bin/sage) tries to load a shell script as if it were an Emacs Lisp program; this fails quickly, because the very first character of the shell script is a #, which is illegal in Emacs Lisp. Doing (load sage) instead tries to find an Emacs Lisp program in your load-path, so it will load /home/chandu/.emacs-scripts/ sage.elc.) Carl Witty --~--~-~--~~~---~--~~ 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] predefined symbolic variable names
Hi,
I just taught a very intense two week workshop on the Riemann Hypothesis
to 24 bright high school students, in which we used SAGE quite a lot
each day for 2.5 hours (http://wstein.org/simuw/). I'm now very
seriously considering some changes to SAGE as a result.
The first is *removing* having predefined symbolic variable
names. I.e., in SAGE right now the variables a..z and A..Z
are prdefined at startup to be symbolic variables (except for I
and e).
This has been discussed several times before on
this list, and in the past I always argued for them. However,
after having watched many actual people using SAGE during
the last two weeks, I have changed my mind. The following
sort of thing happened frequently day after day:
I would make a predefined notebook cell or function or
something like this:
{{{
def R(x):
...
}}}
and students would forget to evaluate it. They would still
try to do things like plot(R, 0, 10), and they would end
up getting the identity function, which was very confusing.
This *constantly* happened.An error message that R
isn't defined would have been vastly superior.
Another problem, is that doing, e..g,
v = [y for y in w]
would turn y into the last value in w. It would no longer
be symbolic. So in writing code for the students, I could
never rely on predefined symbolic variables being defined.
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...).
If users want a symbolic variable, they have to use the var command.
One other thing that surprised me was
(1) how little all the symbolic code in SAGE was actually useful for
the workshop,
(2) how annoying it was not having decimal literals be floats by default, and
(3) how annoying it was having certain special functions, e.g.,
log, sin, cos, etc., return symbolic values by default
instead of numerical values.
I.e., Perhaps I'm starting to see why MATLAB is more popular than
Maple/Mathematica for a lot of classes, and I'm starting to wonder if
SAGE should by default tend toward
being less symbolic, though it should still have all that
functionality easily available.
Don't worry -- I'm not gong to make any drastic changes without some significant
feedback. So please, if you have thoughts on the above, let me know!
--
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] Fwd: [sage-devel] predefined symbolic variable names
On 7/7/07, William Stein wrote: ... 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...). If users want a symbolic variable, they have to use the var command. ... In my opinion there should be *no* predefined symbols. For me even having only these 3 symbols predefined would lead to some initial confusion. I would very much prefer that it be necessary to ask that these things be defined via a single import or other initialization at the top of each notebook/sage session. Then the first question one asks is What is this thing at the start of the notebook page? And the simple answer makes everything clear. --~--~-~--~~~---~--~~ 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
On 7/7/07, William Stein [EMAIL PROTECTED] wrote:
Hi,
I just taught a very intense two week workshop on the Riemann Hypothesis
to 24 bright high school students, in which we used SAGE quite a lot
each day for 2.5 hours (http://wstein.org/simuw/). I'm now very
seriously considering some changes to SAGE as a result.
The first is *removing* having predefined symbolic variable
names. I.e., in SAGE right now the variables a..z and A..Z
are prdefined at startup to be symbolic variables (except for I
and e).
This has been discussed several times before on
this list, and in the past I always argued for them. However,
after having watched many actual people using SAGE during
the last two weeks, I have changed my mind. The following
sort of thing happened frequently day after day:
I would make a predefined notebook cell or function or
something like this:
{{{
def R(x):
...
}}}
and students would forget to evaluate it. They would still
try to do things like plot(R, 0, 10), and they would end
up getting the identity function, which was very confusing.
This *constantly* happened.An error message that R
isn't defined would have been vastly superior.
Another problem, is that doing, e..g,
v = [y for y in w]
would turn y into the last value in w. It would no longer
be symbolic. So in writing code for the students, I could
never rely on predefined symbolic variables being defined.
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...).
If users want a symbolic variable, they have to use the var command.
I vote for the Macaulay variables (RR, QQ, ZZ, etc) to be
predefined. I don't care about e but I prefer I to Python's
J or j for sqrt(-1).
In general, I agree with you that user friendliness is very important.
One other thing that surprised me was
(1) how little all the symbolic code in SAGE was actually useful for
the workshop,
(2) how annoying it was not having decimal literals be floats by default, and
(3) how annoying it was having certain special functions, e.g.,
log, sin, cos, etc., return symbolic values by default
instead of numerical values.
Does having two functions, eg Sin (symbolic) and sin (numerical),
make sense?
I.e., Perhaps I'm starting to see why MATLAB is more popular than
Maple/Mathematica for a lot of classes, and I'm starting to wonder if
SAGE should by default tend toward
being less symbolic, though it should still have all that
functionality easily available.
Don't worry -- I'm not gong to make any drastic changes without some
significant
feedback. So please, if you have thoughts on the above, let me know!
--
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: predefined symbolic variable names
On Jul 7, 2007, at 10:44 , William Stein wrote: 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...). If users want a symbolic variable, they have to use the var command. I prefer having nothing defined, although I suppose a case could be made for 'e' and 'I'. If 'x' is pre-defined, then one could as why not 'y'?, and it's downhill from there :-} Having an explicit var() in a computation/script seems preferable. On this subject, the question of protection for variable names was raised earlier, but I don't recall the outcome. One other thing that surprised me was (1) how little all the symbolic code in SAGE was actually useful for the workshop, This, I think, really depends on the user's habits, and it's really difficult to predict. I often take advantage of the symbolic stuff, but then I sometimes trip over it. Having it optional, as above, may be the best we can do. (2) how annoying it was not having decimal literals be floats by default, and (3) how annoying it was having certain special functions, e.g., log, sin, cos, etc., return symbolic values by default instead of numerical values. On this one, I'm neutral. How many configuration/usage options can we have before it starts getting too complex to deal with? Justin -- Justin C. Walker, Curmudgeon at Large Director Institute for the Enhancement of the Director's Income --- Nobody knows the trouble I've been --- --~--~-~--~~~---~--~~ 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
On 7/7/07, Justin C. Walker [EMAIL PROTECTED] wrote:
On Jul 7, 2007, at 10:44 , William Stein wrote:
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...).
If users want a symbolic variable, they have to use the var command.
I prefer having nothing defined, although I suppose a case could be
made for 'e' and 'I'. If 'x' is pre-defined, then one could as why
not 'y'?, and it's downhill from there :-}
Not having x predefined would be reasonable. It has always been
predefined since SAGE-0.9, mainly because it makes it much easier
to create number fields, etc. However, it can lead to code and
examples that really make me nervous. For example, if one
things the standard way to make a number field is:
K.a = NumberField(x^3 + 1)
but one happens to define x to be a number or something
else in a session, e.g., by using x as a looping variable, e.g.,
for x in object:
print x
then there are problems. It's probably much better to think
that the following are ways to make a number field:
x = polygen(QQ)
K.a = NumberField(x^3 + 1)
or
x = var('x')
K.a = NumberField(x^3+1)
Having an explicit var() in a computation/script seems preferable.
Yep.
On this subject, the question of protection for variable names was
raised earlier, but I don't recall the outcome.
I think this sort of thing just doesn't work -- and shouldn't even be attempted
-- since Python is a dynamically typed language, so types and values
of a variable can (and must be allowed to) change at any time, unlike
with a statically typed language.
One other thing that surprised me was
(1) how little all the symbolic code in SAGE was actually useful for
the workshop,
This, I think, really depends on the user's habits, and it's really
difficult to predict. I often take advantage of the symbolic stuff,
but then I sometimes trip over it. Having it optional, as above, may
be the best we can do.
(2) how annoying it was not having decimal literals be floats by
default, and
(3) how annoying it was having certain special functions, e.g.,
log, sin, cos, etc., return symbolic values by default
instead of numerical values.
On this one, I'm neutral.
How many configuration/usage options can we have before it starts
getting too complex to deal with?
0. We don't have any configuration/usage options and we shouldn't.
I'm just trying to figure out what the best 1 default option will be.
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
On Jul 7, 2007, at 10:44 AM, William Stein wrote: The first is *removing* having predefined symbolic variable names. I.e., in SAGE right now the variables a..z and A..Z are prdefined at startup to be symbolic variables (except for I and e). +1 for nothing but e, I, and x defined by default. This has caused me much more frustration than it has helped. (There should be an easy way to import all of a-z,A-Z however). Ideally, e would be an element of a lazy real field, x an element of ZZ['x'] (if I want to do something quick, having x handy is really nice, and almost everyone tries to create/factor/integrate a polynomial the first time they try SAGE), and I an element of the Gaussian integers. Having to define these every time does get tedious. (2) how annoying it was not having decimal literals be floats by default, and -1. I've probably given you enough feedback on this matter already... (3) how annoying it was having certain special functions, e.g., log, sin, cos, etc., return symbolic values by default instead of numerical values. I mostly to agree here that sin(1) = 0.841470984807897 is more useful, but one concern is how one would get the symbolic sin(1) if one wanted it. Regarding (2), would the return value be float? Could one specify the precision? Would asin(sqrt(3)/2) still be pi/3? (I think so.) What about sqrt? I don't think that behavior should revert back to a floating point. Maybe have two ways to call the function/two functions (one symbolic like now, one numeric)? - 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: emacs support
Thank you. Your suggestion worked. Bhalchandra Thatte (load /usr/local/bin/sage) Try changing this back to (load sage) Carl Witty --~--~-~--~~~---~--~~ 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
Strongly support having as few predefined variables as possible. The
closer to zero the better. Honestly I would even prefer the entire
startup namespace to be as empty as possible; I would rather have to
import EllipticCurve, NumberField, etc than have them pre-loaded. I
know I won't get my way, but that's just my two cents.
david
On Jul 8, 2007, at 3:44 AM, William Stein wrote:
Hi,
I just taught a very intense two week workshop on the Riemann
Hypothesis
to 24 bright high school students, in which we used SAGE quite a lot
each day for 2.5 hours (http://wstein.org/simuw/). I'm now very
seriously considering some changes to SAGE as a result.
The first is *removing* having predefined symbolic variable
names. I.e., in SAGE right now the variables a..z and A..Z
are prdefined at startup to be symbolic variables (except for I
and e).
This has been discussed several times before on
this list, and in the past I always argued for them. However,
after having watched many actual people using SAGE during
the last two weeks, I have changed my mind. The following
sort of thing happened frequently day after day:
I would make a predefined notebook cell or function or
something like this:
{{{
def R(x):
...
}}}
and students would forget to evaluate it. They would still
try to do things like plot(R, 0, 10), and they would end
up getting the identity function, which was very confusing.
This *constantly* happened.An error message that R
isn't defined would have been vastly superior.
Another problem, is that doing, e..g,
v = [y for y in w]
would turn y into the last value in w. It would no longer
be symbolic. So in writing code for the students, I could
never rely on predefined symbolic variables being defined.
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...).
If users want a symbolic variable, they have to use the var command.
One other thing that surprised me was
(1) how little all the symbolic code in SAGE was actually useful for
the workshop,
(2) how annoying it was not having decimal literals be floats by
default, and
(3) how annoying it was having certain special functions, e.g.,
log, sin, cos, etc., return symbolic values by default
instead of numerical values.
I.e., Perhaps I'm starting to see why MATLAB is more popular than
Maple/Mathematica for a lot of classes, and I'm starting to wonder if
SAGE should by default tend toward
being less symbolic, though it should still have all that
functionality easily available.
Don't worry -- I'm not gong to make any drastic changes without some
significant
feedback. So please, if you have thoughts on the above, let me know!
--~--~-~--~~~---~--~~
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] License of Wiki Content
Hi there, 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? Thoughts? 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: License of Wiki Content
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: Hi there, 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? Thoughts? 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
