258 views

Skip to first unread message

Nov 2, 2008, 2:01:00 AM11/2/08

to sage-devel

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.

Chris

Mathematica doesn't need var commands so people coming from

Mathematica may get confused when they issue their first plot command

in Sage.

Chris

Nov 2, 2008, 2:27:13 AM11/2/08

to sage-...@googlegroups.com

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

--------

Nov 2, 2008, 5:22:39 AM11/2/08

to sage-devel

Dear Chris

On Nov 2, 2:01 am, "seber...@spawar.navy.mil"

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.

Cheers

Simon

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

Nov 2, 2008, 5:55:39 AM11/2/08

to sage-devel

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...
> 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

Nov 2, 2008, 11:53:29 AM11/2/08

to sage-devel

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
> 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

Nov 2, 2008, 12:18:41 PM11/2/08

to sage-...@googlegroups.com

On Sun, Nov 2, 2008 at 9:53 AM, Robert Dodier <robert...@gmail.com> wrote:

>

> 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.

>

> 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

Nov 2, 2008, 1:35:40 PM11/2/08

to sage-devel

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

Cheers

Simon

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

Nov 2, 2008, 1:57:50 PM11/2/08

to sage-devel

William Stein wrote:

> I personally Python well suited to mathematical computation,

No problem with any computation involving literal objects.
> 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

Nov 2, 2008, 2:07:31 PM11/2/08

to sage-...@googlegroups.com

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.

Tim.

---

Tim Lahey

PhD Candidate, Systems Design Engineering

University of Waterloo

Nov 2, 2008, 2:19:54 PM11/2/08

to sage-...@googlegroups.com

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

Nov 2, 2008, 2:21:57 PM11/2/08

to sage-...@googlegroups.com

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

Nov 2, 2008, 2:24:50 PM11/2/08

to sage-...@googlegroups.com

On Sun, Nov 2, 2008 at 10:57 AM, Robert Dodier <robert...@gmail.com> wrote:

> William Stein wrote:

>

>> I personally Python well suited to mathematical computation,

> 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

Nov 2, 2008, 3:22:56 PM11/2/08

to sage-...@googlegroups.com

2008/11/2 William Stein <wst...@gmail.com>:

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

>

> >

>

Nov 2, 2008, 3:29:44 PM11/2/08

to sage-devel

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

Nov 2, 2008, 3:37:44 PM11/2/08

to sage-...@googlegroups.com

2008/11/2 mabshoff <mabs...@googlemail.com>:

>

>

>

> 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.

>

>

>

> 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

Nov 2, 2008, 3:53:44 PM11/2/08

to sage-...@googlegroups.com, Fernando Perez

On Sun, Nov 2, 2008 at 12:22 PM, John Cremona <john.c...@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

> 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

Nov 2, 2008, 6:58:50 PM11/2/08

to sage-...@googlegroups.com

> 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

Nov 2, 2008, 7:16:20 PM11/2/08

to sage-...@googlegroups.com

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.

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.

Nov 2, 2008, 7:23:09 PM11/2/08

to sage-...@googlegroups.com

On Sun, Nov 2, 2008 at 3: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).

Everybody using CAS's ivia a command line or notebook
>

>

>> 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

>

>

> >

>

Nov 2, 2008, 7:30:39 PM11/2/08

to sage-...@googlegroups.com

On Sun, Nov 2, 2008 at 4:16 PM, Timothy Clemans

<timothy...@gmail.com> wrote:

>

> 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,
<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

>>

>>

>> >

>>

>

> >

>

Nov 2, 2008, 7:39:00 PM11/2/08

to sage-devel

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

Nov 3, 2008, 11:05:14 AM11/3/08

to sage-devel

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
> 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

Nov 3, 2008, 11:27:49 AM11/3/08

to sage-...@googlegroups.com

On Mon, Nov 3, 2008 at 8:05 AM, Robert Dodier <robert...@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.

>

> 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

Nov 3, 2008, 5:04:12 PM11/3/08

to sage-devel

Hi John,

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.

--David

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

Nov 5, 2008, 11:55:14 PM11/5/08

to sage-devel

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.
> 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

Nov 6, 2008, 12:10:04 AM11/6/08

to sage-...@googlegroups.com

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

Nov 6, 2008, 4:06:31 AM11/6/08

to sage-...@googlegroups.com

I also find Robert D's take on this bizarre, but it just shows (again)

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.

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>:

Nov 6, 2008, 4:21:33 AM11/6/08

to sage-devel

Hi!

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.

Neither am I.

<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

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

Nov 6, 2008, 8:13:38 AM11/6/08

to sage-...@googlegroups.com

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

--

Nov 6, 2008, 2:16:05 PM11/6/08

to sage-devel

If we change the name and nature of the objects a little bit, one can

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.

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.

Nov 6, 2008, 2:44:26 PM11/6/08

to sage-...@googlegroups.com

IANAM (I am not a mathematician), but from what I see, all the problem

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

though writing xx wouldn't give the desired result.

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

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

Nov 6, 2008, 3:02:12 PM11/6/08

to sage-devel

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:

"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

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

Nov 6, 2008, 3:17:51 PM11/6/08

to sage-...@googlegroups.com

Em Qui, 2008-11-06 às 12:02 -0800, Peter escreveu:

> 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:

> 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

Nov 6, 2008, 7:56:54 PM11/6/08

to sage-devel

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.
> 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

Nov 6, 2008, 8:02:25 PM11/6/08

to sage-devel

On Nov 6, 1:02 pm, Peter <Peter.Jip...@gmail.com> wrote:

> "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$."

What if the author really did mean just what he wrote?
> "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

Nov 6, 2008, 8:45:44 PM11/6/08

to sage-...@googlegroups.com

On Nov 3, 2008, at 8:05 AM, Robert Dodier 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.

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

Nov 6, 2008, 9:10:48 PM11/6/08

to sage-...@googlegroups.com

On Nov 6, 2008, at 4:56 PM, Robert Dodier wrote:

> 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

Nov 7, 2008, 4:14:26 AM11/7/08