Why Sage needs var(...) commands unlike Mathematica?
sebe...@spawar.navy.mil
Mathematica doesn't need var commands so people coming from
Mathematica may get confused when they issue their first plot command
in Sage.
Chris
Justin C. Walker
The tutorial and reference manual are available for anyone to read.
If you leap into a new language without doing a little reading, you
can always run into trouble. Sage is not precisely Python, although
it is built on Python as a base. You should not infer from that that
the two are identical.
People coming from a Mathematica background should not assume that
they know all there is to know about how to use a Computer Algebra
System, and instead, read the documentation.
Remember, Sage is short for "Sage is not Mathematica" :-}
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Director
Institute for the Enhancement of the Director's Income
--------
"Weaseling out of things is what separates us from the animals.
Well, except the weasel."
- Homer J Simpson
--------
Simon King
On Nov 2, 2:01 am, "seber...@spawar.navy.mil"
to use something, you need to define it first! Hence I find it
confusing that the variable 'x' does *not* need to be declared with a
var command, since it is pre-defined. But William made it crystal
clear that this won't change, eventually I got used to it, and de
gustibus non est disputandum... :-)
My first experience with a CAS was Maple - but actually I even don't
remember how variables are treated in Maple. This shows how easily the
conventions that Maple (or Mathematica) implant into our minds can be
overwritten.
However: Recently there had been many questions about the plot
commands, e.g. regarding the fact that some plot-commands do not start
with the letters p l o t (parametric_plot etc). I don't use plotting
often, but this gives me the impression that plotting in Sage (and
perhaps the error messages if something goes wrong?) ought to be more
intuitive.
Cheers
Simon
Harald Schilly
> People coming from a Mathematica background should not assume that
> they know all there is to know about how to use a Computer Algebra
no, better not, but sage isn't the answer to the question of all
questions either. I think, the point is to improve the error messages.
A while ago this was also in the survey and therefore it would be nice
to include a sentence like: "seems you have not defined the
variable(s), please read the tutorial" in such error messages. (if it
is possible to catch those errors at all)
harald
Robert Dodier
> On Nov 2, 2008, at 00:01 , sebe...@spawar.navy.mil wrote:
> > Is it possible to avoid need to declare variables with var commands?
error to evaluate an undefined variable. Mathematica adopted
Macsyma's policy, in which it is not an error; an unbound symbol
evaluates to itself. I don't know where Macsyma got that;
in Lisp, at present, it's an error to evaluate an unbound variable,
but maybe it was different in ancient times (1970's).
Python is an interesting and useful language, but in some ways it
isn't well-suited to symbolic processing. Too bad about that.
> People coming from a Mathematica background should not assume that
> they know all there is to know about how to use a Computer Algebra
> System, and instead, read the documentation.
(0) O.p. didn't give any indication of sweeping assumptions.
(1) Few people read the documentation before using a program for
the first time. It's not a problem, & developers ought to plan for it.
(2) If you want people to use Sage, you might attempt to accomodate
them, rather than immediately switching into the you're-a-moron mode.
(3) The answer to the o.p.'s question isn't in the tutorial or
reference
manual. Yes, I looked. Did you? I didn't think so.
FWIW
Robert Dodier
William Stein
>
> Justin C. Walker wrote:
>
>> On Nov 2, 2008, at 00:01 , sebe...@spawar.navy.mil wrote:
>
>> > Is it possible to avoid need to declare variables with var commands?
>
> Sage has adopted Python's evaluation policy, in which it is an
> error to evaluate an undefined variable. Mathematica adopted
> Macsyma's policy, in which it is not an error; an unbound symbol
> evaluates to itself. I don't know where Macsyma got that;
> in Lisp, at present, it's an error to evaluate an unbound variable,
> but maybe it was different in ancient times (1970's).
>
> Python is an interesting and useful language, but in some ways it
> isn't well-suited to symbolic processing. Too bad about that.
I personally Python well suited to mathematical computation,
and at least the approach in Python regarding undefined variables
is consistent with every other general purpose programming
language I've ever used. But it is definitely different than Mathematica.
>> People coming from a Mathematica background should not assume that
>> they know all there is to know about how to use a Computer Algebra
>> System, and instead, read the documentation.
>
> This is so obnoxiously wrong, I just don't know where to start.
What is wrong? That statement Justin made or that he made it at all?
To say Justin's response as written above is wrong, is
to say the following is true (I just negated what he wrote):
"People coming from a Mathematica
background should assume that they know all there is to know
about how to use a Computer Algebra System, and should
not read the documentation".
The first line of section 2 of the tutorial (about calculus) is
"The solve function solves equations. To use it, first specify some variables;
..." and gives an example of using var.
I guess this suggests that one needs to use var. This would
be a good place in the tutorial to insert a sentence that if you
don't use var then you will get a NameError, and that this
behavior is different than in Mathematica, and there is no
mode to change this, since it's a basic feature of how the Python
language works.
William
Simon King
On Nov 2, 6:18 pm, "William Stein" <wst...@gmail.com> wrote:
> >> People coming from a Mathematica background should not assume that
> >> they know all there is to know about how to use a Computer Algebra
> >> System, and instead, read the documentation.
>
> > This is so obnoxiously wrong, I just don't know where to start.
>
> What is wrong? That statement Justin made or that he made it at all?
Mathematica, Maple, Magma or Sage background should not believe that
the respective system is the philosopher's stone. It should be self-
evident that changing from one system to another sometimes involves to
look into a manual.
On the other hand, the statement is partially wrong in the following
sense: We should not *suppose* that a person changing from Mathematica
to Sage will first thoroughly read the manual. I agree with Robert,
who wrote that one should try to accomodate the people.
I think Harald is right that a descriptive error message can be very
helpful to a novice. The problem is that a very descriptive message
would depend on the context, and making it context-sensitive would
involve work. But it is (to some extent) doable!
Example:
-------------
1.
sage: y
...
NameError: name 'y' is not defined
That's clear enough.
2.
sage: sin(y)
...
NameError: name 'y' is not defined
That's the same message - but the context (calculus-function) makes it
clear that the user wanted to make y a variable. Suggestion:
3.
Context sensitivity could be obtained by catching and re-raising
errors.
Would it be possible that the calculus-functions catch any NameError
and re-raise it with an extended error message? The following error
message may be a better help to the people:
sage: sin(y)
...
NameError: name 'y' is not defined. If 'y' is intended to be a
variable, please use var('y'). Type var? for help
Cheers
Simon
Robert Dodier
> I personally Python well suited to mathematical computation,
It's the symbolic stuff that's lacking.
> and at least the approach in Python regarding undefined variables
> is consistent with every other general purpose programming
> language I've ever used.
different, then.
> But it is definitely different than Mathematica.
(to judge by their quick start guide). Neither does Maxima/Macsyma
nor MuPAD nor PARI/GP ftr.
> What is wrong? That statement Justin made or that he made it at all?
original message that the o.p. (Seberino) has assumed that he knows
"all there is to know about how to use a Computer Algebra System".
> The first line of section 2 of the tutorial (about calculus) is
> "The solve function solves equations. To use it, first specify some variables;
> ..." and gives an example of using var.
>
> I guess this suggests that one needs to use var. This would
> be a good place in the tutorial to insert a sentence that if you
> don't use var then you will get a NameError, and that this
> behavior is different than in Mathematica, and there is no
> mode to change this, since it's a basic feature of how the Python
> language works.
is different from various other packages, not just Mathematica. Some
explanation should go in the documentation for var itself as well.
FWIW
Robert Dodier
Tim Lahey
>>
> Apparently Maple also does not require variables to be declared
> (to judge by their quick start guide). Neither does Maxima/Macsyma
> nor MuPAD nor PARI/GP ftr.
>
For most work, Maple doesn't require you to define symbolic variables.
One does need to define local variables for a procedure, though. But
that isn't the same thing.
The having to define variables kind of put me off using Sage to start.
It wasn't particularly clear in the documentation.
My main problems now stem from missing symbolic manipulation commands
some of which are being addressed by pynac. So, I'm kind of holding
off until Sage 3.2 before really diving back in.
>>
> Well, that would be an improvement. The need to declare variables
> is different from various other packages, not just Mathematica. Some
> explanation should go in the documentation for var itself as well.
>
Something should be stated in the NameError message as well.
Tim.
---
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo
William Stein
The NameError is raised before the code is ever evaluated
by the sin function. It is a raised when the code is being
parsed by Python in the first place. So I don't know how
it would be possible to do what you suggest above.
William
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Martin Albrecht
I'm not quite sure this is easily doable. Does iPython support some sort of
exception catching/processing?
Cheers,
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
William Stein
> William Stein wrote:
>
>> I personally Python well suited to mathematical computation,
Wow, I omitted a lot of words from that sentence.
> No problem with any computation involving literal objects.
> It's the symbolic stuff that's lacking.
>
>> and at least the approach in Python regarding undefined variables
>> is consistent with every other general purpose programming
>> language I've ever used.
>
> Well, this is an opportunity for Sage to do something usefully
> different, then.
Sage has done something different, which is to be consistent
with many mainstream general purpose programming language
(by which I mean languages such as Java, Python, C#, etc.)
>
>> But it is definitely different than Mathematica.
>
> Apparently Maple also does not require variables to be declared
> (to judge by their quick start guide). Neither does Maxima/Macsyma
> nor MuPAD nor PARI/GP ftr.
That's right -- many of the special purposes math languages don't
require variables to be defined. A notable exception is the Magma
which requires variables to be define before using them.
>> What is wrong? That statement Justin made or that he made it at all?
>
> It's a classic strawman. There's no evidence whatsoever in the
> original message that the o.p. (Seberino) has assumed that he knows
> "all there is to know about how to use a Computer Algebra System".
Well just for the record I know the o.p. personally, I he is an
extremely well intentioned and considerate person, and
I hope he doesn't take any offense to Justin's
also (I hope) well meaning remarks.
>> The first line of section 2 of the tutorial (about calculus) is
>> "The solve function solves equations. To use it, first specify some variables;
>> ..." and gives an example of using var.
>>
>> I guess this suggests that one needs to use var. This would
>> be a good place in the tutorial to insert a sentence that if you
>> don't use var then you will get a NameError, and that this
>> behavior is different than in Mathematica, and there is no
>> mode to change this, since it's a basic feature of how the Python
>> language works.
>
> Well, that would be an improvement. The need to declare variables
> is different from various other packages, not just Mathematica. Some
> explanation should go in the documentation for var itself as well.
>
> FWIW
OK, let's do that.
William
John Cremona
How much of the problem would go away if the standard startup file had
var('a b c d e f g h i j k l m n o p q r s t u v w x y z')
in it? So that var() only had to be used explicitly for longer variable names?
John
> William
>
> >
>
mabshoff
On Nov 2, 12:22 pm, "John Cremona" <john.crem...@gmail.com> wrote:
> 2008/11/2 William Stein <wst...@gmail.com>:
<SNIP>
> > OK, let's do that.
>
> How much of the problem would go away if the standard startup file had
> var('a b c d e f g h i j k l m n o p q r s t u v w x y z')
> in it? So that var() only had to be used explicitly for longer variable names?
symbolic is bad since it is inconsistent, but I guess it is a
compromise. Any "decent" language should require that one has to
declare variables. I remember a bunch of bugs in MMA where local
functions assume certain variables and things go wrong when the user
does something unexpected on the "outside". This obviously has also to
do with namespaces and so on, but we are using a modern programming
language and the decision to require symbolic variables to be declared
is the right one from my point of view. The documentation is probably
not as outspoken about this as it should be.
Obviously there are people who disagree and prefer the more lispy
model of Maxima/MMA, but Sage is not a clone of either one of those
systems. Beauty is always in the eye of the beholder :)
> John
>
Cheers,
Michael
> > William
John Cremona
>
>
>
> On Nov 2, 12:22 pm, "John Cremona" <john.crem...@gmail.com> wrote:
>> 2008/11/2 William Stein <wst...@gmail.com>:
>
> <SNIP>
>
>> > OK, let's do that.
>>
>> How much of the problem would go away if the standard startup file had
>> var('a b c d e f g h i j k l m n o p q r s t u v w x y z')
>> in it? So that var() only had to be used explicitly for longer variable names?
>
> That would not solve the problem. IMHO even pre-declaring x to be
> symbolic is bad since it is inconsistent, but I guess it is a
> compromise. Any "decent" language should require that one has to
> declare variables. I remember a bunch of bugs in MMA where local
> functions assume certain variables and things go wrong when the user
> does something unexpected on the "outside". This obviously has also to
> do with namespaces and so on, but we are using a modern programming
> language and the decision to require symbolic variables to be declared
> is the right one from my point of view. The documentation is probably
> not as outspoken about this as it should be.
I agree, and I did not really mean my alphabetti suggestion to be
taken too seriously.
I cannot remember why we uniquely define 'x', since as everyone agrees
that is an anomaly, but I certainly use it all the time (probably half
my Sage sessions start with K.<a>=NumberField(polnomial_in_x), after
all). My Magma startup file starts
Z:=Integers();
Q:=Rationals();
Qx<x>:=PolynomialRing(Q);
EC:=EllipticCurve;
but I only need the last one in Sage...
John
William Stein
> How much of the problem would go away if the standard startup file had
> var('a b c d e f g h i j k l m n o p q r s t u v w x y z')
> in it? So that var() only had to be used explicitly for longer variable names?
>
> John
Anyway, in Sage, it seems reasonable to do this, right?
sage: f = x^2 + 1
sage: f
x^2 + 1
sage: f(3)
10
We actually used to do just what you suggest above (also with upper
case lttters).
It was amazing the amount of confusion and pain it caused, mainly
because one can call symbolic expressions. So people would do
this sort of thing
sage: f(10)
10
and be like WTF?! Because they thought they defined f somewhere
else to be some function, but that definition was in a previous session.
Incidentally, if we did allow automatic creation of symbolic
variables, and default
calling of symbolic expressions, then doing something like this would happen
all the time and confuse the crap out of people:
sage: function_name_with_slight_typo(10)
10
Obviously we would have to change Sage so that:
sage: f = x^2 + 1
sage: f(3)
boom -- big error
and require
sage: f(x=3)
10
I'm just pointing out one subtlety... which could be resolved.
I think it would be interesting to have at least the capability
of a mode where variable names are made symbolic if
not previously used, at least if the calling behavior were redefined
as above. This would have be done by somehow parsing the
input, finding all undefined variables, defining them, etc....
It's techincaly possible. Maybe Fernando Perez and I can
try to make a demo of something like this at Sage Days 11.
William
Ronan Paixão
> I personally Python well suited to mathematical computation,
> and at least the approach in Python regarding undefined variables
> is consistent with every other general purpose programming
> language I've ever used. But it is definitely different than Mathematica.
The problem lies in the fact that not everyone using a CAS is a
programmer (though obviously that would help a lot). In the same manner,
some people using other systems eventually learn how to handle it
(MATLAB's symbolic package requires declaring variables).
A compromise solution would be the already proposed use of an init file
which includes a declaration of all single-letter variables (that would
help a lot, but also would create havoc for users who don't read the
manual and try to use multi-letter variables due to consistency, in the
same way it would avoid problems with function names typos). That's a
hard design decision in itself.
Another solution would be to have an init file with that line commented
out, and a remark in the tutorial and the manual explaining its usage. I
believe that would be a good workaround, because whoever enables it
should know what he's doing and that would not create a consistency
dilemma (with the added effect of making the novice user know the great
help an init file can provide).
Ronan Paixão
Timothy Clemans
variables are allowed? A user could easily change the mode to standard
using say set_mode_standard() or something similar. Maybe have Sage
state the mode both on the command line and in the notebook. The only
problem would be that some people might share code that has undefined
variables with people that are using the standard mode.
William Stein
>
>
>> I personally Python well suited to mathematical computation,
>> and at least the approach in Python regarding undefined variables
>> is consistent with every other general purpose programming
>> language I've ever used. But it is definitely different than Mathematica.
>
> The problem lies in the fact that not everyone using a CAS is a
> programmer (though obviously that would help a lot).
is using a programming language though. People using
Sage's @interact or Mathematica's Manipulate are
people using Cas's that aren't using a programming languae.
> In the same manner,
> some people using other systems eventually learn how to handle it
> (MATLAB's symbolic package requires declaring variables).
one doesn't predefine variables. On the other hand, it is not at all a CAS.
It does have a CAS plugin, and I think one does not define variables
for that plugin since symbolic functions are if I remember right just
text strings.
> A compromise solution would be the already proposed use of an init file
> which includes a declaration of all single-letter variables (that would
> help a lot, but also would create havoc for users who don't read the
> manual and try to use multi-letter variables due to consistency, in the
> same way it would avoid problems with function names typos). That's a
> hard design decision in itself.
long as symbolic expressions are callable. If symbolic expressions were
not callable then this would be less of an issue, I guess. Even then,
having predefined a..z and A..Z was so so confusing for people.
E.g., somebody might do:
bar = 0
for m in [1..3]:
bar += n
and be very confused when they get that bar is 3*n. We used to get this sort
of problem a lot when the var's were predefined.
By the way, there is one thing the OP might want to do. If you define
a symbolic expression as follows, the vars *automatically* get defined:
sage: f(x,y,z,theta) = x+y-z/theta # I didn't ever do var('x,y,z,theta')
sage: f.integrate(theta)
(x, y, z, theta) |--> -log(theta)*z + theta*y + theta*x
> Another solution would be to have an init file with that line commented
> out, and a remark in the tutorial and the manual explaining its usage. I
> believe that would be a good workaround, because whoever enables it
> should know what he's doing and that would not create a consistency
> dilemma (with the added effect of making the novice user know the great
> help an init file can provide).
>
> Ronan Paixão
>
>
> >
>
William Stein
<timothy...@gmail.com> wrote:
>
> Would it be possible to have a beginners mode where undefined
> variables are allowed?
so I don't know whether or not it is possible. I suspect it is, but would
have to try several ideas to see if any work well.
> A user could easily change the mode to standard
> using say set_mode_standard() or something similar. Maybe have Sage
> state the mode both on the command line and in the notebook. The only
> problem would be that some people might share code that has undefined
> variables with people that are using the standard mode.
sage: implicit_multiplication(True)
sage: var('x')
x
sage: 3x^3 + 5x - 2
3*x^3 + 5*x - 2
That sets things in a funny convenience mode, and it hasn't turned out to
cause trouble, as far as I know.
So if/when there is a technical way to have automatic variable
definition, maybe having
a mode that does it probably won't cause much trouble for users, in practice.
-- William
>
> On Sun, Nov 2, 2008 at 6:58 PM, Ronan Paixão <ronan...@yahoo.com.br> wrote:
>>
>>
>>> I personally Python well suited to mathematical computation,
>>> and at least the approach in Python regarding undefined variables
>>> is consistent with every other general purpose programming
>>> language I've ever used. But it is definitely different than Mathematica.
>>
>> The problem lies in the fact that not everyone using a CAS is a
>> programmer (though obviously that would help a lot). In the same manner,
>> some people using other systems eventually learn how to handle it
>> (MATLAB's symbolic package requires declaring variables).
>>
>> A compromise solution would be the already proposed use of an init file
>> which includes a declaration of all single-letter variables (that would
>> help a lot, but also would create havoc for users who don't read the
>> manual and try to use multi-letter variables due to consistency, in the
>> same way it would avoid problems with function names typos). That's a
>> hard design decision in itself.
>>
>> Another solution would be to have an init file with that line commented
>> out, and a remark in the tutorial and the manual explaining its usage. I
>> believe that would be a good workaround, because whoever enables it
>> should know what he's doing and that would not create a consistency
>> dilemma (with the added effect of making the novice user know the great
>> help an init file can provide).
>>
>> Ronan Paixão
>>
>>
>> >
>>
>
> >
>
sebe...@spawar.navy.mil
On Nov 2, 4:23 pm, "William Stein" <wst...@gmail.com> wrote:
> sage: f(x,y,z,theta) = x+y-z/theta # I didn't ever do var('x,y,z,theta')
> sage: f.integrate(theta)
> (x, y, z, theta) |--> -log(theta)*z + theta*y + theta*x
cs
Robert Dodier
> Incidentally, if we did allow automatic creation of symbolic
> variables, and default calling of symbolic expressions, then
> doing something like this would happen
> all the time and confuse the crap out of people:
>
> sage: function_name_with_slight_typo(10)
> 10
creating a variable for function_name_with_slight_typo.
Calling symbolic expressions -- that's weird.
> I think it would be interesting to have at least the capability
> of a mode where variable names are made symbolic if
> not previously used, at least if the calling behavior were redefined
> as above. This would have be done by somehow parsing the
> input, finding all undefined variables, defining them, etc....
> It's techincaly possible. Maybe Fernando Perez and I can
> try to make a demo of something like this at Sage Days 11.
which just catches NameError and instantiates suitable variables
and reevaluates the input when that happens. Is there a way to
get Python to parse the input without evaluating it? (Isn't there
an AST package or s.t.l.t. which could do that?) Then you could
(I guess) detect undefined variables without causing side-effects
from any part of the input. Just a guess -- I'm no expert on Python.
FWIW
Robert Dodier
William Stein
>
> William Stein wrote:
>
>> Incidentally, if we did allow automatic creation of symbolic
>> variables, and default calling of symbolic expressions, then
>> doing something like this would happen
>> all the time and confuse the crap out of people:
>>
>> sage: function_name_with_slight_typo(10)
>> 10
>
> Well, that's weird, but it's not weird because of automatically
> creating a variable for function_name_with_slight_typo.
> Calling symbolic expressions -- that's weird.
Would you consider this weird if you read it in a paper, or
would you know how to interpret it?
"Let $f = x^3 + x + 1$ and consider $f(10)$."
>> I think it would be interesting to have at least the capability
>> of a mode where variable names are made symbolic if
>> not previously used, at least if the calling behavior were redefined
>> as above. This would have be done by somehow parsing the
>> input, finding all undefined variables, defining them, etc....
>> It's techincaly possible. Maybe Fernando Perez and I can
>> try to make a demo of something like this at Sage Days 11.
>
> I would be inclined to plug in a custom top-level interpreter loop
> which just catches NameError and instantiates suitable variables
> and reevaluates the input when that happens. Is there a way to
> get Python to parse the input without evaluating it? (Isn't there
> an AST package or s.t.l.t. which could do that?) Then you could
> (I guess) detect undefined variables without causing side-effects
> from any part of the input. Just a guess -- I'm no expert on Python.
Those are two good ideas to try. Obviously, as you say, the parsing
one is better since it avoids nasty confusing side effects that catching
NameError's would result in.
-- William
David Kohel
To give a bit more weight to the counterargument against the
alphabetti
solution:
> I agree, and I did not really mean my alphabetti suggestion to be
> taken too seriously.
symbols
to be symbolic elements. This caused me all sorts of grief when I
forgot to
declare some variable, I would get an error message far down the line
at some
completely irrelevant place. I complained and this "feature" was
removed (so
blame me Chris). For the same reason I voted to leave QQ, RR, and CC,
and
remove predefinition of Q, R, and C (originally Q == QQ, etc.).
If I forget to declare a variable, I want to see it as soon as I try
to use it.
Since you declare x to be in Qx in your startup file, you don't see
the problem,
but symbolic variables are viral: if another generator interacts with
one it gets
the symbolic virus. The current symbolics package supports a lot of
features
(which wasn't always the case) so maybe the "typical" user won't
notice a
problem, however this is one instance where one can easily pass over
to the
symbolics world:
sage: P.<X> = PolynomialRing(QQ);
sage: X + x
X + x
sage: f = X^2 - x^2
sage: f.factor()
(X - x)*(X + x)
sage: f.parent()
Symbolic Ring
sage: X = f.parent()(X)
sage: type(X)
<class 'sage.calculus.calculus.SymbolicPolynomial'>
sage: type(f.factor())
<class 'sage.calculus.calculus.SymbolicArithmetic'>
sage: fac = (1/f).factor()
sage: fac == 1/f
1/((X - x)*(X + x)) == 1/(X^2 - x^2)
sage: f.is_unit()
...
Not implemented error
The sorts of questions and functionality one asks the symbolics
variables
are not the same questions one asks an element of a polynomial ring
or
of a function field element. Stumbling into this world by mistake
because
someone predefined a bunch of variables for me was a real headache.
SAGE is doing remarkably well at keeping a balance between ease-of-
use
for beginners and high-end users.
--David
Robert Dodier
> Would you consider this weird if you read it in a paper, or
> would you know how to interpret it?
>
> "Let $f = x^3 + x + 1$ and consider $f(10)$."
I'm pretty sure I want (x^3 + x + 1)(10) to be (x^3)(10) +
x(10) + 1(10). (If the last term were y instead of 1, I'd
probably want y(10).)
About x(10), I might want that to be x, 10, 10*x, or let
it remain x(10).
About (x^3)(10), I might want that to be x(x(x(10))) or (x(10))^3.
I might want 1(10) to be 1. I probably want x(10) to yield
the same as 1(10) if I substitute 1 for x.
These considerations lead to different interpretations, most of
which differ from the way Sage implements callable expressions,
if I'm not mistaken. I don't see a need for Sage to preempt
useful and interesting interpretations. Under the circumstances,
the right thing to do is to postpone function evaluation until
additional context is supplied.
FWIW
Robert Dodier
Nick Alexander
On 5-Nov-08, at 8:55 PM, Robert Dodier wrote:
>
> William Stein wrote:
>
>> Would you consider this weird if you read it in a paper, or
>> would you know how to interpret it?
>>
>> "Let $f = x^3 + x + 1$ and consider $f(10)$."
>
> I'm not so sure I know what to do with that.
I find this bizarre. I am absolutely certain that I want to view $f$
as a polynomial in one variable and evaluate it at 10.
I can think of lots of alternate ideas (evaluate everything to
bottom!) but I believe none of them are common. Can you cite a paper
that uses the notion of $x^3$ denoting the three-fold composition of a
function $x$ and considering $f = x^3$ and $f(10)$ intending the three-
fold composition of $x$?
Nick
John Cremona
how different people have different instincts. For me, f = x^3 + x +
1 defines a polynomial, and polynomials define functions in an
unambiguous way, and that is it. But if you think of f as a symbolic
expression (as a traditional CA system would) then other
interpretations are possible.
John
2008/11/6 Nick Alexander <ncale...@gmail.com>:
Simon King
On Nov 6, 6:10 am, Nick Alexander <ncalexan...@gmail.com> wrote:
> >> Would you consider this weird if you read it in a paper, or
> >> would you know how to interpret it?
>
> >> "Let $f = x^3 + x + 1$ and consider $f(10)$."
>
> > I'm not so sure I know what to do with that.
<pedantic>
If I read $f(x) = x^3 + x + 1$ in a paper then I would interpret f as
a polynomial function and hence expect $f(10)=10^3+10+1$.
But in the way William stated it, I would interpret f as a polynomial,
not a function. And then, being referee for Williams paper and being
in pedantic mode, I might complain that he should use $ev(f,10)$
(evaluation) or something like that, since polynomials aren't
functions.
From that point of view, I think that Sage should distinguish
polynomials and polynomial functions. Of course, there should be an
easy transition between the two things, say, if f is a polynomial in x
and y, then f.as_function() should be a function in two variables. And
there should be an evaluation function, say, f.eval(10,15), which does
the same as f.as_function()(10,15)
</pedantic>
However, as a nice person and reader of Williams paper, I would
probably correctly guess that $f = x^3 + x + 1$ denotes a polynomial
*and* a polynomial function.
Moreover, if we talk about *commutative* polynomials then the
interpretation x^3(10) = x(x(x(10))) suggested by Robert simply can't
be the one we want, since then x*y(10) = x(y(10)) \not= y(x(10)) =
y*x(10).
Hence, I think it is ok that multivariate commutative polynomials in
Sage are callable, by being considered as polynomial functions.
But for (freely) non-commutative polynomials I agree with Robert's
objection. If f is a non-commutative polynomial in two variables, then
I would want that f(a,b) is only defined for *callable* objects a and
b, and would return a callable object, by interpreting x*y(a,b) =
a(b(.)) and y*x(a,b) = b(a(.))
Cheers
Simon
Franco Saliola
What if I cite Sage instead? :-)
sage: x = SymmetricGroup(10).random_element(); x
(1,9,5,7,3,10,6,4,2)
sage: f = x^3; f
(1,7,6)(2,5,10)(3,4,9)
sage: f(10)
2
Franco
--
Nils Bruin
actually write down examples where Robert D's interpretation is not so
outlandish.
For instance:
sage: var("D, x");
sage: f=D^2+D+1;
sage: f(x^3)
x^6 + x^3 + 1
In an article about differential operators, one would probably mean
that D= d/dx or something like that and then one would expect
f(x^3)=6*x+3*x^2+x^3
admittedly, multiplication (composition) of differential operators is
not commutative, so the symbolic ring would get that wrong as well
(one has D*x=x+1)
Allowing for such exotic interpretations in the symbolic ring would
probably ruin many conveniences for calculus, which I guess is still
the main application, so I would think that properly documenting the
current behaviour is probably the better way to go forward.
I think it also provides an argument for the explicit "var"
declaration: If you declare "D" to be a variable, it's pretty clear
that you shouldn't expect operator semantics, whereas if you're
allowed to use "D" without declaring anything about it, you could make
an argument that Sage was a little bit presumptuous in assuming that
it's not an operator.
Ronan Paixão
comes from the fact that mathematical notation itself (in paper) may be
ambiguous. Imagine for example that you see in a paper $f(a+b)$. From
common notation one would guess that f is a function and that I'm
replacing it's variable with (a+b). However, if one sees $x(a+b)$ the
most common interpretation would be the same as $x*(a+b)$. So, what's
the difference? Just a name change. As robert put it, x^3(10) could be
x(x(x(10))) if that meant x*(x*x*(10))), but in paper we usually don't
write the multiplication operators, using implicit multiplication like
William himself explained:
sage: implicit_multiplication(True)
sage: var('x')
x
sage: 3x^3 + 5x - 2
3*x^3 + 5*x - 2
Then, it becomes important that a computer doesn't have the same parsing
system as we humans do (and any attempt to replicate that would, well,
you can imagine). The thing is that we are building a computer system to
deal with those problems, and in that we must make design decisions
based on what's easier/common/fast/etc.
In my opinion, it would be better to have all functions be declared like
$ f(x) = x^3 + x + 1 $ or just use python's def for functions and "*"
for multiplication to make all cases clear. After all, quoting import
this: "There should be one-- and preferably only one --obvious way to do
it."
Ronan Paixão
Peter
mathematical practice this not
assumed, and expressions like x(3) are avoided or interpreted as 3x
(=3*x). Only when it is clear that
a symbolic name is a function name (like f,g) does function
application become the default. If I read in a paper:
"Let $f:R\to R$ be defined by $f = x^3+x+1$."
I would consider this a (fairly harmless) typo, since the author
surely meant "...defined by $f(x) = x^3+x+1$."
This distinction between variable names and function names could be
implemented
via another symbolic expression subtype for "FunctionExpression".
e.g.
function_var("f,g") # or maybe fvar("f,g")
f(x) = x^3 + x + 1 # equivalent to: f = lambda x: x^3 + x + 1
f(1)
Out: 3
(f+g)(x)
Out: f(x)+g(x)
f+x
Out: Error: don't know how to add FunctionExpression and
SymbolicExpression
(f^3)(x)
Out: f(f(f(x)))
x(10)
Out: Error: SymbolicExpression is not callable
For undergraduates this behavior might be less confusing than having
expressions like
x(x+1) be silently misinterpreted as x+1.
--Peter
Ronan Paixão
> I don't see why every SymbolicExpression should be callable. In usual
> mathematical practice this not
> assumed, and expressions like x(3) are avoided or interpreted as 3x
> (=3*x). Only when it is clear that
> a symbolic name is a function name (like f,g) does function
> application become the default. If I read in a paper:
f is not always a function name. In electric/electronic engineering, f
is also commonly used for frequency, which is usually a variable.
Ronan Paixão
Robert Dodier
> I find this bizarre. I am absolutely certain that I want to view $f$
> as a polynomial in one variable and evaluate it at 10.
What is worrisome here is that you are all too ready to
rule out alternatives, which, as pointed out elsewhere in
this thread, are not nearly as bizarre as you say.
It's rather unmathematical, frankly, to insist that you know
the one true interpretation of an ambiguous expression.
> I can think of lots of alternate ideas (evaluate everything to
> bottom!) but I believe none of them are common.
I'm too ignorant to suggest anything exotic.
The larger issue is that callable symbolic expressions are a
convenience hack; since they are starting fresh, Sage
developers can and should steer away from them.
I say this after encountering various convenience hacks
in Maxima, which, lo, these many decades on, are
very hard to banish.
FWIW
Robert Dodier
Robert Dodier
> "Let $f:R\to R$ be defined by $f = x^3+x+1$."
>
> I would consider this a (fairly harmless) typo, since the author
> surely meant "...defined by $f(x) = x^3+x+1$."
How could he express it so that his readers wouldn't
mistakenly try to clean it up? I don't think he should
bother trying.
FWIW
Robert Dodier
Robert Bradshaw
> William Stein wrote:
>
>> Incidentally, if we did allow automatic creation of symbolic
>> variables, and default calling of symbolic expressions, then
>> doing something like this would happen
>> all the time and confuse the crap out of people:
>>
>> sage: function_name_with_slight_typo(10)
>> 10
>
> Well, that's weird, but it's not weird because of automatically
> creating a variable for function_name_with_slight_typo.
> Calling symbolic expressions -- that's weird.
For me the question is not so much what is "weird" but rather what
behavior has the most potential for strange, subtle bugs. The nature
of the "symbolic ring" to try and accept and absorb about anything
makes this much worse--especially as I'd rather get an immediate
error. For me Sage is much more than an environment to manipulate
expressions, but a scriptable computation engine. Also, Sage being
typed with many various parents and other objects makes it more
natural to require the user to declare things ahead of time.
>> I think it would be interesting to have at least the capability
>> of a mode where variable names are made symbolic if
>> not previously used, at least if the calling behavior were redefined
>> as above. This would have be done by somehow parsing the
>> input, finding all undefined variables, defining them, etc....
>> It's techincaly possible. Maybe Fernando Perez and I can
>> try to make a demo of something like this at Sage Days 11.
>
> I would be inclined to plug in a custom top-level interpreter loop
> which just catches NameError and instantiates suitable variables
> and reevaluates the input when that happens. Is there a way to
> get Python to parse the input without evaluating it? (Isn't there
> an AST package or s.t.l.t. which could do that?) Then you could
> (I guess) detect undefined variables without causing side-effects
> from any part of the input. Just a guess -- I'm no expert on Python.
There is, see http://www.python.org/doc/2.5.2/lib/module-
compiler.html . Tools are even provided to "walk" the tree, so one
could, for example, easily extract all (undeclared, non-declaration)
NameNodes and define them to be symbolic variables before evaluating
the code. Much better than introducing possible side effects with
repeated re-evaluation. (Of course, I would expect this as an
optional mode.)
I see this thread has somewhat diverged from the original topic in
the last couple of days, but I think a lot of the grief could be
saved via better documentation. I created http://trac.sagemath.org/
sage_trac/ticket/4458 . Once you know what a NameError means,
declaring things is an easy fix.
- Robert
Robert Bradshaw
> On Nov 5, 10:10 pm, Nick Alexander <ncalexan...@gmail.com> wrote:
>
>> I find this bizarre. I am absolutely certain that I want to view $f$
>> as a polynomial in one variable and evaluate it at 10.
>
> That's nice. I wouldn't want to stand in your way.
> What is worrisome here is that you are all too ready to
> rule out alternatives, which, as pointed out elsewhere in
> this thread, are not nearly as bizarre as you say.
> It's rather unmathematical, frankly, to insist that you know
> the one true interpretation of an ambiguous expression.
I think settling on a good, consistent, default behavior is fine,
especially if it's what most people "expect." I do consider it a bug
if these kind of interpretations were impossible to make explicitly.
sage: f(x) = x^3+1
sage: f+1 # perfectly natural
x |--> x^3 + 2
sage: f^3 # should this be f(f(f(x))) or consistent
with the above?
x |--> (x^3 + 1)^3
Of course, Python functions don't behave this way (do any languages)
so maybe that's not too bad:
sage: f = lambda x: x^3+1
sage: f^3
Traceback (most recent call last)
...
TypeError: unsupported operand type(s) for ** or pow(): 'function'
and 'int'
>> I can think of lots of alternate ideas (evaluate everything to
>> bottom!) but I believe none of them are common.
>
> All of the alternatives I suggested are pedestrian.
> I'm too ignorant to suggest anything exotic.
>
> The larger issue is that callable symbolic expressions are a
> convenience hack; since they are starting fresh, Sage
> developers can and should steer away from them.
> I say this after encountering various convenience hacks
> in Maxima, which, lo, these many decades on, are
> very hard to banish.
Some acceptance of "convenience hacks" are necessary to make a
useable system. The whole coercion model is one such example
(pedantically, it's wrong to do, for instance, arithmetic between
elements belonging to different objects, but having to explicitly
specify maps is to cumbersome (and error-prone) to consider, and it
can be done in a consistent enough way to not cause mathematical
correctness issues).
We didn't start out with callable symbolic expressions, one always
had to turn them into functions first (or name variables explicitly
via keyword arguments). This caused much more confusion (and
inconvenience) than
sage: f = x^3-1
sage: f(10)
999
where at least everyone understands what's happening (even if they're
not happy about it). There's also things like
plot(x^3-1, -2, 2)
integrate(x^3-1, -2, 2)
which, though no independent variable is specified, have (in my mind)
very obvious intent. Making all other objects (e.g. polynomials,
power series, etc.) have callable and non-callable counterparts would
be an implementation headache as well.
> FWIW
>
> Robert Dodier
I just realized yours was the other email on this thread that I just
responded to :). Don't take it as a personal argument, it's just that
of all the emails in this thread you brought up the most interesting
points to respond to.
- Robert