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
Simon King
the impression that I got from this thread is the following:
-------
Commutative:
1. If f is a *commutative* polynomial in x,y,z,..., then everybody
would at least correctly guess that f(1,2,3,...) has the intended
meaning "evalutation of f at x=1, y=2, z=3,..."
2. Some people would actually *expect* (not just accept) that this
meaning is intended.
=>
It is ok that multivariate polynomials in Sage are callable in the
sense described above. Currently, symbolic variables commute with each
other, and thus it is acceptable that they are callable as well.
Hence, no need to change!
Do we agree on this?
---------
Non-Commutative:
Several people gave evidence that calling a non-commutative
polynomial should be different from the above. It makes sense to
consider non-commutative multiplication as a functional composition
(e.g., if differentials are involved). Therefore my suggestion: f(a,b)
for non-commutative bivariate polynomial f should require that a and b
are functions, and the nc-monomials in f give rise to functional
compositions of a and b. However, this suggestion would only work if f
is freely non-commutative.
=>
The people who are currently implementing non-commutative
polynomials (Burcin, Michael B., William?) should speak up, what
meaning they want to give to their __call__ methods.
Regards
Simon
Burcin Erocal
Simon King <ki...@mathematik.uni-jena.de> wrote:
>
> Dear Team,
>
> the impression that I got from this thread is the following:
> -------
> Commutative:
> 1. If f is a *commutative* polynomial in x,y,z,..., then everybody
> would at least correctly guess that f(1,2,3,...) has the intended
> meaning "evalutation of f at x=1, y=2, z=3,..."
> 2. Some people would actually *expect* (not just accept) that this
> meaning is intended.
>
> =>
> It is ok that multivariate polynomials in Sage are callable in the
> sense described above. Currently, symbolic variables commute with each
> other, and thus it is acceptable that they are callable as well.
>
> Hence, no need to change!
> Do we agree on this?
I was already unhappy about symbolic expressions being callable, this
discussion convinced me that they shouldn't be.
One thing we should not forget is that, polynomials and symbolic
expressions in Sage are different things. I really appreciate
polynomials being callable, and I don't see the need to differentiate
polynomial functions and polynomials.
Note that for polynomials, it is clear what to do when it is called.
There is an ordered list of variables that will be substituted. We
don't need to guess what the user intends.
Things are not so simple for symbolic expressions. I find the current
behavior confusing, and many people on sage-support seem to be confused
by the different ways of constructing functions in Sage. (i.e.,
python function definition, f(x) = ... syntax, just use a symbolic
expression)
I think the python function definition and f(x) = syntax are more than
enough, and we don't need to make symbolic expressions callable.
The advantage of the f(x) syntax is that it gives a clear and ordered
list of variables to substitute for. One could say that this exists for
any symbolic expression, since we have an alphabetically ordered list of
variables, but then we have the following problem:
sage: var('x,y,a,b')
(x, y, a, b)
sage: f = a*x + b*y
sage: f(3,5)
5*y + 3*x
If I was trying to second guess what the user intended, I would expect
a and b to be constants, and x and y to be replaced. This is just
impossible to get right.
Keeping the "explicit is better than implicit" motto in mind, I think
this should change. This syntax is much better, IMHO.
sage: f(x,y) = a*x + b*y
sage: f(3,5)
5*b + 3*a
And I think this should raise an error:
sage: f(5)
b*y + 5*a
BTW, don't forget that we're going to have non-commutative symbolic
variables at some point.
> ---------
> Non-Commutative:
> Several people gave evidence that calling a non-commutative
> polynomial should be different from the above. It makes sense to
> consider non-commutative multiplication as a functional composition
> (e.g., if differentials are involved). Therefore my suggestion: f(a,b)
> for non-commutative bivariate polynomial f should require that a and b
> are functions, and the nc-monomials in f give rise to functional
> compositions of a and b. However, this suggestion would only work if f
> is freely non-commutative.
>
> =>
> The people who are currently implementing non-commutative
> polynomials (Burcin, Michael B., William?) should speak up, what
> meaning they want to give to their __call__ methods.
I haven't thought about it at all. I am working towards a deadline
(next week), so I didn't have any time to cleaning that up to even
submit the initial version.
Cheers,
Burcin
John Cremona
I find Burcin's arguments very persuasive. The user may think of some
of their variable letters being variables and some of them parameters
(as in the a,b vs, x,y example) but there cannot be a reliable way of
Sage guessing which is which.
There is also the issue of variable ordering. e.g.
sage: var('long_variable_name another_long_name')
(long_variable_name, another_long_name)
sage: f = long_variable_name - another_long_name
sage: f(1,2)
1
If I had had you all place bets on the final result, I wonder what
majority there would have been for -1 ? The order used is neither
alphabetical, nor is it the order of the variables in the list
returned by var(). So we just don't know.
sage: f.subs(long_variable_name=1,another_long_name=2)
-1
is at least unambiguous.
John
>
> Cheers,
>
> Burcin
>
>
> >
>
Mike Hansen
On Fri, Nov 7, 2008 at 2:46 AM, John Cremona <john.c...@gmail.com> wrote:
> There is also the issue of variable ordering. e.g.
>
> sage: var('long_variable_name another_long_name')
> (long_variable_name, another_long_name)
> sage: f = long_variable_name - another_long_name
> sage: f(1,2)
> 1
>
> If I had had you all place bets on the final result, I wonder what
> majority there would have been for -1 ? The order used is neither
> alphabetical, nor is it the order of the variables in the list
> returned by var(). So we just don't know.
Actually, it is alphabetical and is the order that appears in f.variables().
sage: f.variables()
(another_long_name, long_variable_name)
--Mike
Jason Grout
I think it is very handy to be able to partially evaluate an
expression. Do you propose a syntax that lets you effectively do f(5)
and get a function back? For example, if I want to plot a level curve
of f at x=5 presuming that f(x,y)=2*x+3*y, say. Here are some
possibilities:
plot( f(x=5), (y, -10,10))
plot( f(x=5,y=y), (y, -10,10))
plot( f(5,None), (y, -10,10))
plot( f(5,y), (y, -10,10))
g(y) = f(5,y)
plot(g, (y, -10,10))
That last one seemed too verbose
Jason
Jason Grout
I guess you could also do:
plot( lambda y: f(5,y), (y, -10,10))
but then you give up things like fast_float.
Jason
John Cremona
2008/11/7 Jason Grout <jason...@creativetrax.com>:
>
>
>
> I think it is very handy to be able to partially evaluate an
> expression. Do you propose a syntax that lets you effectively do f(5)
> and get a function back? For example, if I want to plot a level curve
> of f at x=5 presuming that f(x,y)=2*x+3*y, say. Here are some
> possibilities:
>
>
>
> plot( f(x=5), (y, -10,10))
>
> plot( f(x=5,y=y), (y, -10,10))
>
> plot( f(5,None), (y, -10,10))
>
I prefer this one:
> plot( f(5,y), (y, -10,10))
>
and it would be even better if y could be replaced by a dummy
variable, like this: plot( f(f,t), (t,-10,10) ) -- without having
to declare t as a variable too.
John
Mike Hansen
>> plot( f(x=5), (y, -10,10))
>>
>> plot( f(x=5,y=y), (y, -10,10))
>>
>> plot( f(5,None), (y, -10,10))
>>
>> plot( f(5,y), (y, -10,10))
>>
>> g(y) = f(5,y)
>> plot(g, (y, -10,10))
>> That last one seemed too verbose
>
>
> I guess you could also do:
>
> plot( lambda y: f(5,y), (y, -10,10))
>
> but then you give up things like fast_float.
You didn't mention
plot(f(5,y).function(y), (y, -10,10))
which is the one that'd be compatible with non-callable expressions.
--Mike
Burcin Erocal
If symbolic expressions cease to be callable, plot would need to be
changed to handle these cases:
sage: plot( x^2 )
This seems plausible, since at the moment we allow
sage: plot( sin )
for usability.
Going back to your example, f(5,y) would just return a symbolic
expression, so
sage: f(x,y)=2*x+3*y
sage: plot( f(5,y), (y, -10,10))
would be equivalent to
sage: plot( 10+3*y, (y, -10,10))
which would just work.
The current syntax allows this:
sage: f(x,y) = a*x + b*y
sage: f(5)
b*y + 5*a
sage: f(5)(5)
b*y + 25
I think the last line should be a syntax error.
Cheers,
Burcin
Jason Grout
I agree, since f was explicitly defined with variables x and y.
f(5) should return a function g(y) = b*y+5*a
I think this could be easily changed (just return a function that has
explicit variables, rather than just a symbolic expression).
Jason
Burcin Erocal
I would still like to check that the length of the arguments match, and
raise an error if they don't. So, continuing the above example,
sage: f(5)
should raise an error.
It might be better if
sage: f(5, None)
or
sage: f(5,y)
returned the function g(y) = b*y+5*a.
Cheers,
Burcin
Jason Grout
I agree with both of those alternatives, and agree that it would be
better to insist that f take two arguments.
Jason
kcrisman
> >>> The current syntax allows this:
>
> >>> sage: f(x,y) = a*x + b*y
> >>> sage: f(5)
> >>> b*y + 5*a
> >>> sage: f(5)(5)
> >>> b*y + 25
>
> >>> I think the last line should be a syntax error.
>
> >> I agree, since f was explicitly defined with variables x and y.
>
> >> f(5) should return a function g(y) = b*y+5*a
>
> >> I think this could be easily changed (just return a function that has
> >> explicit variables, rather than just a symbolic expression).
>
> > I would still like to check that the length of the arguments match, and
> > raise an error if they don't. So, continuing the above example,
>
> > sage: f(5)
>
> > should raise an error.
>
> > It might be better if
>
> > sage: f(5, None)
>
> > or
>
> > sage: f(5,y)
>
> > returned the function g(y) = b*y+5*a.
>
> I agree with both of those alternatives, and agree that it would be
> better to insist that f take two arguments.
>
> Jason
more than one argument/variable, very much in the spirit of the (very
important and useful) compromise to have 'x' predefined as a variable
but none others.
If x^2 isn't callable, though, I might as well not use Sage in the
undergraduate classroom, or at least not ask any students to use it.
Well, maybe that's a stretch for me to claim? I'm not sure, honestly,
but ... it's just that computer mathematics systems are pedantic
enough as it is - for obvious reasons, but with too much of it I would
rather teach 1900-style and have them learn to visualize and compute
on their own (radical idea, I know!), since that also has a lot of
benefits pedagogically and mathematically. But I would really rather
have both.
Just my two cents.
- kcrisman
Jason Grout
>
> If x^2 isn't callable, though, I might as well not use Sage in the
> undergraduate classroom, or at least not ask any students to use it.
> Well, maybe that's a stretch for me to claim? I'm not sure, honestly,
> but ... it's just that computer mathematics systems are pedantic
> enough as it is - for obvious reasons, but with too much of it I would
> rather teach 1900-style and have them learn to visualize and compute
> on their own (radical idea, I know!), since that also has a lot of
> benefits pedagogically and mathematically. But I would really rather
> have both.
>
How would x^2 being callable help? Can you give a use case for showing
that x^2 being callable is much easier/simpler than without it being
callable?
I'm not saying it shouldn't be callable; I'm just asking for your opinion.
Jason
kcrisman
> How would x^2 being callable help? Can you give a use case for showing
> that x^2 being callable is much easier/simpler than without it being
> callable?
>
> I'm not saying it shouldn't be callable; I'm just asking for your opinion.
thread was suggesting that perhaps if f=x^2 then f(2) should be 2x^2,
not 4, and my understanding was that this was what it meant to not be
callable. Also it sounded like then plot(x^2,0,1) would have to be
plot(x^2,x,0,1) in that case. If I am mistaken, that's fine.
I feel like by letting f=x^2 be available instead of f(x)=x^2, we are
lowering the bar to use of Sage; the more conventions like this to
remember, the harder it is to use - not because people can't use it,
but because the frustration quotient (especially in a big class) is
high enough to drop it, since there are better things to do with one's
time than have to explain this sort of thing again and again. It
doesn't mean I personally would stop using Sage, just that I might not
use it as often as I would like in a class. However, I am glad it's
being discussed - it is interesting to learn about the different
reasons for such things.
The real issue is that someone who has the option of getting a site
license for something else (or using an existing one) might decide to
use that instead of Sage - not because of this per se, but because
they weigh "larger user base and program I am familiar with, even if
it has minor annoyances" or whatever against "various minor
annoyances, including this one, in program I'm not very familiar with"
- even if both programs have the same behavior, which I don't know
since I don't have the opportunity to use them.
So if the goal of Sage is to compete with them, which for now (and
hopefully in the future too!) may mean needing to be even better than
them, then part of that should be to allow things like this. It is a
minor annoyance to somebody either way, but it seems like this is a
case where it's a minor annoyance (as opposed to the major annoyance
of all letters being predefined as variables) for some, where the
other way would be a slightly more major annoyance for others. At
least, that's how I view it, both in my research and teaching. So
far, I think Sage has done a pretty good job balancing these things,
as someone else said earlier in the thread.
- kcrisman
Pierre
--symbolic expressions are not callable, the functional notation is
required,
--on startup, SAGE has defined x to be... the identity ! so it is
callable.
one would need to make sure that f(g) means composition of functions,
so that, say sin(x) is really the sine function; and x should perhaps
have its __str__ modified so it prints as "x" and not as "foo --> foo"
or whatever. But this is all easy to arrange.
this way we would have a strong and logical symbolic system, and one
"exception" with x which is helpful for newbies/students/etc. This
seems in the spirit of what we have already.
just a thought.
pierre
Ronan Paixão
> Here are some
> possibilities:
>
>
>
> plot( f(x=5), (y, -10,10))
>
> plot( f(x=5,y=y), (y, -10,10))
>
> plot( f(5,None), (y, -10,10))
>
> plot( f(5,y), (y, -10,10))
>
> g(y) = f(5,y)
> plot(g, (y, -10,10))
> That last one seemed too verbose
>
> Jason
>
Personally I like allowing calls, but just using kwargs, like f(x=5),
forcing explicit variable naming, at the same time it would be a
convenience function for .subs(). That is unless f is declared as a
function like f(x) = x^3 because the declaration would imply variable
order.
If one wants to keep the convenience of using f(5) at least it would be
better to only allow one substitution for x, since x already has an
established status (if one wants it even more generic, allow only
single-variable functions). That way calling f(5,3) would raise an error
and force the user to explicitly order the variables.
Ronan Paixão
Georg S. Weber
summarizing ideas and arguments from this thread gives the following
proposal:
Sage would benefit from the possibility to work in two different
modes, a "classroom mode", and a "pedantic mode".
In the classroom mode, e.g. symbolic expressions would be callable,
and quite some guessing would happen behind the scene. Since Wolfram
Research is likely to have spent (compared to the other players) most
resources in usability issues, the Sage classroom mode could be
modeled quite closely after what they do. And we will get the same
strange erronuous behaviour in certain cases as they do, and as was
mentioned above (mma mailing lists). Calling non-commutative rings
modules in Sage might just barf and refuse to work in classroom-mode.
In the pedantic mode, e.g. variables just have to be defined. All the
plot functions might have a considerably more complicated syntax. The
user would have more freedom to exactly tell what he wants Sage to do
for him. But the user also would have now the greater responsibility
inevitably linked to being granted more power.
As for the details, for the user interface it essentially boils down
to have verbose error messages. E.g. a plot function called in
"pedantic mode", but with "classroom mode" style parameters not just
saying "No", but telling the user "In classroom mode, this would work.
You are in pedantic mode, so you probably want to do <Code Snippet> to
get the same behaviour".
Technically, alas, this proposal would imply a good deal of work, and
a whole new dimension of complexity. We would need many, many tests
being doubled (one for each of the two modes), to mention only one of
several areas. The Sage project does not seem to have the necessary
developer resources, at least for the near future.
What do you think?
Cheers,
gsw
Georg S. Weber
better call it "graduate mode" instead of "pedantic mode", at least in
the documentation.
:-)
Cheers,
gsw
Ronan Paixão
> Ahh,
>
> better call it "graduate mode" instead of "pedantic mode", at least in
> the documentation.
>
> :-)
>
> Cheers,
> gsw
Ronan
Robert Bradshaw
[...]
>>> Going back to your example, f(5,y) would just return a symbolic
>>> expression, so
>>>
>>> sage: f(x,y)=2*x+3*y
>>> sage: plot( f(5,y), (y, -10,10))
>>>
>>> would be equivalent to
>>>
>>> sage: plot( 10+3*y, (y, -10,10))
>>>
>>> which would just work.
>>>
>>> The current syntax allows this:
>>>
>>> sage: f(x,y) = a*x + b*y
>>> sage: f(5)
>>> b*y + 5*a
>>> sage: f(5)(5)
>>> b*y + 25
>>>
>>>
>>> I think the last line should be a syntax error.
>>
>>
>> I agree, since f was explicitly defined with variables x and y.
>>
>> f(5) should return a function g(y) = b*y+5*a
>>
>> I think this could be easily changed (just return a function that has
>> explicit variables, rather than just a symbolic expression).
>
> I would still like to check that the length of the arguments match,
> and
> raise an error if they don't. So, continuing the above example,
>
> sage: f(5)
>
> should raise an error.
I agree here.
> It might be better if
>
> sage: f(5, None)
This makes sense to me, but would be quite strange to the "average
calculus student" (where the average is over the the undergrads that
I have interacted with).
> or
>
> sage: f(5,y)
>
> returned the function g(y) = b*y+5*a.
What about f(5,a), would it be a function of a? Or f(y,5)? Or is
there somehow special casing going on when the variable name plugged
in matches the name of the expected argument (I'd rather let f(...)
have the same return type no matter what the arguments are).
I think this is *the* key point that needs to be addressed here. I
doubt people are going to avoid using Sage because symbolic
expressions are callable. However, I could see a lot of people
wondering why
sage: f = x^2
sage: f(2)
or
sage: plot(f, -10, 10)
does not work, and finding it easier to go with a system that "just
works" (for them) than worry about always distinguishing between
callable vs. non-callable expressions (or, worrying about teaching
such a distinction to their calculus 101 students).
It seems that the core objections are about Sage's automatic
resolution of ambiguity. When I write x=var(x); f = x^2, (almost) all
of us agree what f(2) should be. But if I write f = a*x^2, f(2) now
has additional ambiguity, and in particular the interpretation
"2*x^2" is arguably the "wrong" one (though reverse-alphabetic or
some other ordering is potentially just as bad and even more confusing).
I would propose that *single variable* expressions behave like
callables in one variable, there is no ambiguity as to the ordering,
so one should be able to call, integrate, differentiate, plot, etc.
with them without having to specify the variable. On trying to use a
expression with more than one indeterminate, an error should be
raised with a clear explanation the ambiguity and of how to define a
mulit-variate function. The f(x=5) syntax should still be available
as all ambiguity is resolved.
- Robert
Stan Schymanski
Robert Bradshaw wrote:
>
> [snip]
>
> I would propose that *single variable* expressions behave like
> callables in one variable, there is no ambiguity as to the ordering,
> so one should be able to call, integrate, differentiate, plot, etc.
> with them without having to specify the variable. On trying to use a
> expression with more than one indeterminate, an error should be
> raised with a clear explanation the ambiguity and of how to define a
> mulit-variate function. The f(x=5) syntax should still be available
> as all ambiguity is resolved.
>
> - Robert
>
>
>
I do not see any advantage in making implicit assumptions such as x is a
variable but a, y or whatever isn't or that the arguments of a callable
function are assigned to variables in alphabetic order. As a beginner, I
fell for Fortran's implicit assumptions and it took me ages to find out
that I need to put "implicit none" at the beginning of all my code.
Meaningful error messages are more helpful for everyone than solving
ambiguity by implicit assumptions that one has to remember in order to
understand what the program does.
The problem of losing beginners to other software packages only occurs
if they get lost, for example if the error message does not tell them
what to do in order to advance. *Or* if the program does something they
don't understand because it makes a different implicit assumption than
they would, but doesn't tell them. In my opinion, consistency is very
easy to get used to, while the attempt to guess what different people
mean will result in a hell of a lot of confusion and scare many people off.
These are just my 5 cents.
Stan