Re: Calculus
William Stein
I have recently discovered SAGE, which I think is really quite amazing.
I am contemplating introducing the students in our honors calculus course
here at Dartmouth to SAGE. I'm a bit leery about this, since I'm new to SAGE
myself. I'm wondering if you can suggest materials (e.g. sample worksheets)
I could crib from.
The time might not quite by right for doing this, since there isn't very much
written about using SAGE for calculus beyond the reference manual chapter,
which you already know about. I will teach calculus 1 year from now, and have
my own very nice notes (which I made by sitting in on the best calculus teacher's
class at UCSD), and will change them to use SAGE. But that project is a
year away. I'm not aware of anybody else creating extensive notes on using
SAGE for calculus yet. (I'm cc'ing this to sage-devel -- if anybody there has
any comments, please make them.)
That said, one of the main longterm goals of SAGE is to provide a viable alternative
to Maple, Mathematica, Matlab, and Magma, and for that to happen being up
to snuff for calculus teaching is very important. (For me longterm means "about
a year".)
Some observations about SAGE.
-- It would be great to have a short, simple description of
how to save and retrieve worksheets. And maybe there could be an
`Open Worksheet' option on the file menu, right below `New Worksheet',
where it usually comes. It took be the longest time to find the `Home' button!
I agree. This has bugged me too. This is now trac ticket #682:
http://trac.sagemath.org/sage_trac/ticket/682
-- It's still far from clear to me what `downloading' and `uploading' are
supposed to mean.
It's supposed to be exactly the same as "save" and "open". Maybe I should
change the names to "save" and "open"? Right now the terminology just
follows Google Documents (which inspired much of the notebook's layout).
-- When I install an updated version of SAGE, my old worksheets aren't
available. I've been finding them, opening them with a text editor, and
copying the text into a new worksheet. I bet there is a better way.
That's very weird.
There was some slight change in the root account versus admin account
that might be responsible for this. It never happen again in the future.
-- I think that the Python convention of not including the upper bound
in a sum is a real problem.
sage: sum(i for i in range(1,10))
45
I understand this is a fundamental convention in Python, and that it is very
natural for people used to malloc(), but I worry that this will be a constant
headache for students (and professors!).
Indeed, this is perhaps one of _the_ fundamental conventions.
SAGE understands that I want to
include the upper limit when I ask for a taylor series:
sage: taylor(exp(x),x,0,3)
1 + x + x^2/2 + x^3/6
Maybe that is a bug? :-)
But in a sum it pretends not to understand what I mean. I guess I could
define `myrange' to include the upper bound. But I think it would be better
if you could come up with a nice, clean way to protect users from
this aspect of Python, as you have protected us from other aspects
(like ^, /, long integers).
it would be easy to do this:
sage: import __builtin__; range = lambda a,b: __builtin__.range(a,b+1)
sage: range(1,10)
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
However, I am pretty sure people would complain about that way way
more than they complain about the current situation, especially because
a huge amount of code from books on Python wouldn't work anymore.
There is a good reason range is defined the way it is in Python.
With the above, you have to do funny things like this, i.e., put
in len(v)-1, which is equally unnatural:
sage: v = [1,5,17]
sage: for i in range(0,len(v)-1): print v[i]
....:
1
5
17
A better solution would, as you suggest, to define a function like
range -- but not called range -- that includes both endpoints.
One possibly nasty possibility would be to allow Magma-like
notation:
sage: [1..4]
[1, 2, 3, 4]
so the above might be a reasonable option.
How does one specify an integer range in Maple, Mathematica, Maxima?
-- Speaking of long integers, I think this is probably a bug:
sage: sum(i for i in xrange(10^6))
499999500000L
That is not a bug. Python's native long integer type has the unfortunately
very annoying property that it prints with an L suffixed. You can make it
back into a regular SAGE integer by doing the following:
sage: Integer(sum(i for i in xrange(10^6)))
499999500000
Some remarks:
* Small Python integers (like in the sum above) are much faster for arithmetic
than SAGE's large integer type (Integer).
* SAGE's large integer type is vastly faster than Python's integers when the
integers are big. It's based on GMP.
* You could do the sum above entirely with SAGE GMP integers using the
xsrange command, but it would be much slower:
sage: time sum(i for i in xrange(10^6))
CPU times: user 0.10 s, sys: 0.01 s, total: 0.11 s
Wall time: 0.11
499999500000
sage: time sum(i for i in xsrange(10^6))
CPU times: user 2.96 s, sys: 0.03 s, total: 2.98 s
Wall time: 3.01
499999500000
Part of the problem is that xsrange is in pure python -- it's not optimized at all.
-- The response to `latex?' seems to be out of date.
%latex
The equation y^2 = x^3 + x defines an elliptic curve.
We have 2006 = SAGE{factor(2006)}.
I thought it was a great credit to SAGE that when I edited the sample input
in what seemed the obvious way, enclosing the math in $$ and changing SAGE
to \sage, that it worked as expected.
Ah, you've found a bug. What happens is that all SAGE documentation
is de-texed before displaying in the notebook (in plain text format). Unfortunately
this detexing makes the documentation for latex appear completely
wrong!
The solution is probably to come up with a notation to tell SAGE not
to do the detexing. This is now trac #683.
-- Regarding latex, it would be great to have a simple description of
how to use the notebook interface to produce a paper in latex incorporating
sage input and output,
It would be great if it were possible to do that. Creating a "save as latex"
option in the notebook has been on the todo list for a long time. I have
some "big plans" along these lines (in both directions)...
-- I haven't yet figured out how to run consistency tests (making sure
that examples have the correct output) within a sage notebook.
This is also not implemented. If the code doesn't take to long to compute,
I usually just click "Evaluate All" under Action. Then the output you see
is definitely what SAGE produced.
Another thing you can do -- if foo.tex is a tex file that contains
SAGE sessions in verbatim environments, then you can type
sage -t foo.tex
to make sure they work as claimed. The SAGE sessions
have to be like from the command line -- which you can get by clicking
"Text" in the notebook, which will reformat a notebook session to
look like a command line session (though it doesn't work for things
that don't make sense at the command line, e.g., %latex).
Also, if one verbatim block depends on the results of another
you have to do this:
\begin{verbatim}
sage: a = 5
\end{verbatim}%link
....
%link
\begin{verbatim}
sage: print a
5
\end{verbatim}
-- William
David Joyner
> On 9/17/07, Peter G. Doyle <do...@gauss.dartmouth.edu> wrote:
> > I have recently discovered SAGE, which I think is really quite amazing.
> >
> > I am contemplating introducing the students in our honors calculus course
> > here at Dartmouth to SAGE. I'm a bit leery about this, since I'm new to
> SAGE
> > myself. I'm wondering if you can suggest materials (e.g. sample
> worksheets)
> > I could crib from.
>
> The time might not quite by right for doing this, since there isn't very
> much
> written about using SAGE for calculus beyond the reference manual chapter,
> which you already know about. I will teach calculus 1 year from now, and
> have
> my own very nice notes (which I made by sitting in on the best calculus
> teacher's
> class at UCSD), and will change them to use SAGE. But that project is a
> year away. I'm not aware of anybody else creating extensive notes on using
> SAGE for calculus yet. (I'm cc'ing this to sage-devel -- if anybody there
> has
> any comments, please make them.)
I am working on it. It is a huge job and my time is limited so
progress is slow. I was planning on using your notes for
Calc 2 since I don't think it covers calc 1 (I could be misremembering...).
For calc 1, I'll try using Granville's old text (public domain); for
calc 3, using
Sean Mauch (also public domain); and for DEs, using my own notes.
I've looked at lots of others on the web but they were either licensed wrong or
unsuitable for some other reason.
Alec Mihailovs
From: William Stein
> One possibly nasty possibility would be to allow Magma-like notation:
> sage: [1..4]
> [1, 2, 3, 4]
>
In Maple it is similar to Magma, $1..4 produces 1,2,3,4. Also, .. is used
for plots, sums, integrals et al. as plot(x^2,x=-1..1); int(x^2,x=-1..1);
etc.
>> -- Regarding latex, it would be great to have a simple description of
>> how to use the notebook interface to produce a paper in latex
>> incorporating
>> sage input and output,
That can be done more simple in texmacs with a SAGE session embedded. I
think SAGE sessions can be added to LyX, too, but that seems to be not
implemented yet.
Alec
William Stein
On 9/17/07, William Stein <wst...@gmail.com> wrote:
> On 9/17/07, Peter G. Doyle <do...@gauss.dartmouth.edu> wrote:
> > -- It's still far from clear to me what `downloading' and `uploading' are
> > supposed to mean.
>
>
> It's supposed to be exactly the same as "save" and "open". Maybe I should
> change the names to "save" and "open"? Right now the terminology just
> follows Google Documents (which inspired much of the notebook's layout).
>
I `upload' a paper to the arxiv: That's like saving it.
You could also think of it as the arxiv opening the paper. The SAGE notebook
is not like the arxiv though -- it's a program, so this is more like opening
a file in Microsoft Word.
I `download'
a paper from the arxiv: That's like opening it. Here the
nomenclature seems to be backwards.
When you click download, what happens is that you save the file
to your local disk, and only after that happens it happens to
be opened by a pdf (or dvi or ps) reader on your computer. Three
separate things happen.
It sounds from what you write though, that it is best to just stick
with the "upload" / "download" terminology, since it is *very* clear
in which direction the file goes in each case. Upload means "goes
to the server (SAGE notebook), and download means it goes to
your local hard drive.
> A better solution would, as you suggest, to define a function like
> range -- but not called range -- that includes both endpoints.
> One possibly nasty possibility would be to allow Magma-like
> notation:
> sage: [1..4]
> [1, 2, 3, 4]
> I can't think of any situation where .. (not in a string) is valid Python,
> so the above might be a reasonable option.
>
This sounds like a great idea! I like having the lower bound explicit.
I wonder if there would be some consistent way to make 1..4 stand for
an iterator, and [1..4] a list. Hmm: then since we'd want [2,3,5..9]
to be a list, we'd want 2,3,5..9 to be an iterator, whereas (2,3,5..9)
would presumably be a tuple, which seems problematic. Is there a
clean way to handle this?
I don't know. I'll wait to see if sage-devel (the mailing list) generates
discussion about this before deciding whether to consider actually
doing it. Since nobody has seriously proposed it before (after 2.5
years), there may be some good arguments against it. A general
rule of thumb with Sage development is that one should avoid
modifying the preparser if at all possible, because all such modifications
distance Sage from the very widely used and known Python language,
and this in itself actually can cause a lot of problems and confusion.
So we're pretty conservative about making any changes at all to
the preparser at this point.
> How does one specify an integer range in Maple, Mathematica, Maxima?
>
In Mathematica, Range[10] is 1..10, Range[0,10] is 0..10.
Interesting. It is like in Python, but adjusted for Mathematica being 1-based.
-- William
Robert Bradshaw
I really like the "open" and "save" terminology best--it even brings
up "open" and "save" dialogs. Download/upload is much less intuitive
(I think it should almost be transparent that there is even a "server").
>
> > A better solution would, as you suggest, to define a function like
> > range -- but not called range -- that includes both endpoints.
> > One possibly nasty possibility would be to allow Magma-like
> > notation:
> > sage: [1..4]
> > [1, 2, 3, 4]
> > I can't think of any situation where .. (not in a string) is
> valid Python,
> > so the above might be a reasonable option.
> >
>
> This sounds like a great idea! I like having the lower bound
> explicit.
>
> I wonder if there would be some consistent way to make 1..4 stand for
> an iterator, and [1..4] a list. Hmm: then since we'd want [2,3,5..9]
> to be a list, we'd want 2,3,5..9 to be an iterator, whereas (2,3,5..9)
> would presumably be a tuple, which seems problematic. Is there a
> clean way to handle this?
I like this a lot too, and think it would be worth modifying the
preparser to do. The range starting at 0 is natural for me, but it
seems to trip a lot of (non-programmers) up.
- Robert
William Stein
> It sounds from what you write though, that it is best to just stick
> with the "upload" / "download" terminology, since it is *very* clear
> in which direction the file goes in each case. Upload means "goes
> to the server (SAGE notebook), and download means it goes to
> your local hard drive.
I really like the "open" and "save" terminology best--it even brings
up "open" and "save" dialogs. Download/upload is much less intuitive
(I think it should almost be transparent that there is even a "server").
OK, cool. Could some other people vote?
> > A better solution would, as you suggest, to define a function like
> > range -- but not called range -- that includes both endpoints.
> > One possibly nasty possibility would be to allow Magma-like
> > notation:
> > sage: [1..4]
> > [1, 2, 3, 4]
> > I can't think of any situation where .. (not in a string) is
> valid Python,
> > so the above might be a reasonable option.
> >
>
> This sounds like a great idea! I like having the lower bound
> explicit.
>
> I wonder if there would be some consistent way to make 1..4 stand for
> an iterator, and [1..4] a list. Hmm: then since we'd want [2,3,5..9]
> to be a list, we'd want 2,3,5..9 to be an iterator, whereas (2,3,5..9)
> would presumably be a tuple, which seems problematic. Is there a
> clean way to handle this?
I like this a lot too, and think it would be worth modifying the
preparser to do. The range starting at 0 is natural for me, but it
seems to trip a lot of (non-programmers) up.
Robert, Since you do so much work on Cython, maybe you could think
about the formal specification of the Python language and see whether
..
not appearing in a string is ever valid Python. I.e., could we add
[expr1 .. expr2]
to the language without running into problems?
Maybe
(expr1 .. expr2)
should return a generator and
[expr1 .. expr2]
should return a list.
And, if anybody out there thinks adding the above to the preparser
would make you positively cringe in disgust, please speak up!
(It doesn't mean we won't add it anyways...)
Nick Alexander
> about the formal specification of the Python language and see whether
> ..
> not appearing in a string is ever valid Python. I.e., could we add
> [expr1 .. expr2]
> to the language without running into problems?
Much like generators (K.<x>), this cannot be added to the preparser
without parsing arbitary python expressions (expr1 and expr2 in this
case). At the moment, you can make the preparser barf and it would
be a great deal of work to fix. Are we willing to do another
"correct 90% of the time" hack? If this is considered very valuable,
I suggest we hijack a Python binary operator and repurpose it. Or we
could uniformly preparse '..' to be that redefined operator; that
would be better.
I vote against.
Nick
William Stein
Just for clarification, could you explain why the following algorithm
wouldn't suffice to parse the above 100% of the time?
Suppose at position i, i+1 in the input string that there is "..", and
this is not in a string. Reduce i counting ['s and ]'s that are not
in a string literal until the
count of [ is greater than the count of ]. This locates the left [.
Starting again with position i at .., increase i counting ['s and ]'s
not in string literals until the count of ] is greater than
the count of ['s.
I naively think the above should correctly find the positions of [ and ],
and hence of expr1 and expr2, in [ expr1 ... expr2 ] in all cases.
I naively think this because I think that any valid Python expression
with a [ must have a balanced ] (discarding string literals).
Mike Hansen
strong Python convention. I'd rather have consistency since it
appears so often in other places.
I'd vote against.
--Mike
On 9/17/07, Nick Alexander <ncale...@gmail.com> wrote:
>
Robert Bradshaw
multi-dimensional slice list, is represented by '...' (exactly three
dots). Exactly two subsequent dots is illegal.
I don't think there is a suitable binary operation to hijack, however
I think
'[' expr1 [,]..[,] expr2 ']' # the commas here are optional, and
expr doesn't contain unbalanced strings or un-quoted brackets (not
regex, but easy to check).
could be easily and reliably pre-parsed into something like
"sage_range(expr, Ellipsis, expr2)"
Note that "[1,2,3,..,10]" would get turned into "sage_range(1,2,3,
Ellipsis,10)" which would then return [1,2,3,4,5,6,7,8,9,10]. Using
the same logic, there would be no need to limit an expression to a
single Ellipsis, e.g. "[1..4,6..10]" would be "sage_range(1,Ellipsis,
4,6,Ellipsis,10)" = [1,2,3,4,6,7,8,9,10]. We could even let
sage_range(2,4,...,10) = [2,4,6,8,10]. A similar expression in ()'s
would yeild a generator (and could even lack an upper bound).
- Robert
Robert Bradshaw
we are breaking?
On Sep 17, 2007, at 9:39 PM, Mike Hansen wrote:
Martin Albrecht
> > an iterator, and [1..4] a list. Hmm: then since we'd want [2,3,5..9]
> > to be a list, we'd want 2,3,5..9 to be an iterator, whereas (2,3,5..9)
> > would presumably be a tuple, which seems problematic. Is there a
> > clean way to handle this?
I vote against it!
(a) because I usually vote against preparser changes :-)
(b) it means SAGE is slowly getting its own language and
(c) it breaks conventions, i.e. it adds confusion IMHO.
(d) It might be because I used to be CS major but I think it is okay just
educate users about the -- wildly used -- Python (and C and Java) convention.
(e) It is not a math paper you are writing in SAGE but they are writing code
in a programming language and you are using a library with a lot of math
capabilities.
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinr...@jabber.ccc.de
Robert Bradshaw
On Sep 18, 2007, at 12:50 AM, Martin Albrecht wrote:
>>> I wonder if there would be some consistent way to make 1..4 stand
>>> for
>>> an iterator, and [1..4] a list. Hmm: then since we'd want
>>> [2,3,5..9]
>>> to be a list, we'd want 2,3,5..9 to be an iterator, whereas
>>> (2,3,5..9)
>>> would presumably be a tuple, which seems problematic. Is there a
>>> clean way to handle this?
Regarding this, it would be more like list comprehension. [blah for x
in A] is a list. (blah for x in A) is an iterator. 1..4 would be more
ambigious to pre-parse.
However, if we go with the current tally it looks like it's going to
be shot down anyway...
Chris Chiasson
> And, if anybody out there thinks adding the above to the preparser
> would make you positively cringe in disgust, please speak up!
> (It doesn't mean we won't add it anyways...)
If you ask me, my opinion would be not to change it.
If you ask why:
Earlier, someone said that Range[10] in Mathematica gives you 1..10.
While this is correct, it is also "incorrect".
What is actually returned is:
List[1,2,3,4,5,6,7,8,9,10]
There are actually _eleven_ elements in the returned expression,
because the head (List) is at index 0. The head can be edited just
like the integers in the rest of the expression. For instance, this is
a valid expression: 0[1,2,3,4,5,6,7,8,9,10]
In a way, you could actually say that expressions (which include lists
and arrays) in Mathematica are actually zero based.
However, this fact has been neatly tucked away (hidden, basically) in
almost all of the commands in Mathematica's function library. It is so
pervasive that several functions take an option called Heads (which
has an "intelligent" default) that controls whether or not the
function operates on index zero. This behavior can be quite maddening
at times, when one is wondering why a certain structure isn't located,
only to find out it was inside a head.
If sage is going to move to being contextually 1 based, but actually 0
based, which is basically what the proposal is asking for (and what
Mathematica does), then people are going to start wanting this strange
1-off behavior everywhere... and you will have to design for it. Also,
even with great care, it will still trip people up. It would probably
make things more consistent and easier to learn if you stick with
Python's convention.
David Joyner
> > > It sounds from what you write though, that it is best to just stick
> > > with the "upload" / "download" terminology, since it is *very* clear
> > > in which direction the file goes in each case. Upload means "goes
> > > to the server (SAGE notebook), and download means it goes to
> > > your local hard drive.
> >
> > I really like the "open" and "save" terminology best--it even brings
> > up "open" and "save" dialogs. Download/upload is much less intuitive
> > (I think it should almost be transparent that there is even a "server").
>
> OK, cool. Could some other people vote?
Agreed: "open" and "save" are good, but then don't you have 2 different
save options? (Save to sevrver and save to local HD?)
Joel B. Mohler
I don't have a strong opinion about the original proposition ... although I
have spent the last week being thoroughly vexed by python being zero-based
when all the things I would write on paper about math would index things
one-based.
However, I did want to say this about the preparser. My impression is that it
is written by doing very manual character/string reading. I think
the 'tokenize' module could probably make the code much much cleaner. It has
annoying (but understandable) semantics. Here's an example below.
--
Joel
import tokenize
# helper class to generate a stream from a string
class line_token_stream:
def __init__( self, s ):
self.line = s
def __call__( self ):
if self.line:
s = self.line
self.line = None
return s
raise StopIteration
def tokenize_line( s ):
for t in tokenize.generate_tokens( line_token_stream( s ) ):
yield t
for i in tokenize_line( "func(1+2)" ):
print i
John Cremona
This is a basic mathematics/CS divide. Mathematicians will expect
their vectors of length n to have indices 1..n and similarly for
matrices and so on. The packages pari and magma use that convention
accordinly, since they are written for mathematicians to be as close
to mathematical notation as possible, and this is a great help to
getting mathematicians to do computations.
I think there's a real problem if we tell mathematicians tat to use
SAGE properly they have to both learn programming in a language they
have probably never heard of (sorry, but that is the case with pyhton
and mathematicians) and also re-learn habits of a lifetime. There is
a very steep learning curve involved in learning a new package in any
case -- it took me years to get a "feel for" magma, and I still don't
have a good one for SAGE -- and it does not take a lot to put people
off.
Sorry if this sounds negative, but I have a feeling that sage-devel
has more CS people in it than mathematicians!
John
--
John Cremona
Martin Albrecht
> [I'm not sure why this thread is atll called "Calculus"!]
>
> This is a basic mathematics/CS divide. Mathematicians will expect
> their vectors of length n to have indices 1..n and similarly for
> matrices and so on. The packages pari and magma use that convention
> accordinly, since they are written for mathematicians to be as close
> to mathematical notation as possible, and this is a great help to
> getting mathematicians to do computations.
>
> I think there's a real problem if we tell mathematicians tat to use
> SAGE properly they have to both learn programming in a language they
> have probably never heard of (sorry, but that is the case with pyhton
> and mathematicians) and also re-learn habits of a lifetime. There is
> a very steep learning curve involved in learning a new package in any
> case -- it took me years to get a "feel for" magma, and I still don't
> have a good one for SAGE -- and it does not take a lot to put people
> off.
>
> Sorry if this sounds negative, but I have a feeling that sage-devel
> has more CS people in it than mathematicians!
The main issue is: Starting at 1 cannot be done if you want to keep using
Python, i.e. not reinventing the wheel. You can change the SAGE library code
but everything core Python will still start counting at zero. Also, other
libraries you might want to use with SAGE (one of the cool things about SAGE
is that you can use it with all the other cool Python libraries) will still
start counting at 0. Introducing a couple of functions which start counting
at 1 will make things more difficult than easy. The rule: start counting at
zero is easy enough to understand, though I appreciate that it is sometimes
odd if you are working with a paper and have to fiddle with the indices. The
rule: "sometimes we start at one and often at zero" is way harder to get
IMHO.
So if we set aside our personal preferences and backgrounds (CS and Math) for
a moment: by choosing a mainstream programming language the choice to start
counting at zero was made as well. If we are not happy about it we might need
to fork Python (this is not a proposal :-)).
Also, the argument given above is a marketing argument. It is about convincing
somebody to use a piece of software. I don't think it is a good idea to
change a clean, well understood and dominant design (at least in CS to be
precise) just for the purpose of convincing somebody to use a product, when
we don't even know, if [s]he's interested in it. If SAGE has the (best) tools
researchers need, they will use it. If somebody refuses to use a piece of
software because of indexing differences ... well ... I honestly wouldn't
know what to say.
David Harvey
On Sep 17, 2007, at 11:55 PM, William Stein wrote:
> And, if anybody out there thinks adding the above to the preparser
> would make you positively cringe in disgust, please speak up!
> (It doesn't mean we won't add it anyways...)
Positively cringe in disgust.
-1
david
Jaap Spies
> On Tuesday 18 September 2007, John Cremona wrote:
>>
>> Sorry if this sounds negative, but I have a feeling that sage-devel
>> has more CS people in it than mathematicians!
>
> The main issue is: Starting at 1 cannot be done if you want to keep using
> Python, i.e. not reinventing the wheel. You can change the SAGE library code
> but everything core Python will still start counting at zero. Also, other
> libraries you might want to use with SAGE (one of the cool things about SAGE
> is that you can use it with all the other cool Python libraries) will still
> start counting at 0. Introducing a couple of functions which start counting
> at 1 will make things more difficult than easy. The rule: start counting at
> zero is easy enough to understand, though I appreciate that it is sometimes
> odd if you are working with a paper and have to fiddle with the indices. The
> rule: "sometimes we start at one and often at zero" is way harder to get
> IMHO.
>
> So if we set aside our personal preferences and backgrounds (CS and Math) for
> a moment: by choosing a mainstream programming language the choice to start
> counting at zero was made as well. If we are not happy about it we might need
> to fork Python (this is not a proposal :-)).
>
I think we should stay as close as possible to Python.
And a lot of mathematicians start counting with 0 as the first natural number,
including me coming from 'The Foundation of Mathematics'.
See for instance: http://en.wikipedia.org/wiki/Natural_number
> Also, the argument given above is a marketing argument. It is about convincing
> somebody to use a piece of software. I don't think it is a good idea to
> change a clean, well understood and dominant design (at least in CS to be
> precise) just for the purpose of convincing somebody to use a product, when
> we don't even know, if [s]he's interested in it. If SAGE has the (best) tools
> researchers need, they will use it. If somebody refuses to use a piece of
> software because of indexing differences ... well ... I honestly wouldn't
> know what to say.
>
+1
Jaap
Ondrej Certik
>
> (a) because I usually vote against preparser changes :-)
> (b) it means SAGE is slowly getting its own language and
> (c) it breaks conventions, i.e. it adds confusion IMHO.
> (d) It might be because I used to be CS major but I think it is okay just
> educate users about the -- wildly used -- Python (and C and Java) convention.
> (e) It is not a math paper you are writing in SAGE but they are writing code
> in a programming language and you are using a library with a lot of math
> capabilities.
Exactly. I am not a SAGE developer (yet), but I vote against it as
well. As to a), I am actually against preparser completely.
Ondrej
Hamptonio
definitely not a CS person, but I think people just need to get used
to the behavior of range. It took me a while to adjust, but the
benefits of learning python were well worth it. I think the preparser
should be as minimal as possible.
The only reason I like the idea of ".." is that packages such as scipy
and matplotlib are already very inspired by Matlab, so it would make
sage more matlab-like, increasing the chance of winning over matlab
users. But overall, I think it is best to stick to python syntax.
Marshall
William Stein
I don't have a strong opinion about the original proposition ... although I
have spent the last week being thoroughly vexed by python being zero-based
when all the things I would write on paper about math would index things
one-based.
One solution to that is to just write things 0-based in your math papers.
I've been doing that in all the mathematics I write for the last 2 years
or so, and nobody complains. Consider an $n$-dimensional vector
space with basis $v_0, \ldots, v_{n-1}$.
However, I did want to say this about the preparser. My impression is that it
is written by doing very manual character/string reading. I think
the 'tokenize' module could probably make the code much much cleaner. It has
annoying (but understandable) semantics. Here's an example below.
True. I've been looking forward to somebody rewriting the preparse(...)
function for a long time. Much to my surprise nobody has. I don't think
anybody has even tried, though people have suggested they would try
on a few occasions. I would certainly be happy if it were to happen, though
I'm not going to do it myself, since the current version works perfectly
well, is easy to understand, and I have other things that I have to do.
Also, speeding up the preparser might have little noticeable effect on the
speed of Sage, since all actual work / computation happens after preparsing.
That said, if you do
sage: search_src('sage_eval')
you'll see 83 places in the Sage library code itself that involve calling
the Sage preparser, and those could be faster.
Using tokenize as you illustrate below would probably be a simple
intermediate way to rewrite the preparser without going nuts trying
to do something too complicated. E.g., the preparser currently
has code to find string literals in the input line -- the tokenize module
does the same thing, probably much better. Also the preparser
has code to parse out valid identifiers, and again the tokenize module
below does that automatically.
I think "modifying preparse.py to benefit from the Python standard tokenize module" would be a good trac enhancement ticket:
http://trac.sagemath.org/sage_trac/ticket/689
--
Joel
import tokenize
# helper class to generate a stream from a string
class line_token_stream:
def __init__( self, s ):
self.line = s
def __call__( self ):
if self.line:
s = self.line
self.line = None
return s
raise StopIteration
def tokenize_line( s ):
for t in tokenize.generate_tokens( line_token_stream( s ) ):
yield t
for i in tokenize_line( "func(1+2)" ):
print i
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Nick Alexander
> (...)
> function for a long time. Much to my surprise nobody has. I don't
> think
> anybody has even tried, though people have suggested they would try
> on a few occasions.
I did! In the end, I never was able to parse K.<x> = ... to my
satisfaction, so I abandoned it.
I also used a parser combinator library that was pretty crufty and
probably wasn't suitable for SAGE, and I wasn't in the mood to write
my own combinator library.
Nick
Ted Kosan
> This is a basic mathematics/CS divide. Mathematicians will expect
> their vectors of length n to have indices 1..n and similarly for
> matrices and so on. The packages pari and magma use that convention
> accordinly, since they are written for mathematicians to be as close
> to mathematical notation as possible, and this is a great help to
> getting mathematicians to do computations.
>
> I think there's a real problem if we tell mathematicians tat to use
> SAGE properly they have to both learn programming in a language they
> have probably never heard of (sorry, but that is the case with pyhton
> and mathematicians) and also re-learn habits of a lifetime. There is
> a very steep learning curve involved in learning a new package in any
> case -- it took me years to get a "feel for" magma, and I still don't
> have a good one for SAGE -- and it does not take a lot to put people
> off.
>
> Sorry if this sounds negative, but I have a feeling that sage-devel
> has more CS people in it than mathematicians!
What is Sage's target market? It seems to me that determining an
answer to this question should be a high priority item :-)
ted
William
> > True. I've been looking forward to somebody rewriting the preparse
> > (...)
> > function for a long time. Much to my surprise nobody has. I don't
> > think
> > anybody has even tried, though people have suggested they would try
> > on a few occasions.
>
> I did! In the end, I never was able to parse K.<x> = ... to my
> satisfaction, so I abandoned it.
Could you post a short summary about what you did (what library /
approach
used, considered, etc.), and why you weren't
happy with it, etc.,? It would be really helpful to whoever actually
tries
to do something with:
http://trac.sagemath.org/sage_trac/ticket/689
Thanks!
> I also used a parser combinator library that was pretty crufty and
> probably wasn't suitable for SAGE, and I wasn't in the mood to write
> my own combinator library.
What does "parser combinator library" mean? It sounds like Klingon to
me.
William
William Stein
Hi William,
> When you click download, what happens is that you save the file
> to your local disk, and only after that happens it happens to
> be opened by a pdf (or dvi or ps) reader on your computer. Three
> separate things happen.
>
Actually, when I click download, nothing obvious happens (on my G4
running Mac OS 10.4). I am interested to learn that the file is
supposed to open in some reader. I think is that had happened, I
might have developed a better notion of why this was called
`download'.
I was referring to downloading a paper from the arxiv, i.e., your
other example. I was not referring to Sage notebooks.
As for `upload', I admit I am still not clear on what this is supposed
to do. I don't know that I've ever successfully uploaded a file.
It generally says, "Error uploading worksheet 'Error decompressing
saved worksheet.'". Probably I am trying to upload the wrong kind of
file. That's using the upload button on the `Home' page. There's
also an `upload' selection on the `Data' menu, which winds up telling
me I can download the file (this was confusing - I thought we were
trying to upload the file!) or link it to a worksheet (whatever that
means) or delete it.
What kind of file are you uploading? Currently the only file type that
is supported is files that you downloaded before from the Sage notebook.
Other formats will be added next time their is a notebook coding sprint.
> It sounds from what you write though, that it is best to just stick
> with the "upload" / "download" terminology, since it is *very* clear
> in which direction the file goes in each case. Upload means "goes
> to the server (SAGE notebook), and download means it goes to
> your local hard drive.
>
I guess what you mean is that it really ought to be clear. But think
about it from the user's point of view. I am not thinking of the
notebook as a server. To me, SAGE feels like any other application,
except that it happens to be running in a browser window. You see a
big distinction in the fact that it is running as a server, but you've
succeeded so well in making the notebook interface feel like an
ordinary application that this distinction doesn't seem obvious to me.
As for the analogy to google apps, there I understand that there are
these farms of machines out in Nebraska or Nevada or somewhere to
which I can `upload' my file. But here everything is running on my
machine, so this distinction isn't so obvious to me. Now I am
starting to understand it. Anyway, my point is that you should not
assume that what is very clear to you as the architect of the system
will be very clear to users, to whom the SAGE notebook interface may
look more like an application than a server. In Mathematica or Maple,
I open and close documents, so that's what I'm expecting to do with
SAGE.
Understood. I didn't actually think about any of the above when naming
the menus as they are now. I just copied exactly what they were named
in Google Documents. By the way, http://sagenb.org allows one to use
Sage remotely (not on your own computer).
> A general
> rule of thumb with Sage development is that one should avoid
> modifying the preparser if at all possible, because all such modifications
> distance Sage from the very widely used and known Python language,
> and this in itself actually can cause a lot of problems and confusion.
> So we're pretty conservative about making any changes at all to
> the preparser at this point.
>
Well, that makes sense. You've cast your lot with Python. I do worry
what will happen as Python changes. For example, they're talking
about getting rid of the print statement. And maybe getting rid of
xrange. If I commit to SAGE, will my worksheets keep going out of
date as Python changes?
The choice is either Python (or Java/Perl/Ruby) or designing my own
language; every other serious math system has made the latter choice.
Choosing to use a mainstream standard language (like Python) is
one of the main things that characterizes Sage. It has,
in many ways I never expected, turned out to be -- by
far -- the right choice to make.
Python 3000 (=Python 3.0) -- when/if it ever gets released -- is advertised as the one
and only major change to Python that will break backwards compatibility.
So far, since the early 1990s, Python has been incredibly backward
compatible. After Python 3.0, I expect Python will remain very stable as well.
By the way the print change will mean that one writes
sage: print (2+2)
4
instead of
sage: print 2 + 2
4
It's conceivable the Sage preparser could add back the old behavior (or that
Python 3.0 would add it back as an option). Also, there will be good quality
tools for automatically migrating code to Python 3.0.
Anyway, I think it will be nearly 3 years until Python 3.0 even begins to
be something that will be really relevant to Sage. That's a long time, considering
that Sage didn't exist in any way 3 years ago.
Basically, in summary, I have no worries whatever about Python as a stable
choice of language for Sage.
> > > How does one specify an integer range in Maple, Mathematica, Maxima?
> > >
> >
> > In Mathematica, Range[10] is 1..10, Range[0,10] is 0..10.
>
> Interesting. It is like in Python, but adjusted for Mathematica being
> 1-based.
Look, I hate Mathematica more than the next guy, even though I've been
using it for many years now. But in this case they've got it right.
And maybe Python has it right for bit-bangers. But I believe that to
have the value of sum(i for i in range(1,10)) be 45 is a recipe for
trouble. That's why I think your suggestion of replacing it with
sum(i for i in [1..10]) is a stroke of genius. Now instead of having
to constantly remind students that range(1,10) doesn't mean what they
think. you can just train them to use [1..10] instead.
There was a long thread on sage-devel about this:
http://groups.google.com/group/sage-devel/browse_thread/thread/674e88887d0da278
OK, so as a former UCSD professor, I have to ask who you think is the
best calculus teacher there.
John Eggers. I sat in on his class two years ago, and learned a great
deal about how to teach Calculus:
http://www.math.ucsd.edu/~jeggers/
William Stein
That's an interesting question that I've thought about...
Sage is free software produced mostly by volunteer work.
There is currently not a single person who is paid fulltime
to work on Sage. The current goal with Sage is not to maximize
profit, and as such, the phrase "target market" is likely have a
different meaning for Sage than for Maple (say), and hence the
answer is likely to be different.
I see the primary goal of the Sage project is the following:
"Provide a free open source viable alternative to
Magma, Maple, Mathematica, and MATLAB."
(For me personally the goal is a viable alternative to Magma, since
Maple, Mathematica, and Matlab are all useless
in my research area, since nobody in my area of
number theory do not use those systems for serious
research -- everybody uses Magma or PARI.)
Back to your original question. Because of the above goal,
the target audience for Sage is in fact pretty similar to the
ones for Magma, Maple, Mathematica, and MATLAB. However,
the emphasis is much different, and because Sage is a rapidly
changing project, the meaning of "target audience"
changes over time.
I see the target audience for Sage today, in order of priority as:
(1) People who can contribute back and would otherwise be likely
to use Magma,
(2) People who can contribute back and would otherwise be likely
to use Maple/Mathematica,
(3) People who would use Magma and not contribute back,
(4) Maple/Mathematica users who would not contribute back, and
(5) Matlab users who would not contribute back.
That said, I view all of these groups as very important.
This priority list will change as Sage becomes more feature complete
and more bugs are fixed. Also, perhaps the above priority list would
nearly reverse if Sage were to have either a commercial counterpart (think
Redhat who sell support for Linux) or a generous financial benefactor
(think Mark Shuttleworth who sponsors Ubuntu using his dot-com millions).
Things are much different when people actually get paid
to work on a project ( e.g., the 2d mathematica-like graphics
in Sage were written last year by Alex Clemesha, who I
employed full time to work on Sage as a normal job. That was
an improvement to Sage aimed very much at group (4) above.)
Comments are very welcome!
William
William Stein
---------- Forwarded message ----------
From: Peter Doyle (a Professor at Dartmouth)
Date: Sep 18, 2007 10:32 AM
Subject: Re: Calculus
To: William Stein < wst...@gmail.com>
Hi William,
> There was a long thread on sage-devel about this:
>
> http://groups.google.com/group/sage-devel/browse_thread/thread/674e88887d0da278
>
by how the discussion turned to the question of basing ranges at 0
rather than 1. Having the default lower bound 0 actually doesn't
bother me at all. The real problem as I see it is that in range(1,10)
the upper bound isn't included. This can be justified in the case of
range(10) by viewing 10 as telling not the upper bound, but the length
of the list. But in range(1,10), 10 tells neither the length of the
list nor the upper bound. Or rather, it's the upper bound for a
half-open interval of integers, which is not the kind of convention
that is going to be natural for mathematicians or calculus students.
Mathematicians *could* have defined $\sum_{i=1}^{10}$ not to include
the upper limit in the sum. Only that's just not how we do it.
Anyway, what I like about your proposal to introduce the notation
1..10 is that it sidesteps the question of what range() ought to do.
Like it or not, range() does what it does. Meanwhile, [1..10] does
what you expect it to do. I can't believe anyone would argue that
[1..10] ought to omit 10. I am sure there are people who never mess
up and expect range() to include the upper bound. And with practice,
most people will learn that when a loop isn't working, they should
check the upper bound to make sure they didn't screw up because
range() doesn't work as they naturally expect. But the beauty of a
notation like 1..10 is that it does what you expect.
This is not to say that I think you necessarily have to make this
addition to the preparser. I think using Python was an inspired
decision, and is responsible for the fact that SAGE is so great. I
can see why you would not want to deviate from it without a compelling
reason. Not yet, anyway: Maybe after all the hackers have moved on
to Ruby (and then Topaz, and then Tourmaline...), leaving Python
(i.e., SAGE) to the mathematicians.
Cheers,
Peter
Ted Kosan
> Sage is free software produced mostly by volunteer work.
> There is currently not a single person who is paid fulltime
> to work on Sage. The current goal with Sage is not to maximize
> profit, and as such, the phrase "target market" is likely have a
> different meaning for Sage than for Maple (say), and hence the
> answer is likely to be different.
My view of profit is as follows:
1. The net gain from an activity. 2. For a firm: revenue minus cost.
www-personal.umich.edu/~alandear/glossary/p.html
My position is that people would not use SAGE unless they were gaining
something from it. :-)
The reason I chose the term "market" is because I think SAGE has
evolved to the point where marketing it has become a top priority.
Just to be clear, here is the definition of marketing that I am using:
"Marketing is the process or act of making products appeal to a
certain demographic, or to a consumer."
http://en.wikipedia.org/wiki/Marketing
> I see the target audience for Sage today, in order of priority as:
> (1) People who can contribute back and would otherwise be likely
> to use Magma,
> (2) People who can contribute back and would otherwise be likely
> to use Maple/Mathematica,
> (3) People who would use Magma and not contribute back,
> (4) Maple/Mathematica users who would not contribute back, and
> (5) Matlab users who would not contribute back.
This is how I view SAGE's potential target audience:
http://sage.math.washington.edu/home/tkosan/sage_potential_target_audience.png
If the goal is to grow SAGE's user base as large as possible, it is my
option that SAGE should be marketed as a lower-cost, massively more
powerful replacement for the scientific calculator. I also think that
the largest group of scientific calculator users in the world consists
of high school students.
As a number of people have noted on the SAGE lists, getting current
mathematicians to learn SAGE is extremely difficult. I think that for
every mathematician that one can get to use SAGE, the same amount of
effort would be able to get 10+ high school students or other
scientific calculator users to use it. Over time, this would
translate into a large and increasing number of young mathematicians
using SAGE. I think that a large user base would also solve SAGE's
programmer shortage problem because programmers could be recruited
from this group fairly easily.
> Also, perhaps the above priority list would
> nearly reverse if Sage were to have either a commercial counterpart (think
> Redhat who sell support for Linux) or a generous financial benefactor
> (think Mark Shuttleworth who sponsors Ubuntu using his dot-com millions).
> Things are much different when people actually get paid
> to work on a project <snip>
Is there anyone interested in starting a SAGE-based company and
offering SAGE as a web service to the scientific calculator target
audience? If so, I think that the university I work for could be your
first customer. I also have some ideas on how to make a SAGE-based
company thrive.
Ted
Jaap Spies
> ---------- Forwarded message ----------
> From: Peter Doyle (a Professor at Dartmouth)
> Date: Sep 18, 2007 10:32 AM
> Subject: Re: Calculus
> To: William Stein <wst...@gmail.com>
>
> Hi William,
>
>> There was a long thread on sage-devel about this:
>>
>>
> http://groups.google.com/group/sage-devel/browse_thread/thread/674e88887d0da278
>
> Thanks for pointing out this thread. Regarding range(), I was struck
> by how the discussion turned to the question of basing ranges at 0
> rather than 1. Having the default lower bound 0 actually doesn't
> bother me at all. The real problem as I see it is that in range(1,10)
> the upper bound isn't included. This can be justified in the case of
> range(10) by viewing 10 as telling not the upper bound, but the length
> of the list. But in range(1,10), 10 tells neither the length of the
> list nor the upper bound. Or rather, it's the upper bound for a
> half-open interval of integers, which is not the kind of convention
> that is going to be natural for mathematicians or calculus students.
> Mathematicians *could* have defined $\sum_{i=1}^{10}$ not to include
> the upper limit in the sum. Only that's just not how we do it.
>
Why not define a new function srange (short for sagerange),
or redefine the existing srange function:
def srange(a,b=None,step=1, include_endpoint=True):
or something like that.
See sage: srange??
Alternative: reuse xrange
this function will be removed from Python in Python3000.
> This is not to say that I think you necessarily have to make this
> addition to the preparser. I think using Python was an inspired
> decision, and is responsible for the fact that SAGE is so great. I
> can see why you would not want to deviate from it without a compelling
> reason. Not yet, anyway: Maybe after all the hackers have moved on
> to Ruby (and then Topaz, and then Tourmaline...), leaving Python
> (i.e., SAGE) to the mathematicians.
>
Diamonds are forever!
Jaap
Robert Bradshaw
One disadvantage of this is that include_endpoint=True takes much
more time to write than "+1", and requires the same amount of
knowledge. Perhaps one could have a function "full_range" that
includes the endpoint. I still like the [a..b] notation that makes
things totally obvious, and I am as surprised as Peter Doyle at the
shift of topic of whether or not indices should be 0-based (which we
don't have a choice about while sticking with Python).
Jaap Spies
>> Why not define a new function srange (short for sagerange),
>> or redefine the existing srange function:
>>
>> def srange(a,b=None,step=1, include_endpoint=True):
>>
>> or something like that.
>>
>> See sage: srange??
>>
>> Alternative: reuse xrange
>> this function will be removed from Python in Python3000.
>
> One disadvantage of this is that include_endpoint=True takes much
> more time to write than "+1", and requires the same amount of
> knowledge. Perhaps one could have a function "full_range" that
> includes the endpoint.
Sorry, I meant this to be the default action.
Jaap
Mike Hansen
integrate function. It could detect the argument types so if you
passed it a list, it'd behave the same as the builtin sum function.
sage: integrate(x, x, 0, 10)
50
sage: sum(x, x, 0, 10)
55
sage: sum(range(10))
45
I'm having trouble thinking of other instances where range() not
including the upper bound would cause (major) problems.
--Mike
Joel B. Mohler
> I still like the [a..b] notation that makes
> things totally obvious, and I am as surprised as Peter Doyle at the
> shift of topic of whether or not indices should be 0-based (which we
> don't have a choice about while sticking with Python).
Well, I'll respond as to why I think they are exactly the same issue (in
spirit) since I'm the one who brought up 0-based vs. 1-based. To me, it is
very very intuitive that range(10) has 10 elements. The only serious point
of contention is where those 10 elements start. That's why I think that
these are the same issues.
I'll also say that I didn't mean to open this can of worms. It was just on my
mind at the time and I don't really expect us to preparse or change python to
work around this. However, I could fully understand why anyone would think
it a royal pain in the neck. When trying to compute something that you read
on paper, it is a continual conversion and a very confusing conversion.
After all, one of the classic source of programming errors is "off-by-one".
--
Joel
didier deshommes
array object that can be 0,1,2,... based and a List object that is
1-based. I think it would be nice to have an iterator object similar
to (1:n) in matlab (but not a list object).
didier
2007/9/18, Joel B. Mohler <jo...@kiwistrawberry.us>:
Chris Chiasson
> How about providing a sum function that would behave like, say, the
> integrate function. It could detect the argument types so if you
> passed it a list, it'd behave the same as the builtin sum function.
>
> sage: integrate(x, x, 0, 10)
> 50
> sage: sum(x, x, 0, 10)
> 55
> sage: sum(range(10))
> 45
>
> I'm having trouble thinking of other instances where range() not
> including the upper bound would cause (major) problems.
>
> --Mike
^^^
bump