On Nov 2, 2008, at 00:01 , seber...@spawar.navy.mil wrote:
> Is it possible to avoid need to declare variables with var commands?
> Mathematica doesn't need var commands so people coming from > Mathematica may get confused when they issue their first plot command > in Sage.
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 --------
<seber...@spawar.navy.mil> wrote:
> Is it possible to avoid need to declare variables with var commands?
> Mathematica doesn't need var commands so people coming from
> Mathematica may get confused when they issue their first plot command
> in Sage.
On the opposite: Personally I find it very intuitive that, if you want
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.
On Nov 2, 8:27 am, "Justin C. Walker" <jus...@mac.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...
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)
Justin C. Walker wrote:
> On Nov 2, 2008, at 00:01 , seber...@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.
> 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.
(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.
On Sun, Nov 2, 2008 at 9:53 AM, Robert Dodier <robert.dod...@gmail.com> wrote:
> Justin C. Walker wrote:
>> On Nov 2, 2008, at 00:01 , seber...@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.
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?
I think Justin's statement is true in the sense that people with a
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
William Stein wrote:
> I personally Python well suited to mathematical computation,
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.
> 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.
> 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".
> 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.
> 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
On Sun, Nov 2, 2008 at 10:35 AM, Simon King <k...@mathematik.uni-jena.de> wrote:
> Hi!
> 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?
> I think Justin's statement is true in the sense that people with a > 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
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
> On Nov 2, 2008, at 1:57 PM, Robert Dodier wrote: > > 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.
I'm not quite sure this is easily doable. Does iPython support some sort of exception catching/processing?
On Sun, Nov 2, 2008 at 10:57 AM, Robert Dodier <robert.dod...@gmail.com> wrote: > 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.
> On Sun, Nov 2, 2008 at 10:57 AM, Robert Dodier <robert.dod...@gmail.com> wrote: >> 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.
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?
> 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.
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 :)
> 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
> 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 :)
On Sun, Nov 2, 2008 at 12:22 PM, John Cremona <john.crem...@gmail.com> wrote: > 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.
> 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).
Would it be possible to have a beginners mode where undefined
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.
On Sun, Nov 2, 2008 at 6:58 PM, Ronan Paixão <ronanpai...@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).
On Sun, Nov 2, 2008 at 3:58 PM, Ronan Paixão <ronanpai...@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).
Everybody using CAS's ivia a command line or notebook
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).
MATLAB's a good example, since it's very popular and as you point out
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.
We literally already tried that solution and it is very very bad, at least as
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
Associate Professor of Mathematics
University of Washington
http://wstein.org
> Would it be possible to have a beginners mode where undefined
> variables are allowed?
Nobody has proposed a technically feasible way to actually do this yet,
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.
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.
> On Sun, Nov 2, 2008 at 6:58 PM, Ronan Paixão <ronanpai...@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
-- William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
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.
> 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.
On Mon, Nov 3, 2008 at 8:05 AM, Robert Dodier <robert.dod...@gmail.com> wrote:
> 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.
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.
In some version, there was an invasive declaration of single character
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.
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'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.
