Re: Sage (fwd)
William Stein
> Below is a message from a student who I met, who had tried to use SAGE
> but a) found the dependence on knowledge of rings to be awkward
I think currently SAGE is not aimed at people who haven't had
a course in abstract algebra. Various people have done a lot of
work for SAGE that is aimed at such people, but frankly I do
not have a good strategy to make SAGE accessible
to people who know about groups, rings, fields, etc.
I'm interested in starting some brainstorming about ways to make SAGE very
accessible to people who don't know about those algebraic structures.
Ideas? For starters, perhaps David Kaplan could suggest a couple
of specific sample problems that he would like to use SAGE to solve,
and we could think about how:
(1) they could be done, but require unreasonable knowledge of algebra
(2) they can't be easily done right now, but could be if we put
some additional code in SAGE.
SAGE includes Maxima, and Maxima is extremely capable at Calculus related
computations -- so one question is how to make such capabilities
available from SAGE without the user having to know anything about maxima
(or even what maxima is). So far SAGE is terrible at this, compared to
how good it could be.
> b) didn't get much info out of the documentation.
> He's very excited about open source software, especially for
> mathematics, and seems to be interested in working on documentation.
> One thing he explicitly expressed interest in was helping make a short
> tutorial for getting started with SAGE. David J., you're working on
> such a thing, aren't you?
>
> ---------- Forwarded message ----------
> Date: Thu, 30 Nov 2006 17:06:28 -0800 (PST)
> From: David Kaplan <dka...@u.washington.edu>
> To: boo...@u.washington.edu
> Subject: Sage
>
> This is my email. I am interested in helping the Sage Project in any way
> possible. I was thinking documentation.
> Dave K.
> Im working on Mandriva Linux, btw, but I can test on the standardized
> cygwin binary too.
>
>
>
Bobby Moretti
On Thu, 30 Nov 2006 19:16:39 -0800, <boo...@u.washington.edu> wrote:
> Below is a message from a student who I met, who had tried to use SAGE
> but a) found the dependence on knowledge of rings to be awkward
I think currently SAGE is not aimed at people who haven't had
a course in abstract algebra.
This is definitely the case. While one does not need to understand all the ins and outs of ring theory in order to make a matrix in SAGE, you at least have to understand the connection between rings and matrices. This is going to be, at the very least, intimidating to people who have never heard of a ring. And if they have to mess with algebraic structures at all, they may consider it an annoying and unnecessary waste of time.
Various people have done a lot of
work for SAGE that is aimed at such people, but frankly I do
not have a good strategy to make SAGE accessible
to people who know about groups, rings, fields, etc.
I'm interested in starting some brainstorming about ways to make SAGE very
accessible to people who don't know about those algebraic structures.
Yes, let's come up with such a strategy. I do think we need a unified plan. If not, we run the risk of having a bunch of different implementations of software aimed at such people, each having low interoperability both amongst themselves and with the other areas of SAGE.
Ideas? For starters, perhaps David Kaplan could suggest a couple
of specific sample problems that he would like to use SAGE to solve,
and we could think about how:
(1) they could be done, but require unreasonable knowledge of algebra
(2) they can't be easily done right now, but could be if we put
some additional code in SAGE.
SAGE includes Maxima, and Maxima is extremely capable at Calculus related
computations -- so one question is how to make such capabilities
available from SAGE without the user having to know anything about maxima
(or even what maxima is). So far SAGE is terrible at this, compared to
how good it could be.
Looking at the actual problems that people might want to do is a good way to get started. But again, I'd caution against taking too much of an ad-hoc approach. I think that calculus is a great place to start. First of all, we do have Maxima. Also, having an easy-to-use calculus package that displays its output prettily is a must for any self-respecting CAS. With jsMath and Maxima, we have a real potential to blow away the competition here. And finally, calculus is kind of a lowest common denominator among people who are using a CAS. It's probably the first thing that any non-mathematician would try... first impressions are important.
Re. brainstorming, I'd like to do this. Maybe after the meeting today, or sometime on Monday? I know things are busy getting 1.5 ready for release, so maybe we should wait until after that gets out the door.
> b) didn't get much info out of the documentation.
> He's very excited about open source software, especially for
> mathematics, and seems to be interested in working on documentation.
> One thing he explicitly expressed interest in was helping make a short
> tutorial for getting started with SAGE. David J., you're working on
> such a thing, aren't you?
>
> ---------- Forwarded message ----------
> Date: Thu, 30 Nov 2006 17:06:28 -0800 (PST)
> From: David Kaplan <dka...@u.washington.edu >
> To: boo...@u.washington.edu
> Subject: Sage
>
> This is my email. I am interested in helping the Sage Project in any way
> possible. I was thinking documentation.
> Dave K.
> Im working on Mandriva Linux, btw, but I can test on the standardized
> cygwin binary too.
Bobby Moretti
mor...@u.washington.edu
David Joyner
implement calculus in an insanely easy way, you must fiddle with the
preprocessor.
To illustrate a possible solution (as a starting point for a discussion,
not that I think this will be done), I'll mention an idea of mine which
got shot
down my everyone when I posted it awhile back (maybe last summer):
Change the preparser so that when you want to define (say) a function
like f(x) = sin(x), instead of having to type
sage: f = maxima("sin(x)")
sage: f.integrate("x")
they could type
sage f:= x->sin(x)
sage: integrate(f)
The ":=" would clue the parser that a new type of function is going to be
inputted. I believe this type of notation is used by both gap and maple.
Some simple way of inputting maxima functions is needed and IMHO
this is the main problem to making the calculus commands in SAGE
"insanely easy".
++++++++++++++++++++++++++++++++++++++++++
> --
> Bobby Moretti
> mor...@u.washington.edu <mailto:mor...@u.washington.edu>
> >
William Stein
wrote:
>
> Short of a clever python trick which is beyond me, I think to
> implement calculus in an insanely easy way, you must fiddle with the
> preprocessor.
>
> To illustrate a possible solution (as a starting point for a discussion,
> not that I think this will be done), I'll mention an idea of mine which
> got shot
> down my everyone when I posted it awhile back (maybe last summer):
> Change the preparser so that when you want to define (say) a function
> like f(x) = sin(x), instead of having to type
>
> sage: f = maxima("sin(x)")
> sage: f.integrate("x")
>
> they could type
>
> sage f:= x->sin(x)
> sage: integrate(f)
>
> The ":=" would clue the parser that a new type of function is going to be
> inputted. I believe this type of notation is used by both gap and maple.
> Some simple way of inputting maxima functions is needed and IMHO
> this is the main problem to making the calculus commands in SAGE
> "insanely easy".
I still disagree. Wouldn't this be easier:
sage: f = sin(x)
sage: integrate(f)
cos(x)
This is almost already implemented in SAGE. In fact the first line
works, but the second isn't implemented yet.
We might want to pre-define formal indeterminates a,b,c,...,z on
startup of SAGE, so users can use any of them in such expressions.
William
David Joyner
Okay, sin was a bad example. How would you make the following work?
sage: f = exp(x)*sin(exp(x))
sage: integrate(f)
- cos(exp(x))
The first line fails.
William Stein
wrote:
> Okay, sin was a bad example. How would you make the following work?
>
> sage: f = exp(x)*sin(exp(x))
> sage: integrate(f)
> - cos(exp(x))
>
> The first line fails.
I would make it work by implementing it. It's not implemented yet.
In particular there is no formal version of exp implemented
in SAGE. There is a formal version of cosine:
sage: f = cos(x)*sin(cos(x))
sage: f
(cos(x)*sin(cos(x)))
Then to do integrate(f), I would internall do:
(1) g = maxima(f) # currently doesn't give the right thing, but it
could
(2) g.integrate('x')
(3) parse the result (which in this case is simply the formal integral,
since maxima can't integrate it; same for maple).
(4) return the answer again as a native SAGE function.
Steps 1-3 could also be done behind the scenes using maple or
mathematica if available, or all three, and one can compare the results.
Actually, formal exp is implemented in SAGE, but it's not available by
default yet:
sage: from sage.functions.functions import expo as exp
sage: f = exp(x)*sin(exp(x))
sage: f
(expo(x)*sin(expo(x)))
Don't be put off by the outer parenthesis, since that's just cosmetic and
can
be easily fixed.
-- William
Bobby Moretti
> startup of SAGE, so users can use any of them in such expressions.
>
I'm not sure I like that idea... but I don't really know of an
alternative. Is there any way for SAGE to guess that someone is using
a given variable as an indeterminate? Possibly using the preprocessor?
That way we could define the indeterminates naturally, on the fly,
emulating how my favorite little CAS (the one that comes on the TI-89
calculators) handles it.
--
Bobby Moretti
mor...@u.washington.edu
William Stein
wrote:
>
> On 12/2/06, William Stein <wst...@gmail.com> wrote:
>>
>> We might want to pre-define formal indeterminates a,b,c,...,z on
>> startup of SAGE, so users can use any of them in such expressions.
>>
>
> I'm not sure I like that idea... but I don't really know of an
> alternative. Is there any way for SAGE to guess that someone is using
> a given variable as an indeterminate?
Without the preprocessor it is impossible, since it's simply a syntax
error in the language.
> Possibly using the preprocessor?
Even with the preprocessor it would be impossible (or insanely slow),
since the proprocessor has no state information (as well it shouldn't).
Use of the preprocessor should be avoided if at all possible, and them
some.
> That way we could define the indeterminates naturally, on the fly,
> emulating how my favorite little CAS (the one that comes on the TI-89
> calculators) handles it.
No. SAGE is not going to do this. A predefined list of variables, e.g.,
a,..,z, A,...,Z I would consider. I won't totally change the language
semantics of Python. That SAGE almost completely works within the
framework
of Python is one of its critical distinctions, and I won't sacrifice it.
Whatever solution we come up with for making it easy to use SAGE for
math, it has to work within that design constraint.
-- William
Bobby Moretti
These are all good reasons... I wish there was a better way than
having a predefined list of indeterminates... I could see all sorts of
things being screwed up that way. People will assign other types to,
say x, and then go ahead and call integrate(sin(x), x) again, and will
be very surprised by the result... although maybe that's an acceptable
'gotcha'.
--
Bobby Moretti
mor...@u.washington.edu
William Stein
wrote:
>> No. SAGE is not going to do this. A predefined list of variables,
>> e.g.,
>> a,..,z, A,...,Z I would consider. I won't totally change the language
>> semantics of Python. That SAGE almost completely works within the
>> framework
>> of Python is one of its critical distinctions, and I won't sacrifice it.
>> Whatever solution we come up with for making it easy to use SAGE for
>> math, it has to work within that design constraint.
>>
>> -- William
>>
>
> These are all good reasons... I wish there was a better way than
> having a predefined list of indeterminates... I could see all sorts of
> things being screwed up that way.
Such as?
> People will assign other types to,
> say x, and then go ahead and call integrate(sin(x), x) again, and will
> be very surprised by the result... although maybe that's an acceptable
> 'gotcha'.
That's exactly what would happen in Mathematica:
In[1]:= Integrate[Sin[x],x]
Out[1]= -Cos[x]
In[2]:= x := 5;
In[3]:= Integrate[Sin[x],x];
Integrate::ilim: Invalid integration variable or limit(s) in 5.
Please think hard and give me a few things that from
your "all sorts of things being screwed up that way." list that
are serious issues, so I can be more careful in designing things.
Thanks!
-- William
Bobby Moretti
> > having a predefined list of indeterminates... I could see all sorts of
> > things being screwed up that way.
>
> Such as?
Sorry, I was sort of thinking out loud. Wrong choice of words, and not
what I meant to say. A set of predefined indeterminates seems like a
pretty natural thing to have, in a mathematics software suite. We
should just make sure to explain what's really going on to people.
How would this relate to the polynomial ring naming in 1.5? Will users
confuse our predefined x, and the 'x' given for the name of a variable
in a polynomial ring that might have been declared?
I've created a wiki page for collaboration and discussion about this issue:
http://sage.math.washington.edu:9001/BasicCalculus
It doesn't have very much on it yet, but I'd like to get at the very
least a comprehensive list of guidelines and constraints to work with.
----
Bobby Moretti
mor...@u.washington.edu
William Stein
wrote:
> Sorry, I was sort of thinking out loud. Wrong choice of words, and not
> what I meant to say. A set of predefined indeterminates seems like a
> pretty natural thing to have, in a mathematics software suite. We
> should just make sure to explain what's really going on to people.
OK, good.
> How would this relate to the polynomial ring naming in 1.5? Will users
> confuse our predefined x, and the 'x' given for the name of a variable
> in a polynomial ring that might have been declared?
In SAGE-1.5, the default polynomial ring naming is exactly as in SAGE-1.4.
I fully implemented the automatic injection of polynomial ring variables
when the rings are created, but it is *off* by default. When it is on,
it is verbose, and lets the user know what is happening.
> I've created a wiki page for collaboration and discussion about this
> issue:
> http://sage.math.washington.edu:9001/BasicCalculus
Excellent.
> It doesn't have very much on it yet, but I'd like to get at the very
> least a comprehensive list of guidelines and constraints to work with.
OK. Thanks.
william
David Joyner
>>> These are all good reasons... I wish there was a better way than
>>> having a predefined list of indeterminates... I could see all sorts of
>>> things being screwed up that way.
>>>
>> Such as?
>>
It's easy to imagine things that can go wrong since this is essentially
what Maple (and Reduce/the TI92) does
and I have lots of experience with students doing Maple worksheets in a
computer lab.
The problem is to make sure that they can be easily fixed. For example,
if you want a function to be defined
this way:
f = exp(x)*sin(exp(x))
a student will want f(1) to work. Will it? I'm guessing you'll have a
function like
value(f,1) or subs(1,f)
or somethign like that. This is awkward at first for them but if it is
explained they will get used to it.
What if they want the floating point approximation to 3 decimal places?
Maybe
value(f,1.0)
or something? Again, it must be explained. I can easily imagine a
student setting x = 1 for
some reason and then having the rest of the session messed up since x is
no longer available to
them to define functions with. The student will need a command to
"clear" some of all
predefined variables (such as clear("x") or clear_all() or something
like that).
One idea, which I think students will accept, is to have a command like
load_calculus()
or something. This could for example
(a) load predefined variables,
(b) spit out a very brief screen of explanations (perhaps a list of some
available
commands, an explanation of how to get help in the notebook or on the
command-line, ...),
(c) load a bunch of teacher-defined *.sage files in examples/calculus,
(d) other stuff?
Of course, one extremely cool thing about the SAGE notebook is that you
can actually
design a special calculus control bar if you want. Maybe if you click on
help, one of the items
says calculus, and there is a link there to explain how to put a
calculus help control bar where the
normal control bar is .
All this is just brain storming. If any of it seems useful, I'm hapy to
put it on the wiki (or others
can feel free to). I'm glad this discussion is going on though!
David Harvey
On Dec 3, 2006, at 12:56 AM, Bobby Moretti wrote:
>
>>> These are all good reasons... I wish there was a better way than
>>> having a predefined list of indeterminates... I could see all
>>> sorts of
>>> things being screwed up that way.
>>
>> Such as?
>
> Sorry, I was sort of thinking out loud. Wrong choice of words, and not
> what I meant to say. A set of predefined indeterminates seems like a
> pretty natural thing to have, in a mathematics software suite. We
> should just make sure to explain what's really going on to people.
If the predefined indeterminate belongs to a ring, which ring is it?
David
William Stein
Very likely it would just be ZZ[a,b,c,d...,z, A,B,C,...,Z].
Alternatively,
they could be "formal indeterminates" that don't belong to some "formal
ring",
but that's less easy to think about.
William
William Stein
wrote:
> Bobby Moretti wrote:
>>>> These are all good reasons... I wish there was a better way than
>>>> having a predefined list of indeterminates... I could see all sorts of
>>>> things being screwed up that way.
>>>>
>>> Such as?
>>>
>
> It's easy to imagine things that can go wrong since this is essentially
> what Maple (and Reduce/the TI92) does
> and I have lots of experience with students doing Maple worksheets in a
> computer lab.
> The problem is to make sure that they can be easily fixed. For example,
> if you want a function to be defined
> this way:
>
> f = exp(x)*sin(exp(x))
>
> a student will want f(1) to work. Will it? I'm guessing you'll have a
> function like
>
> value(f,1) or subs(1,f)
>
> or somethign like that.
Yes, f(1) will work. It actually already does in the current version
of SAGE! E.g.,
sage: f = sin(x)*cos(sin(x))
sage: f(1)
(sin(1)*cos(sin(1)))
sage: a = f(1)
sage: a
(sin(1)*cos(sin(1)))
sage: float(a)
0.56072828148897991
> This is awkward at first for them but if it is
> explained they will get used to it.
> What if they want the floating point approximation to 3 decimal places?
> Maybe
>
> value(f,1.0)
>
> or something?
No way, that's way too hard to remember. Here's what is already
implemented
in SAGE:
sage: f(1.0)
0.560728281488980
> Again, it must be explained. I can easily imagine a
> student setting x = 1 for
> some reason and then having the rest of the session messed up since x is
> no longer available to
> them to define functions with.
That's a problem in maple, mathematica, etc.
> The student will need a command to
> "clear" some of all
> predefined variables (such as clear("x") or clear_all() or something
> like that).
Clear could easily set the variable back to being an indeterminate.
> One idea, which I think students will accept, is to have a command like
>
> load_calculus()
>
> or something. This could for example
> (a) load predefined variables,
> (b) spit out a very brief screen of explanations (perhaps a list of some
> available
> commands, an explanation of how to get help in the notebook or on the
> command-line, ...),
> (c) load a bunch of teacher-defined *.sage files in examples/calculus,
> (d) other stuff?
>
> Of course, one extremely cool thing about the SAGE notebook is that you
> can actually
> design a special calculus control bar if you want. Maybe if you click on
> help, one of the items
> says calculus, and there is a link there to explain how to put a
> calculus help control bar where the
> normal control bar is .
Very interesting idea.
William
Joel B. Mohler
current design with regards to simple calculus. I think they uncover some
oddities in the current design, but I'm not entirely sure what they mean.
The results acheived are far from what a novice might expect and IMO rather
bizarre even to the expert.
********* Exhibit 1: (Is x==y? Shouldn't this be a syntax error?)
sage: x.parent()
Univariate Polynomial Ring in x over Rational Field
sage: P,y=ZZ['y'].objgen()
sage: f=cos(x)*sin(y)
sage: f(1)
(cos(1)*sin(1))
*********************
********* Exhibit 2: (What in the world does sin(x)(1) mean?)
sage: P,(x,y)=ZZ['x,y'].objgens()
sage: f=sin(x)
sage: f(1)
sin(x)(1)
sage: float(f(1))
# disaster strikes
*********************
********* Exhibit 3: (Shouldn't this be a type error?)
sage: P,x=IntegerModRing(17)['x'].objgen()
sage: f=sin(x)
sage: f(18)
sin(1)
*********************
Perhaps the most important is "Exhibit 2". To my eyes, a function definition
is not complete with-out a clearly defined argument list. Piggybacking on
top of argument lists to polynomial rings seems like it will lead to endless
pains of the nature of the creatures above.
--
Joel
William Stein
<jo...@kiwistrawberry.us> wrote:
>
> I have a couple of cases that I think scratch around at the boundaries
> of the
> current design with regards to simple calculus. I think they uncover
> some
> oddities in the current design, but I'm not entirely sure what they mean.
> The results acheived are far from what a novice might expect and IMO
> rather
> bizarre even to the expert.
>
> ********* Exhibit 1: (Is x==y? Shouldn't this be a syntax error?)
> sage: x.parent()
> Univariate Polynomial Ring in x over Rational Field
> sage: P,y=ZZ['y'].objgen()
> sage: f=cos(x)*sin(y)
> sage: f(1)
> (cos(1)*sin(1))
> *********************
Yes, this should be a syntax error.
> ********* Exhibit 2: (What in the world does sin(x)(1) mean?)
> sage: P,(x,y)=ZZ['x,y'].objgens()
> sage: f=sin(x)
> sage: f(1)
> sin(x)(1)
> sage: float(f(1))
> # disaster strikes
> *********************
Yes, this is wrong. But it's just a NotImplementedError, i.e., the
__call__
method of sin doesn't do anything with multivariate polynomials, so it just
forms the formal evaluation sin(x), which it doesn't know what to do with.
> ********* Exhibit 3: (Shouldn't this be a type error?)
> sage: P,x=IntegerModRing(17)['x'].objgen()
> sage: f=sin(x)
> sage: f(18)
> sin(1)
> *********************
Yes, it should be a type error.
> Perhaps the most important is "Exhibit 2". To my eyes, a function
> definition
> is not complete with-out a clearly defined argument list. Piggybacking
> on
> top of argument lists to polynomial rings seems like it will lead to
> endless
> pains of the nature of the creatures above.
This is simply how symbolic mathematics, in particular calculus, works.
It does lead to pain and confusion in many calculus classes. I don't
think dealing with this will be easy. But I think it's absolutely crucial
in order for SAGE to ever be a viable alternative to Maple/Mathematica.
All your examples above are very good, and will help inform the design
that we come up with. Thanks! Keep 'em coming! (Could somebody please
post something based on all this into the wiki -- I suddenly only have
limited net access for the next few days).
William
Bobby Moretti
>
> On Sun, 03 Dec 2006 10:38:20 -0800, Joel B. Mohler
> <jo...@kiwistrawberry.us> wrote:
>
> > Perhaps the most important is "Exhibit 2". To my eyes, a function
> > definition
> > is not complete with-out a clearly defined argument list. Piggybacking
> > on
> > top of argument lists to polynomial rings seems like it will lead to
> > endless
> > pains of the nature of the creatures above.
>
> This is simply how symbolic mathematics, in particular calculus, works.
> It does lead to pain and confusion in many calculus classes. I don't
> think dealing with this will be easy. But I think it's absolutely crucial
> in order for SAGE to ever be a viable alternative to Maple/Mathematica.
Agreed.
> All your examples above are very good, and will help inform the design
> that we come up with. Thanks! Keep 'em coming! (Could somebody please
> post something based on all this into the wiki -- I suddenly only have
> limited net access for the next few days).
Done.
--
Bobby Moretti
mor...@u.washington.edu
Joel B. Mohler
> > ********* Exhibit 2: (What in the world does sin(x)(1) mean?)
> > sage: P,(x,y)=ZZ['x,y'].objgens()
> > sage: f=sin(x)
> > sage: f(1)
> > sin(x)(1)
> > sage: float(f(1))
> > # disaster strikes
> > *********************
>
> Yes, this is wrong. But it's just a NotImplementedError, i.e., the
> __call__
> method of sin doesn't do anything with multivariate polynomials, so it just
> forms the formal evaluation sin(x), which it doesn't know what to do with.
Yes, but what should occur here? I think that f is a function that should
take 2 variables since I could say "f=sin(x*y)". In this light, the actual
correct operation above is that "f(1)" gives a NotEnoughArgumentsError. So,
the general principle would be that the function takes as many variables as
are in the polynomial ring whose elements appears as arguments to formal
functions (Isn't that a hideous description? -- which alarms me because the
design appears to demand that hideous description). This has a side-effect
though. If the indeterminates all come from ZZ[a,b,c,d...,z, A,B,C,...,Z] as
stated earlier, that means all of these functions will take 52 variables.
That's clearly not what we want. Am I missing some other obvious design?
> > Perhaps the most important is "Exhibit 2". To my eyes, a function
> > definition
> > is not complete with-out a clearly defined argument list. Piggybacking
> > on
> > top of argument lists to polynomial rings seems like it will lead to
> > endless
> > pains of the nature of the creatures above.
>
> This is simply how symbolic mathematics, in particular calculus, works.
> It does lead to pain and confusion in many calculus classes. I don't
> think dealing with this will be easy. But I think it's absolutely crucial
> in order for SAGE to ever be a viable alternative to Maple/Mathematica.
Yes, I definitely agree that this is critical to make sage a maple replacement
(which is certainly one of my desires for SAGE). It's a royal pain to
differentiate a simple function in SAGE as it stands now.
My comments above lead me to believe that we really need to step outside the
polynomial ring box though. I'm pretty firmly of the belief that we need to
be able to declare formal indeterminants. They are essentially things of the
type sage.functions.functions.Function_arith that behave as identity
functions.
--
Joel
Bobby Moretti
> ...
> One idea, which I think students will accept, is to have a command like
>
> load_calculus()
>
> or something. This could for example
> (a) load predefined variables,
> (b) spit out a very brief screen of explanations (perhaps a list of some
> available
> commands, an explanation of how to get help in the notebook or on the
> command-line, ...),
> (c) load a bunch of teacher-defined *.sage files in examples/calculus,
> (d) other stuff?
I thought about something like this. My initial reaction is to caution
against making SAGE too 'modey'... sometimes I get annoyed by such
programs. (But then again I use vi as my editor of choice).
Also, having different modes could break interoperativity between
different parts of SAGE... something we should try to avoid.
I think I like the idea of a 'simple mode' calculus bar. I think we
could implement it in a way that doesn't clutter our interface too
much. Perhaps that could go hand-in-hand with loading the predefined
indeterminates?
> Of course, one extremely cool thing about the SAGE notebook is that you
> can actually
> design a special calculus control bar if you want. Maybe if you click on
> help, one of the items
> says calculus, and there is a link there to explain how to put a
> calculus help control bar where the
> normal control bar is .
>
> All this is just brain storming. If any of it seems useful, I'm hapy to
> put it on the wiki (or others
> can feel free to). I'm glad this discussion is going on though!
Yes, please put any ideas that you have on the wiki. Again, the page
is http://sage.math.washington.edu:9001/BasicCalculus
--
Bobby Moretti
mor...@u.washington.edu
David Harvey
On Dec 3, 2006, at 3:25 PM, Joel B. Mohler wrote:
> My comments above lead me to believe that we really need to step
> outside the
> polynomial ring box though.
I tentatively agree with this assessment. Polynomial rings don't seem
to be the right thing here.
David
William Stein
wrote:
>> or something. This could for example
>> (a) load predefined variables,
>> (b) spit out a very brief screen of explanations (perhaps a list of some
>> available
>> commands, an explanation of how to get help in the notebook or on the
>> command-line, ...),
>> (c) load a bunch of teacher-defined *.sage files in examples/calculus,
>> (d) other stuff?
>
> I thought about something like this. My initial reaction is to caution
> against making SAGE too 'modey'... sometimes I get annoyed by such
> programs. (But then again I use vi as my editor of choice).
I don't like this at all. We have a serious design challenge which is
to make something that really does both calculus and serious math. I say
we face that challenge head on and find a good solution, even if it means
a lot of very hard thought. I like the challenge.
> Also, having different modes could break interoperativity between
> different parts of SAGE... something we should try to avoid.
Yep. That the programs SAGE interfaces with are "modey" is one reason
why it's possible for SAGE to work at all.
> I think I like the idea of a 'simple mode' calculus bar. I think we
> could implement it in a way that doesn't clutter our interface too
> much. Perhaps that could go hand-in-hand with loading the predefined
> indeterminates?
I see no reason at all not to always have a,...,z, and A,..,Z predefined
in all cases.
William
Joel B. Mohler
> > If the predefined indeterminate belongs to a ring, which ring is it?
>
> Very likely it would just be ZZ[a,b,c,d...,z, A,B,C,...,Z].
> Alternatively,
> they could be "formal indeterminates" that don't belong to some "formal
> ring",
> but that's less easy to think about.
What if you want to differentiate f(x)=x^x. This is senseless in a polynomial
ring.
--
Joel
William Stein
This is the same as saying that "1/2" is senseless if 1 and 2
are integers.
This is not a problem. That the expression x^x does not define an element
of the polynomial ring, is not a problem.
Exponentiation of an element of the polynomial ring to the power
of a non-integer would be a constructor for some other sort of object,
namely a function in some general function space.
William
David Joyner
calculus, I'd like us to keep one thing in mind.
Busy students, at all levels of intelligence, are extremely good
at doing one type of calculation: how long with it take to do a given
task. The average student is not computer-savvy and so we
must be sensitive to these easily-frustrated students.
There are two sides:
(1) those for predefining variables and rings
(2) those against predefining variables and rings.
I've presented a compomise (in order to predefine variables and rings,
you have to enter a command such as "load_calculus").
(1) is probably the simplest solution but whatever works easily for the
student user is fine with me.
Joel B. Mohler
I'm not sure I entirely agree with this. I see that it could be done this
way, but it seems quite mathematically strange to me. The fraction field of
a ring is a well-known mathematical object, but the idea of putting a
generator for a polynomial ring in an exponent is entirely undefined in any
abstract sense (unless there's some mathematics I'm missing).
--
Joel
William Stein
It defines the formal function x |--> x^x, which is defined on all
numbers x such that x^x is defined. It is at least as meaningful as
the following:
def f(x):
return x^x
William
Robert Bradshaw
dummy variables and have should really have no context outside of the
function definition. Another problem is that, if we say f = sin(a)+cos
(x), then f(1,2) is ambiguous. Here's what I think should happen:
f = sin(x) should be illegal (though I'm not sure how to throw an
informative error here). Instead one should have to type f(x) = sin
(x). This would be pre-parsed to something like
with inject_indetermanents('x'):
f = sin(x)
Here inject_indetermanents would be assign x to an indetermanent that
knows both its name (for printing) and its position (in the tuple if
f is called with multiple arguments, and x is recursively called down
the tree). It would be a morphism of the category of sets and always
act as the identity function on __call__. It could, say, know how to
differentiate itself (return 1 if the variable with respect to
integration matches self.name, 0 (or dx/dother) otherwise. It would
support addition, exponentiation, etc. via a generic "sum" class that
takes two functions and returns a function. Coercible into R[x], etc.
(I'm not sure how contexts work, perhaps the all the indetermanents
in the block would have to be wrapped... this is still doable via
regular expressions...)
Any comments?
- Robert
Joel B. Mohler
>
> I think we are thinking of these indetermanents wrongly--they are
> dummy variables and have should really have no context outside of the
> function definition. Another problem is that, if we say f = sin(a)+cos
> (x), then f(1,2) is ambiguous. Here's what I think should happen:
>
> f = sin(x) should be illegal (though I'm not sure how to throw an
> informative error here). Instead one should have to type f(x) = sin
> (x). This would be pre-parsed to something like
>
> with inject_indetermanents('x'):
> f = sin(x)
>
> Here inject_indetermanents would be assign x to an indetermanent that
> knows both its name (for printing) and its position (in the tuple if
> f is called with multiple arguments, and x is recursively called down
> the tree). It would be a morphism of the category of sets and always
> act as the identity function on __call__. It could, say, know how to
> differentiate itself (return 1 if the variable with respect to
> integration matches self.name, 0 (or dx/dother) otherwise. It would
> support addition, exponentiation, etc. via a generic "sum" class that
> takes two functions and returns a function. Coercible into R[x], etc.
>
> (I'm not sure how contexts work, perhaps the all the indetermanents
> in the block would have to be wrapped... this is still doable via
> regular expressions...)
>
> Any comments?
I like this proposal a great deal. It fixes all of my complaints that
I've been bringing up about polynomial rings. It is however very
difficult to actually implement this with-out pre-parser logic. I'm
not certain how much of a downside that is.
One other downside is that these indeterminants would not be
elements in the polynomial ring and so it seems that they would not
benefit from the speed of the polynomial arithmetic architecture. That
is to say, you could have polynomials in sage which don't know they
are polynomials so I guess all the computation would use the most
naive methods of computation and not utilize the heavily optimized
polynomial code. This would be rather sad.
However, if you want to make a decently usable calculus interface, I
think you will have to make some sacrifices of this nature.
--
Joel
Robert Bradshaw
Yes, though at least here the preparser rule is stateless and simple. The
"pythonic" way of defining functions is
def f(x):
return x - sin(x)
or even
f = lambda x: x - sin(x)
which doesn't allow us to do, say, (symbolic) calculus on the returned
object--we'd probably want the returned result to be an instance of
ElementaryFunction. It seems reasonable to use the preparser to create a
simple, intuitive way of defining _mathematical_ functions.
Also, this could co-exist with whatever (predefined or not) values are
assigned to x.
> One other downside is that these indeterminants would not be
> elements in the polynomial ring and so it seems that they would not
> benefit from the speed of the polynomial arithmetic architecture. That
> is to say, you could have polynomials in sage which don't know they
> are polynomials so I guess all the computation would use the most
> naive methods of computation and not utilize the heavily optimized
> polynomial code. This would be rather sad.
This is true, but I think that if someone wants the full speed and
functionality of polynomials one should create the object as a polynomial
(or at least cast it into such a ring--this should be fully supported).
Also, polynomials (currently) are always stored in their expanded version,
which may or may not be desired (I'm thinking of calculus students here).
William Stein
<robe...@math.washington.edu> wrote:
> On Mon, 4 Dec 2006, Joel B. Mohler wrote:
>> On Mon, Dec 04, 2006 at 09:46:18AM -0800, Robert Bradshaw wrote:
>>> I think we are thinking of these indetermanents wrongly--they are
>>> dummy variables and have should really have no context outside of the
>>> function definition. Another problem is that, if we say f = sin(a)+cos
>>> (x), then f(1,2) is ambiguous.
Because the order of arguments is not specified? I disagree to some
extent, since you could likewise say that if f = a*x in Q[a,x], then
f(1,2) is
ambigous. Likewise, in the above example, just use the alphabetical
order of the variable names.
>>> f = sin(x) should be illegal (though I'm not sure how to throw an
>>> informative error here).
That means writing "sin(x)" is illegal, so
show(plot(sin(x)))
is illegal, and lots of other things like
integrate(sin(x), x)
In mathematica (and maxima) right now I can type
Integrate[sin[x], x]
and it works, which is a good thing. In Maxima, I can type
integrate(sin(x), x)
and it works fine. *This* is the main design goal. I.e., to
be able to do computations like above and have them work directly
in SAGE (without having to type maxima('integrate(sin(x), x)')).
Thus making "f = sin(x)" illegal violates our basic design goal.
Also, the following should work:
integrate(sin(x*y) + z, x)
and give 'x*z - cos(x*y)/y' as output.
Examples like above are what I meant when I requested a list
of samples of what our proposed calculus, etc., functionality
for SAGE should do. In fact, an excellent way to decide
what we want is to take a bunch of calculus problems from
a calculus book and try to make up how you would type
them into SAGE. If the way isn't fairly straightforward
and natural for undergraduates, we have more work to do.
In math single-letter variables names are totaly standard,
so we're OK with that. A possible problem is what to do
about things like
sin(x_0 + x_1 + x_2^3)
How do we make it possible to specify subscripted variables?
Maybe x[0] x[1] x[2], etc., and make it so our formal
variables a,...,z, A,...,Z have their __getitem__ method overloaded
to return new variables?
Moreover, and I can tell you this from lots of experience,
any use of the preparser must be avoided if at all possible.
Anything that involves the preparser is also bad, because it
is very painful and error prone to move code that was written
with the preparser to library .py code. I always regret that
the preparser is used at all, but there is no escaping that it
is needed a little.
>>> Instead one should have to type f(x) = sin
>>> (x). This would be pre-parsed to something like
>>>
>>> with inject_indetermanents('x'):
>>> f = sin(x)
>>>
>>> Here inject_indetermanents would be assign x to an indetermanent that
>>> knows both its name (for printing) and its position (in the tuple if
>>> f is called with multiple arguments, and x is recursively called down
>>> the tree). It would be a morphism of the category of sets and always
>>> act as the identity function on __call__. It could, say, know how to
>>> differentiate itself (return 1 if the variable with respect to
>>> integration matches self.name, 0 (or dx/dother) otherwise. It would
>>> support addition, exponentiation, etc. via a generic "sum" class that
>>> takes two functions and returns a function. Coercible into R[x], etc.
>>>
>>> (I'm not sure how contexts work, perhaps the all the indetermanents
>>> in the block would have to be wrapped... this is still doable via
>>> regular expressions...)
Pain!
Joel B. Mohler
> On Mon, 04 Dec 2006 16:03:45 -0800, Robert Bradshaw
>
> <robe...@math.washington.edu> wrote:
> > On Mon, 4 Dec 2006, Joel B. Mohler wrote:
> >> On Mon, Dec 04, 2006 at 09:46:18AM -0800, Robert Bradshaw wrote:
> >>> I think we are thinking of these indetermanents wrongly--they are
> >>> dummy variables and have should really have no context outside of the
> >>> function definition. Another problem is that, if we say f = sin(a)+cos
> >>> (x), then f(1,2) is ambiguous.
>
> Because the order of arguments is not specified? I disagree to some
> extent, since you could likewise say that if f = a*x in Q[a,x], then
> f(1,2) is
> ambigous. Likewise, in the above example, just use the alphabetical
> order of the variable names.
So, you are willing to throw out the ability to order your own arguments? I
suppose that technically this doesn't cut down on functionality, but there is
quite often I might want a function of 'x' and 'n' and want them in that
order. I think this will be *very* annoying in the long run. I also think
that single letter variable names will be a strange limitation -- I often
want a 'theta' in mathematica. I realize that I could define my own
polynomial ring, but thats a strange user requirement to my eyes.
So, if we have Q[a,x] and f=x. Is f a function of 1 or 2 variables? I think
it should be a function of 2 variables (the a is implicit). I gather that
you (William) disagree with this, but I'm not sure how you are going to code
that up. I'm also not sure that it will be user comprehensible in the end.
--
Joel
Joel B. Mohler
> >>> informative error here).
>
> That means writing "sin(x)" is illegal, so
>
> show(plot(sin(x)))
>
> is illegal
I realize that some of the things that Robert & I are saying would make the
above plot much more complicated to generate (personally, the result of that
plot command is near useless so I'm not sure I care, but it's nice to have
default bounds I guess). However, I think that if the above plot command
works, the following should also:
sage: show(plot(1))
---------------------------------------------------------------------------
<type 'exceptions.ValueError'> Traceback (most recent call last)
/home/joel/<ipython console> in <module>()
/home/joel/sage-1.5.alpha6/local/lib/python2.5/site-packages/sage/plot/plot.py
in __call__(self, funcs, xmin, xmax, parametric, polar, show, **kwds)
2096 data.append((x, float(y)))
2097 except (TypeError, ValueError), msg:
-> 2098 raise ValueError, "Unable to compute f(%s)"%x
2099 # adaptive refinement
2100 i, j = 0, 0
<type 'exceptions.ValueError'>: Unable to compute f(-0.99139086463)
*****************************************************************************
My suggestion for a fix is that the input to plot command should be coerced to
a function of one variable and then evaluated. Constants would, of course,
be coerced to the constant function.
--
Joel
William Stein
<jo...@kiwistrawberry.us> wrote:
>
> On Tuesday 05 December 2006 02:43, William Stein wrote:
>> >>> f = sin(x) should be illegal (though I'm not sure how to throw an
>> >>> informative error here).
>>
>> That means writing "sin(x)" is illegal, so
>>
>> show(plot(sin(x)))
>>
>> is illegal
>
> I realize that some of the things that Robert & I are saying would make
> the
> above plot much more complicated to generate (personally, the result of
> that
> plot command is near useless so I'm not sure I care, but it's nice to
> have
> default bounds I guess).
The bounds are irrelevant for this discussion. Surely you wouldn't
say that the results of
show(plot(sin(x), 0, 2*pi))
is "nearly useless", would you? This works in the current version of
SAGE already, and is very natural.
> However, I think that if the above plot command
> works, the following should also:
>
> sage: show(plot(1))
Yes. That it doesn't is a bug.
> ---------------------------------------------------------------------------
> <type 'exceptions.ValueError'> Traceback (most recent call
> last)
>
> /home/joel/<ipython console> in <module>()
>
> /home/joel/sage-1.5.alpha6/local/lib/python2.5/site-packages/sage/plot/plot.py
> in __call__(self, funcs, xmin, xmax, parametric, polar, show, **kwds)
> 2096 data.append((x, float(y)))
> 2097 except (TypeError, ValueError), msg:
> -> 2098 raise ValueError, "Unable to compute f(%s)"%x
> My suggestion for a fix is that the input to plot command should be
> coerced to
> a function of one variable and then evaluated. Constants would, of
> course,
> be coerced to the constant function.
The solution in mathematica and most systems is that one
has to give the variable one is plotting with respect to.
You know, honestly, the problem of how to express do Calculus with
a computer algebra system is not exactly a new one. It's been
to some degree completely and totally solved by Mathematica.
Maybe the real discussion we should be having is how can we
make a basic interface to SAGE for doing calculus that is very similar
to mathematica's? Only if there is a strong technical reason why
something is not possible in Python, should we even be having these
discussions. Basically, before we continue going along the route
suggested by you and Robert, I would like a very good justification
for why Mathematica/Maple got it wrong (despite millions of users
and two decades of polishing and work). Otherwise, I don't understand
why we don't just do something similar to Mathematica. This reduces
the learning curve for some people a lot, and means we spend time
solving problems instead of coming up with a new design that is probably
wrong anyways, then spending a lot of time testing it, only to find
that it really doesn't work for various reasons.
What do you think Bobby?
We are building the car, not reinventing the wheel.
-- William
David Harvey
On Dec 5, 2006, at 12:29 PM, William Stein wrote:
> You know, honestly, the problem of how to express do Calculus with
> a computer algebra system is not exactly a new one. It's been
> to some degree completely and totally solved by Mathematica.
> Maybe the real discussion we should be having is how can we
> make a basic interface to SAGE for doing calculus that is very similar
> to mathematica's? Only if there is a strong technical reason why
> something is not possible in Python, should we even be having these
> discussions. Basically, before we continue going along the route
> suggested by you and Robert, I would like a very good justification
> for why Mathematica/Maple got it wrong (despite millions of users
> and two decades of polishing and work). Otherwise, I don't understand
> why we don't just do something similar to Mathematica. This reduces
> the learning curve for some people a lot, and means we spend time
> solving problems instead of coming up with a new design that is
> probably
> wrong anyways, then spending a lot of time testing it, only to find
> that it really doesn't work for various reasons.
I agree with these sentiments. The only problem is that perhaps
Mathematica semantics differ considerably from Python's from the
ground up, and this would make it very difficult to have both in the
same interface. I haven't used Mathematica for a long time, but when
I did, I distinctly remember the feeling of never being quite sure
what the "type" of my objects was; whereas Python has a very strong
notion of type. But it could be simply that I hadn't had much
programming experience back then.
I wish I could contribute more usefully to this discussion, I think
it's an extremely important one, because being able to do calculus is
critical to SAGE's mainstream acceptance. But I just don't have
enough familiarity with Mathematica/Maple. (Or calculus for that
matter. Crap I have to go and teach div/grad/curl in 60 minutes.)
David
Joel B. Mohler
> You know, honestly, the problem of how to express do Calculus with
> a computer algebra system is not exactly a new one. It's been
> to some degree completely and totally solved by Mathematica.
> Maybe the real discussion we should be having is how can we
> make a basic interface to SAGE for doing calculus that is very similar
> to mathematica's? Only if there is a strong technical reason why
> something is not possible in Python, should we even be having these
> discussions. Basically, before we continue going along the route
> suggested by you and Robert, I would like a very good justification
> for why Mathematica/Maple got it wrong (despite millions of users
> and two decades of polishing and work). Otherwise, I don't understand
> why we don't just do something similar to Mathematica. This reduces
> the learning curve for some people a lot, and means we spend time
> solving problems instead of coming up with a new design that is probably
> wrong anyways, then spending a lot of time testing it, only to find
> that it really doesn't work for various reasons.
William, thanks for your kind hint for me to be quiet a bit. I believe you are
right that I should be so. After this e-mail and a few additions to the wiki, I
will be quiet on this topic.
However, I don't agree that the suggestion of using variables from the
polynomial ring is doing what mathematica does. Some Examples:
Exhibit 1: My understanding is that you want f(1) to be 1 in sage, but
mathematica is not so.
In[1]:= f=x
Out[1]= x
In[2]:= f(1)
Out[2]= x
Exhibit 2: Mathematica has a dummy variable.
In[12]:= f[x_]:=Sin[x]
In[13]:= f'[x]
Out[13]= Cos[x]
In[14]:= f'[y]
Out[14]= Cos[y]
Exhibit 3: Part of the expected second variable is the name of the independent
variable.
In[6]:= Plot[Sin[x]]
Plot::argmu: Plot called with 1 argument; 2 or more arguments are expected.
I apologize if I've made too much noise about all this, but I think that a clear
concept of a dummy variable needs to be introduced. I have thought of no easy
way to do that with-out a rather painful bit of preparsing. I definitely agree
that the preparser should be avoided if possible. Currently, I see no evidence
that we can have a real idea of dummy variables with-out pre-parser work.
--
Joel
William Stein
<jo...@kiwistrawberry.us> wrote:
> William, thanks for your kind hint for me to be quiet a bit. I believe
> you are
> right that I should be so. After this e-mail and a few additions to the
> wiki, I
> will be quiet on this topic.
No, don't be quiet!!
> However, I don't agree that the suggestion of using variables from the
> polynomial ring is doing what mathematica does. Some Examples:
>
> Exhibit 1: My understanding is that you want f(1) to be 1 in sage, but
> mathematica is not so.
> In[1]:= f=x
> Out[1]= x
> In[2]:= f(1)
> Out[2]= x
>
> Exhibit 2: Mathematica has a dummy variable.
> In[12]:= f[x_]:=Sin[x]
> In[13]:= f'[x]
> Out[13]= Cos[x]
> In[14]:= f'[y]
> Out[14]= Cos[y]
>
> Exhibit 3: Part of the expected second variable is the name of the
> independent
> variable.
> In[6]:= Plot[Sin[x]]
> Plot::argmu: Plot called with 1 argument; 2 or more arguments are
> expected.
I was also confused about this.
Maple and Mathematica have symbolic expressions, like Sin[x] * Cos[y],
(or sin(x)*cos(y)), which you *can not* evalaute in those systems!
You can only do a variant of "substitution". This is what we should
do too, and doesn't require the preprocessor. In order to define
a function to be evaluated, one should just use Python's def or lambda.
Example in Maple:
auth2-213:~/s/spkg/standard was$ maple
|\^/| Maple 10 (APPLE PPC OSX)
._|\| |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc.
2005
\ MAPLE / All rights reserved. Maple is a trademark of
<____ ____> Waterloo Maple Inc.
| Type ? for help.
> f = sin(x);
f = sin(x)
> f(2);
f(2)
> f;
f
> f := sin(x);
f := sin(x)
> f;
sin(x)
> integrate(f, x);
-cos(x)
> f(2);
sin(x)(2)
> subs(x=2,f);
sin(2)
Example in Mathematica:
auth2-213:~/s/spkg/standard was$ math
Mathematica 5.2 for Mac OS X
Copyright 1988-2005 Wolfram Research, Inc.
-- Terminal graphics initialized --
In[1]:= f := Sin[x];
In[2]:= f[2];
In[3]:= f[2]
Out[3]= Sin[x][2]
In[4]:= Integrate[f, x];
In[5]:= Integrate[f,x]
Out[5]= -Cos[x]
OK, I forget how to subst in mathematica, but I have to go now.
Also, PARI has this same distinction too.
? f = x*y
%2 = y*x
? f(2,3)
*** unused characters: f(2,3)
^-----
? subst(f,x,2)
%3
= 2*y
Bobby Moretti
William, I know you're busy right now, but when you get a chance could
you give an example of what a SAGE session with this type of
substitution would look like?
--
Bobby Moretti
mor...@u.washington.edu
Bobby Moretti
I agree as well. Any language issues aside, there's no reason at all
to reinvent the wheel on this. However, there are some issues that we
have do deal with that are no problem for maple or mathematica:
> We have a serious design challenge which is
> to make something that really does both calculus and serious math. I say
> we face that challenge head on and find a good solution, even if it means
> a lot of very hard thought. I like the challenge.
I think a smooth transition between calculus and 'serious math' is
key, or at the very least being able to naturally use both in the same
session.
While it will be nice for SAGE's calculus interface to be immediately
available to Mathematica and Maple users with no learning curve, it is
just as important that we minimize the learning curve for someone who
knows calculus, but may not know any computer algebra language.
It's been a while since I've used Mathematica myself. From what I
recall, Mathematica handles basic calculus pretty well. I'm going to
go refamiliarize myself with it a bit today...
--
Bobby Moretti
mor...@u.washington.edu
alex clemesha
I have used Mathematica for several years, and for Symbolic computation,
IMO, it just *by far the best*, so I totally agree with what is said here:
> > You know, honestly, the problem of how to express do Calculus with
> > a computer algebra system is not exactly a new one. It's been
> > to some degree completely and totally solved by Mathematica.
>Also, having an easy-to-use calculus package that displays its output prettily is a must for any self-respecting CAS. >With jsMath and Maxima, we have a real potential to blow away the competition here. And finally, calculus is kind of >a lowest common denominator among people who are using a CAS. It's probably the first thing that any >non-mathematician would try... first impressions are important.
So we need to:
1) Study the details of how Mathematica (Maple?) does symbolic computation.
2) Implement it in Python using Maxima (While not breaking Python *at all* !, semantics, preparser,etc!)
It seems that a lot of discussion in this thread has to do with the
semantics of defining a function.
In python one can use either:
def or lambda
In SAGE one can use either:
def, lambda, or existing ' sage.functions.functions.Function_arith' types
In Mathematica, one must use the
"Blank" _, "BlankSequence" __, or "BlankNullSequence" ___, pattern objects
to specify replacement rules.
i.e:
(* Using a "Blank" pattern *)
In[5]:= f[x_]:=x*Sin[x]
(* Replace with y *)
In[6]:=f[y]
Out[6]=y Sin[y]
(* Replace with Integer *)
In[9]:=f[1]
Out[9]=Sin[1]
(* Replace with Real *)
In[10]:=f[1.0]
Out[10]=0.841471
(* Explicitly do Rule substitution *)
In[11]:=f[x]/.x->1.0
Out[11]=0.841471
(* Now with NO Blank Rule object *)
In[1]:=g[x]=x*Sin[x]
Out[1]=x Sin[x]
(* NO substitution occurs *)
In[2]:=g[y]
Out[2]=g[y]
(* The object "g[x]" is exactly "x Sin[x]" *)
In[4]:=g[x]
Out[4]=x Sin[x]
So more discussion is needed about all this,
I think making symbolic computation from SAGE very usable is an
great challenge that we should embrace.
-Alex
William Stein
wrote:
> William, I know you're busy right now, but when you get a chance could
> you give an example of what a SAGE session with this type of
> substitution would look like?
Here's an example. It actually works today if you change one line
of interfaces/maxima.py, and it gives a flavor of what we want if
you ignore the top line involving maxima:
# ignore the following two lines
sage: sin = maxima('sin'); cos=maxima('cos'); exp=maxima('exp');
tan=maxima('tan')
sage: R.<x,y,z> = QQ[]
# what I basically want (and which already works today with the setup
above):
sage: f = sin(x) + cos(x*y) + exp(2*x*y); f
cos(x*y) + %e^(2*x*y) + sin(x)
sage: g = f.ev('z=sqrt(2)', 'y=2/3'); g # substitutions
sin(x) + cos(2*x/3) + %e^(4*x/3)
sage: h = g.integrate(x); h
-cos(x) + 3*sin(2*x/3)/2 + 3*%e^(4*x/3)/4
sage: k = h.diff(x); k
sin(x) + cos(2*x/3) + %e^(4*x/3)
sage: tan(10)
tan(10)
sage: float(tan(10))
0.64836082745908663
-------------
Substitutions would have to work differently in SAGE though, e.g., as
in the following *fantasy* session:
sage: f = sin(x) + cos(x*y) + exp(2*x*y); f
cos(x*y) + exp(2*x*y) + sin(x)
sage: g = f.subs( (z,sqrt(2)), (y,2/3)); g # substitutions
sin(x) + cos(2*x/3) + e^(4*x/3)
sage: h = g.integrate(x); h
-cos(x) + 3*sin(2*x/3)/2 + 3*exp(4*x/3)/4
sage: k = h.diff(x); k
sin(x) + cos(2*x/3) + exp(4*x/3)
sage: tan(10)
tan(10)
sage: float(tan(10))
0.64836082745908663
Non one-letter vars:
sage: theta = var('theta')
sage: g = sin(theta) + cos(theta) + x^2 + y
sage: g.subs(theta, 3)
sin(3) + cos(3) + x^2 + y
sage: g.subs((theta, 3), (x,5))
sin(3) + cos(3) + 25 + y
Subscripts could be via a dot notation or square brackets, which would
fit well with the current impelmentation:
sage: f = cos(x.0 + 7*x.1 + 3*x.2)
or alternatively,
sage: f = cos(x[0] + 7*x[1] + 3*x[2])
The second version requires no preparsing. The first does, but it's
already
done -- x.[number] alread gets preparsed to x.gen(number).
Anybody who seriously wants to get into this calculus discussion for SAGE
definitely *MUST* take a good look through the maxima documentation, since
Maxima is, for Calculus, an amazingly powerful program, which already does
everything -- and which will be doing all the heavily lifting. The problem
is just that we need to do much more than we have to make Maxima's really
amazing power very easy to use in SAGE. I.e., basically I'd like
something
that feels like the best of Maple/Mathematica but is implemented mostly
behind the scenes using Maxima. This is exactly the analogue of
what Alex Clemesha has been doing with graphics for SAGE, but for calculus.
-- William
William Stein
wrote:
> On 12/5/06, David Harvey <dmha...@math.harvard.edu> wrote:
>> On Dec 5, 2006, at 12:29 PM, William Stein wrote:
>> > You know, honestly, the problem of how to express do Calculus with
>> > a computer algebra system is not exactly a new one. It's been
>> > to some degree completely and totally solved by Mathematica.
>> > Maybe the real discussion we should be having is how can we
>> > make a basic interface to SAGE for doing calculus that is very similar
>> > to mathematica's? Only if there is a strong technical reason why
>> > something is not possible in Python, should we even be having these
>> > discussions. Basically, before we continue going along the route
>> > suggested by you and Robert, I would like a very good justification
>> > for why Mathematica/Maple got it wrong (despite millions of users
>> > and two decades of polishing and work). Otherwise, I don't understand
>> > why we don't just do something similar to Mathematica. This reduces
>> > the learning curve for some people a lot, and means we spend time
>> > solving problems instead of coming up with a new design that is
>> > probably
>> > wrong anyways, then spending a lot of time testing it, only to find
>> > that it really doesn't work for various reasons.
>>
>> I agree with these sentiments. The only problem is that perhaps
>> Mathematica semantics differ considerably from Python's from the
>> ground up, and this would make it very difficult to have both in the
>> same interface.
This is not true, and the graphics project Alex carried out proves it.
Things get made "pythonic", but fundamentally Python supports a wide
range of ways of programming (e.g., functional, object oriented,
procedural,
etc.,).
>> I haven't used Mathematica for a long time, but when
>> I did, I distinctly remember the feeling of never being quite sure
>> what the "type" of my objects was; whereas Python has a very strong
>> notion of type. But it could be simply that I hadn't had much
>> programming experience back then.
>>
>> I wish I could contribute more usefully to this discussion, I think
>> it's an extremely important one, because being able to do calculus is
>> critical to SAGE's mainstream acceptance. But I just don't have
>> enough familiarity with Mathematica/Maple. (Or calculus for that
>> matter. Crap I have to go and teach div/grad/curl in 60 minutes.)
>>
>> David
>
> I agree as well.
Regarding the type issue, I think you're wrong to be worried. If I
believed you,
I would have never been able to write the SAGE interfaces to
PARI/Mathemtica/etc.
that I already wrote. Also a single variable "x"
in Python can have hundreds of different types during the course
of a session (i.e., Python is not strongly typed).
And you should maybe think less about Maple/Mathematica than about Maxima,
which inspired both of those programs, and which is part of SAGE already.
> Any language issues aside, there's no reason at all
> to reinvent the wheel on this. However, there are some issues that we
> have do deal with that are no problem for maple or mathematica:
>> We have a serious design challenge which is
>> to make something that really does both calculus and serious math. I
>> say
>> we face that challenge head on and find a good solution, even if it
>> means
>> a lot of very hard thought. I like the challenge.
>
> I think a smooth transition between calculus and 'serious math' is
> key, or at the very least being able to naturally use both in the same
> session.
>
> While it will be nice for SAGE's calculus interface to be immediately
> available to Mathematica and Maple users with no learning curve, it is
> just as important that we minimize the learning curve for someone who
> knows calculus, but may not know any computer algebra language.
>
> It's been a while since I've used Mathematica myself. From what I
> recall, Mathematica handles basic calculus pretty well. I'm going to
> go refamiliarize myself with it a bit today...
Very good. Do the same with Maple *and* Maxima.
William
Robert Bradshaw
illegal is bad, especially with regard to plotting, etc.. Also, I
understand (at least to some degree) your aversion to using the
preprocessor.
I think it is worth noting that there is a difference in both Maple
and Mathematica between "functions" and "expressions." Functions can
be evaluated at values, expressions are evaluated in a context. I
have been thinking about things in terms of functions, but I guess
everyone else has been thinking in terms of expressions. Here is what
I see of the difference:
|\^/| Maple 10 (IBM INTEL LINUX)
._|\| |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple
Inc. 2005
\ MAPLE / All rights reserved. Maple is a trademark of
<____ ____> Waterloo Maple Inc.
| Type ? for help.
> f := sin(x)+y: # as an
expression
> f(3,4);
sin(x)(3, 4) + y(3, 4) #
this seems so counter-intuitive
> x:=3:
> f;
sin(3) + y #
now has 3 plugged in
> f := (x,y) -> sin(x)+y: # as a function, I
think the syntax isn't the easiest to learn/guess but makes sense.
Can even be used as an argument to plot.
> f(3,4);
sin(3) + 4
> x := 3: #
f is not changed here
> f(1,2);
sin(1) + 2
The same thing happens in Mathematica
Mathematica 5.2 for Linux x86 (64 bit)
Copyright 1988-2005 Wolfram Research, Inc.
-- Motif graphics initialized --
In[1]:= f := Sin[x] + y; # this is an
expression
In[2]:= f[3,4]
Out[2]= (y + Sin[x])[3, 4] # what does this mean?
In[3]:= x := 1
In[4]:= f
Out[4]= y + Sin[1] # 1 is now plugged
in for x
In[5]:= f[x_, y_] := Sin[x] + y;
SetDelayed::write: Tag Plus in (y + Sin[1])[x_, y_] is
Protected. # clearly, I'm not just re_assigning f
In[6]:= g[x_,y_] := Sin[x] + y # this is essentially the
same as my original proposal, except for the _'s
In[7]:= g[3,4]
Out[7]= 4 + Sin[3]
I guess I'm fine with the expression paradigm (where would they live/
what would their parent be?), but I think it would be very nice to
make them callable (which I guess would be abuse of notation).
Argument naming/order (and, in some cases perhaps number) is the big
difficulty here (and I think just forcing alphabetical is not a good
solution (with polynomials the order is defined at ring creation
time)). Either that or make substations very easy and natural.
I also have to say that defining all 52 1-letter variables on startup
seems less than ideal (they can get easily overwritten, use variables
like "theta" too, and it just seems like a hack to say "we'll define
all of them in case any get used") but it seems it's better than
requiring the preparser.
- Robert
Joel B. Mohler
> Substitutions would have to work differently in SAGE though, e.g., as
> in the following *fantasy* session:
>
> sage: f = sin(x) + cos(x*y) + exp(2*x*y); f
> cos(x*y) + exp(2*x*y) + sin(x)
> sage: g = f.subs( (z,sqrt(2)), (y,2/3)); g # substitutions
> sin(x) + cos(2*x/3) + e^(4*x/3)
> sage: h = g.integrate(x); h
> -cos(x) + 3*sin(2*x/3)/2 + 3*exp(4*x/3)/4
> sage: k = h.diff(x); k
> sin(x) + cos(2*x/3) + exp(4*x/3)
Excellent to see some fantasy code! This e-mail echos Robert's e-mail of 4
hours ago. I too have been having this discussion with the assumption that
our goal was for (as Robert says) support of "functions", not support
of "expressions". Indeed, I entirely forgot about mathematica's substitute
syntax because I always found it very hard to remember -- especially after I
realized I could make the real McCoy callable function --
In[1]:= f[x_]:=x
In[2]:= f[12]
Out[2]= 12
(I've long since abandoned mathematica because licensing servers and other
annoyances of proprietary software is a pain I could live without!)
From my study of functions.py, I believe that it needs a relatively thorough
overhaul to get all the dummy variable concepts integrated. Looking at
William's fantasy, I now understand why my questions of the form "How many
variables does that function have ....?" were unanswered. It simply doesn't
matter if you don't care about positional parameters.
Here's my fantasy:
** which doesn't need the pre-parser
** which is (I believe) realistically doable with careful design
sage: x,y=vars('x,y')
sage: f=Function( (x,y), sin(x) ); f
(x,y) -> sin(x)
sage: f(0,12)
sin(0) # whether this is 0 or sin(0) is not important to my fantasy
Some comments:
** this almost works in the one variable case already, but I believe that
multiple variables is unattainable with-out some more aggressive work similar
to what I'm suggesting
** whether x,y are generic variables or polynomial ring generators is not a
big deal to me (although it seems to me they have nothing to do with
polynomials)
** I believe that x,y should be identity functions so that "sin(x)" is
viewed as a composition of the identity function and the sin function.
** Functions will need to have a tuple of parameters, so that the __call__
method can know how to replace things as it goes down the parse tree of
Function_arith objects, etc. (Or, the variables could be replaced on
creation with a Function_dummy_positional identity function).
** I'm not clear from the maxima.py source code whether the result of
integration/differentiation is an opaque string from maxima or if we re-parse
it (I doubt we re-parse because that seems unnecessarily difficult). If we
don't reparse, I think that the maxima interface might need to know about
dummy variables to some minor extent.
--
Joel
William Stein
<jo...@kiwistrawberry.us> wrote:
> Here's my fantasy:
> ** which doesn't need the pre-parser
> ** which is (I believe) realistically doable with careful design
> sage: x,y=vars('x,y')
> sage: f=Function( (x,y), sin(x) ); f
> (x,y) -> sin(x)
> sage: f(0,12)
> sin(0) # whether this is 0 or sin(0) is not important to my fantasy
It's unclear to me why we need callable functions as a separate new
construction, when Python already has a notion of callable functions.
I.e., why is this not enough for you already?
def f(x,y):
return sin(x)
or even
f= lambda x,y: sin(x)
What's the advantage of what you're proposing over what's already there?
William
William Stein
<jo...@kiwistrawberry.us> wrote:
> ** I'm not clear from the maxima.py source code whether the result of
> integration/differentiation is an opaque string from maxima or if we
> re-parse
> it (I doubt we re-parse because that seems unnecessarily difficult). If
> we
> don't reparse, I think that the maxima interface might need to know about
> dummy variables to some minor extent.
Currently the if f is a maxima object the f.integrate('x'), says, gives
another maxima object. You can get the string rep of that object, or
call functions with it as input.
If we are going to reparse maxima results back to SAGE (and it's not 100%
clear to me yet if we will, but it's likely), we'll "just" have to define
all the objects that can appear in a maxima expression, do a little
preparsing
(e.g., replace %pi by pi), then call sage_eval on the string.
William
alex clemesha
functions with either 'def' or 'lambda',
personally I think that feels *by far* the most natural.
-Alex
Robert Bradshaw
The main difficulty with def/lamdba is how would one do calculus with
one of these functions?
David Harvey
On Dec 6, 2006, at 12:39 PM, Robert Bradshaw wrote:
> The main difficulty with def/lamdba is how would one do calculus with
> one of these functions?
Yeah, like if def f(x): ... and def g(x): ... then how do I write f + g?
David
Robert Bradshaw
> I guess I'm fine with the expression paradigm (where would they live/
> what would their parent be?), but I think it would be very nice to
> make them callable (which I guess would be abuse of notation).
> Argument naming/order (and, in some cases perhaps number) is the big
> difficulty here (and I think just forcing alphabetical is not a good
> solution (with polynomials the order is defined at ring creation
> time)). Either that or make substations very easy and natural.
I don't know why I didn't see the obvious use of unspecified keywords
in python functions sooner. So, here's another fantasy session for
maximum flexibility:
sage: f = sin(x) + y
sage: f(x=1, y=4)
sin(1) + 4
sage: f({x: 1, y: 4})
sin(1)+4
sage: f.integrate(x)
-cos(x) + xy
sage: x = 99
sage: f.integrate(x)
Traceback ...
sage: f.integrate('x') # here x (the indetermanent) is over-ridden,
but we can still refer to it by its (immutable) name
-cos(x) + xy
sage: f({'x': 1, 'y': 4})
sin(1)+4
sage: g = f(y=2); g
sin(x) + 2
sage: g(7): # ONE free variable, can use that by default
sin(7) + 2
sage: g.derivative() # again, ONE free variable
cos(x)
sage: g.derivative(y)
0
sage: f(2,1)
?? error/alphabetical ordering
sage: f(2, x=5, u=9)
?? should it be smart enough to figure this out? Order the unnamed
ones as above?
- Robert
alex clemesha
so one can define "functions" transparently with 'def' and 'lambda' that a user
can do calculus with.
-Alex
boo...@u.washington.edu
Example:
sage: F.<x> = FunctionSpace(domain = RR, range = RR)
sage: f = sin(x)
sage: g = cos(x)
sage: f+g
sin(x) + cos(x)
sage: f(g)
sin(cos(x))
sage: (f+g)(0)
1
sage: (f(g)).diff(x)
cos(cos(x))*(-sin(x))
--tom
William Stein
ANSWER 1:
def h(x):
return f(x) + g(x)
ANSWER 2: You don't. And there is no compelling reason that you should.
My impression is that even in Mathematica/Maple if you define an
evaluatable
function (a "substitution rule), then you can't really do arithmetic and
calculus with it either:
In[13]:= f[x_] := x^2 + 3;
In[14]:= f[2]
Out[14]= 7
In[15]:= (f+f)[2]
Out[15]= (2 f)[2]
If you want to do arithmetic and calculus with functions, you define them
as formal symbolic objects, and you're good to go. If you need to evaluate
them you use "subs" in maple (for subtitution), "ev" in Maxima (for
basically
the same thing), "subst" in pari (for the same thing), and I *still* don't
know what in Mathematica, but I'm sure there's some standard funny syntax.
It is very clarifying to distinguish between functions that one calls(in
the
sense of computer programs) and symbolic functions that are elements of
some
formal algebra. This is what is done in Maple/Mathematica/Maxima and
PARI,
and I don't see why SAGE should do things differently, given that this
approach
has been very successful. Average beginning students can
quickly do problems in calculus books using Maple/Mathematica... so their
approach is very likely practicle. Also, my impression is that among
us Alex C. is one of the only people who has actual signficant experience
with
this sort of computer algebra/calculus, and he is all for just using
Python's
def and lambda for defining functions.
-- William
William Stein
>
> Yeah, that was my thought, too. If we make an object, similar to a
> ring, representative of a function space, then if you call a function on
> an indeterminant member of this space, you get back a function; a member
> of the space.
>
> Example:
>
> sage: F.<x> = FunctionSpace(domain = RR, range = RR)
> sage: f = sin(x)
> sage: g = cos(x)
> sage: f+g
> sin(x) + cos(x)
> sage: f(g)
> sin(cos(x))
> sage: (f+g)(0)
> 1
> sage: (f(g)).diff(x)
> cos(cos(x))*(-sin(x))
Again, at this point I just don't see a compelling reason to so
dramatically depart from what Maple/Mathematica/Maxima, etc. do.
They all have a notion of substition of a variable for evaluating
symbolic functions, and separately a notion like "def" or "lambda".
Mixing these up seems to me to be ignoring the lessons learned
by decades of research and testing of actual users of this sort
of software.
-- William
Robert Bradshaw
I have to agree that although I like the concreteness of the
FunctionSpace construction, this would go way over the heads of most
of my calculus students. I am willing to assume that the way
Mathematica/Maple does things is the result of a lot of thought and
research. I would still advocate using the __call__ method for
substitution (not necessarily to the exclusion of an explicit "subs"
function) and, at least for single-variable expressions, letting the
(single) indeterminate be implicit.
- Robert
Joel B. Mohler
> It is very clarifying to distinguish between functions that one calls(in
> the
> sense of computer programs) and symbolic functions that are elements of
> some
> formal algebra. This is what is done in Maple/Mathematica/Maxima and
> PARI,
> and I don't see why SAGE should do things differently, given that this
> approach
> has been very successful.
But the point is that you CAN do calculus with the functions defined in
mathematica. Obviously, you can write functions in the mathematica language for
which calculus makes no sense (a loop perhaps), but as long as you define
something entirely in terms of analytic functions you can do calculus with it.
What I'm suggesting with defining these functions does not need to supplant the
idea of expressions. I think they can work very nicely together (using my
previous syntax):
sage: f=Function((x,y),x^n) # an expression involving another constant n
sage: f(2,3)
2^n
sage: f.subst((n,3)) # n is not in the official argument list
(x,y) -> x^3
You can do (and I've done many times) something entirely analogous to this in
mathematica.
> Average beginning students can
> quickly do problems in calculus books using Maple/Mathematica... so their
> approach is very likely practicle. Also, my impression is that among
> us Alex C. is one of the only people who has actual signficant experience
> with
> this sort of computer algebra/calculus, and he is all for just using
> Python's
> def and lambda for defining functions.
I, for one, and I've been asking around with some of my colleagues, know and
dislike the substitution method in mathematica. We find it very awkward to use.
To be sure, it's somewhat the choice of syntax (involving / and . and -> in a
strange juxtaposition), but I think it's only natural to want to use functional
notation when doing calculus.
Again, I don't think these have to be competing notions. In mathematica you
really can work entirely in either paradigm or mix and match.
--
Joel
alex clemesha
Again, I don't think these have to be competing notions. In mathematica you
really can work entirely in either paradigm or mix and match.
I totally agree with this.
Here are a couple of different ways in Mathematica
a user can evaluate the derivative of Sin at Pi:
In[5]:=f=Function[{x},Sin[x]]
Out[5]=Function[{x},Sin[x]]
(* Use shorthand ' notation *)
In[7]:=f'[Pi]
Out[7]=-1
(* Using the "Apply" shorthand notation *)
In[9]:=f'@Pi
Out[9]=-1
(* Using built in Sin directly *)
In[26]:=Sin'@Pi
Out[26]=-1
(* Notice Delayed Evaluation is not set *)
In[10]:=g[x_]=D[Sin[x],x]
Out[10]=Cos[x]
In[11]:=g[Pi]
Out[11]=-1
(* Notice here the ":=" delayed evaluation cause this to FAIL *)
In[12]:= h[x_]:=D[Sin[x],x]
In[12]:= h[Pi]
General::ivar: Pi is not a valid variable.
Out[12]= D[0, Pi]
-Alex
Joel B. Mohler
> I guess what I'm suggesting is completely implement "
> sage.functions.functions.* "
> so one can define "functions" transparently with 'def' and 'lambda' that a
> user
> can do calculus with.
If we can actually achieve a lambda function that you can do calculus with, that
would be idea. I have no idea how you would go about doing that though. Did
you have implementation details in mind?
--
Joel
William Stein
wrote:
>> Again, I don't think these have to be competing notions. In mathematica
>> you
>> really can work entirely in either paradigm or mix and match.
>
I was confused, since there are (at least) three separate notions
of something like functions Mathematica:
1. A formal expression, e.g., y + Sin[Pi*x].
This can't be evaluated at a number, but one can use substitution,
and calculus, etc., with such functions.
In[32]:= f = Sin[x+y]
Out[32]= Sin[x + y]
In[33]:= f
Out[33]= Sin[x + y]
In[34]:= f /. {x -> 2, y -> 3}
Out[34]= Sin[5]
2. A Function of one more variables, e.g.,
f=Function[{x, y},Sin[x + y]]
These can be evaluated, and in many cases one can also do
calculus with them. It is explicit in defining the function
what the input variables are, and in what order.
In[29]:= f=Function[{x, y},Sin[x + y]]
Out[29]= Function[{x, y}, Sin[x + y]]
In[30]:= f
Out[30]= Function[{x, y}, Sin[x + y]]
In[31]:= f[2,3]
Out[31]= Sin[5]
3. A substitution rule (?), which I guess doesn't have
any analogue in Python. I was confused before and didn't know
about 2 (above) and thought 3 was the only way to define a function.
Calculus rules don't make sense for these, but they can be evaluated.
In[36]:= z[x_, y_] := Sin[x+y]
In[37]:= z[2,3]
Out[37]= Sin[5]
----
My impression is that we should implement analogues of (1) and (2)
for SAGE. I'm not sure if (3) has any place. I think the proposal
of Robert and Joel is compatible with (2), but I think (1) is
also very important (and one needs (2) in order to implement (1)
anyways).
----
> If we can actually achieve a lambda function that you can do calculus
> with, thatwould be idea. I have no idea how you would go about doing
> that though. Didyou have implementation details in mind?
There way to define
William Stein
>> you
>> really can work entirely in either paradigm or mix and match.
>
I was confused, since there are (at least) three separate notions
In[33]:= f
In[30]:= f
----
----
I think there is no clean way to define arithmetic, etc., with Python
functions,
i.e., objects of type <type 'function'>. So it's technically not possible.
Thus I was wrong to suggest we can do everything we want that Mathematica
does just using "def" and "lambda", plus formal symbolic expressions.
alex clemesha
If we can actually achieve a lambda function that you can do calculus with, that
would be idea. I have no idea how you would go about doing that though. Did
you have implementation details in mind?
and with those beginners, non-programmers, etc can define functions
that are "pythonic", i.e. how you would define a function in *normal* python
from a *novices* point of view. Behind the scenes would be the well thought
through "sage.functions.functions.*", which advanced user can use to make
very specific "Functions fields". I too am unsure of the details of this, that why
more discussion is good :)
-Alex
Joel B. Mohler
> 3. A substitution rule (?), which I guess doesn't have
> any analogue in Python. I was confused before and didn't know
> about 2 (above) and thought 3 was the only way to define a function.
> Calculus rules don't make sense for these, but they can be
> evaluated.
>
> In[36]:= z[x_, y_] := Sin[x+y]
>
> In[37]:= z[2,3]
>
> Out[37]= Sin[5]
Actually, you can do calculus with these too.
In[12]:= f[x_]:=Sin[x]
In[13]:= f'[x]
Out[13]= Cos[x]
In[14]:= f'[y]
Out[14]= Cos[y]
Of course, I don't believe the prime notation is an option for our python
(with-out *very* ugly preparsing).
--
Joel
David Joyner
but one other subject should be addressed: easy to understand error
messages. A long traceback is fine but at the end, something to
help explain to the user what they probably did wrong is also
important.
The comments what Maple/Mma are doing things right and we should
emulate them reminds me of the following story: years ago
an Ivy league school had everyone use one of these in calculus.
It got so frustrating that some enterprising students made some money
selling "F*** M." t-shirts (where I think you can fill in the blanks).
This was years ago, and I'm not trying to put anyone or product down,
just an amusing illustration of the frustrations we want to try to avoid.
I really believe that because of the talented and inventive
programmers working on SAGE, we can actually do better than both.
+++++++++++++++++++++++++++++++++++
William Stein
------- Forwarded message -------
From: "Jaap Spies" <j.s...@hccnet.nl>
To: "David Joyner" <wdjo...@gmail.com>, "William Stein" <wst...@gmail.com>
Cc:
Subject: Re: [sage-devel] Re: Sage (fwd)
Date: Wed, 06 Dec 2006 15:39:24 -0800
David Joyner wrote:
> just an amusing illustration of the frustrations we want to try to avoid.
> I really believe that because of the talented and inventive
> programmers working on SAGE, we can actually do better than both.
>
I really hope so! I prefer Maple above Mathematica, but they are both
a pain ...
Bobby Moretti
When I was messing around with Mathematica (couldn't get my hands on
Maple, but I probably would have had a similar experience) back in
high school, I found it *very* counterintuitive to do basic calculus.
I essentially gave up trying. And given the amount of confusion about
how Mathematica works displayed so far on this thread, my guess is
that I am not alone.
Part of the problem is the difference between mathematical functions
and computer language functions. The idea of substituting parameters
is present in mathematics... if I define f(x) = x sin (x^2)
mathematically, and I want to evaluate it at some point in the domain,
I just *do* the substitution. I don't typically write something
separately.
I'm afraid that this subtlety will likely be lost on most SAGE users.
Extensive knowledge of computer programming is not required in order
to use SAGE. I hope we can come up with a solution that is acceptable
in both paradigms. Perhaps the solution that Math/Maple/etc. use is
the best, but I hope we can find a more intuitive one.
--
Bobby Moretti
mor...@u.washington.edu