173 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

to sage-devel

Dear Team,

the impression that I got from this thread is the following:

-------

Commutative:

1. If f is a *commutative* polynomial in x,y,z,..., then everybody

would at least correctly guess that f(1,2,3,...) has the intended

meaning "evalutation of f at x=1, y=2, z=3,..."

2. Some people would actually *expect* (not just accept) that this

meaning is intended.

=>

It is ok that multivariate polynomials in Sage are callable in the

sense described above. Currently, symbolic variables commute with each

other, and thus it is acceptable that they are callable as well.

Hence, no need to change!

Do we agree on this?

---------

Non-Commutative:

Several people gave evidence that calling a non-commutative

polynomial should be different from the above. It makes sense to

consider non-commutative multiplication as a functional composition

(e.g., if differentials are involved). Therefore my suggestion: f(a,b)

for non-commutative bivariate polynomial f should require that a and b

are functions, and the nc-monomials in f give rise to functional

compositions of a and b. However, this suggestion would only work if f

is freely non-commutative.

=>

The people who are currently implementing non-commutative

polynomials (Burcin, Michael B., William?) should speak up, what

meaning they want to give to their __call__ methods.

Regards

Simon

the impression that I got from this thread is the following:

-------

Commutative:

1. If f is a *commutative* polynomial in x,y,z,..., then everybody

would at least correctly guess that f(1,2,3,...) has the intended

meaning "evalutation of f at x=1, y=2, z=3,..."

2. Some people would actually *expect* (not just accept) that this

meaning is intended.

=>

It is ok that multivariate polynomials in Sage are callable in the

sense described above. Currently, symbolic variables commute with each

other, and thus it is acceptable that they are callable as well.

Hence, no need to change!

Do we agree on this?

---------

Non-Commutative:

Several people gave evidence that calling a non-commutative

polynomial should be different from the above. It makes sense to

consider non-commutative multiplication as a functional composition

(e.g., if differentials are involved). Therefore my suggestion: f(a,b)

for non-commutative bivariate polynomial f should require that a and b

are functions, and the nc-monomials in f give rise to functional

compositions of a and b. However, this suggestion would only work if f

is freely non-commutative.

=>

The people who are currently implementing non-commutative

polynomials (Burcin, Michael B., William?) should speak up, what

meaning they want to give to their __call__ methods.

Regards

Simon

Nov 7, 2008, 5:04:38 AM11/7/08

to sage-...@googlegroups.com

On Fri, 7 Nov 2008 01:14:26 -0800 (PST)

Simon King <ki...@mathematik.uni-jena.de> wrote:

Simon King <ki...@mathematik.uni-jena.de> wrote:

>

> Dear Team,

>

> the impression that I got from this thread is the following:

> -------

> Commutative:

> 1. If f is a *commutative* polynomial in x,y,z,..., then everybody

> would at least correctly guess that f(1,2,3,...) has the intended

> meaning "evalutation of f at x=1, y=2, z=3,..."

> 2. Some people would actually *expect* (not just accept) that this

> meaning is intended.

>

> =>

> It is ok that multivariate polynomials in Sage are callable in the

> sense described above. Currently, symbolic variables commute with each

> other, and thus it is acceptable that they are callable as well.

>

> Hence, no need to change!

> Do we agree on this?

I was already unhappy about symbolic expressions being callable, this

discussion convinced me that they shouldn't be.

One thing we should not forget is that, polynomials and symbolic

expressions in Sage are different things. I really appreciate

polynomials being callable, and I don't see the need to differentiate

polynomial functions and polynomials.

Note that for polynomials, it is clear what to do when it is called.

There is an ordered list of variables that will be substituted. We

don't need to guess what the user intends.

Things are not so simple for symbolic expressions. I find the current

behavior confusing, and many people on sage-support seem to be confused

by the different ways of constructing functions in Sage. (i.e.,

python function definition, f(x) = ... syntax, just use a symbolic

expression)

I think the python function definition and f(x) = syntax are more than

enough, and we don't need to make symbolic expressions callable.

The advantage of the f(x) syntax is that it gives a clear and ordered

list of variables to substitute for. One could say that this exists for

any symbolic expression, since we have an alphabetically ordered list of

variables, but then we have the following problem:

sage: var('x,y,a,b')

(x, y, a, b)

sage: f = a*x + b*y

sage: f(3,5)

5*y + 3*x

If I was trying to second guess what the user intended, I would expect

a and b to be constants, and x and y to be replaced. This is just

impossible to get right.

Keeping the "explicit is better than implicit" motto in mind, I think

this should change. This syntax is much better, IMHO.

sage: f(x,y) = a*x + b*y

sage: f(3,5)

5*b + 3*a

And I think this should raise an error:

sage: f(5)

b*y + 5*a

BTW, don't forget that we're going to have non-commutative symbolic

variables at some point.

> ---------

> Non-Commutative:

> Several people gave evidence that calling a non-commutative

> polynomial should be different from the above. It makes sense to

> consider non-commutative multiplication as a functional composition

> (e.g., if differentials are involved). Therefore my suggestion: f(a,b)

> for non-commutative bivariate polynomial f should require that a and b

> are functions, and the nc-monomials in f give rise to functional

> compositions of a and b. However, this suggestion would only work if f

> is freely non-commutative.

>

> =>

> The people who are currently implementing non-commutative

> polynomials (Burcin, Michael B., William?) should speak up, what

> meaning they want to give to their __call__ methods.

I haven't thought about it at all. I am working towards a deadline

(next week), so I didn't have any time to cleaning that up to even

submit the initial version.

Cheers,

Burcin

Nov 7, 2008, 5:46:09 AM11/7/08

to sage-...@googlegroups.com

2008/11/7 Burcin Erocal <bur...@erocal.org>:

I find Burcin's arguments very persuasive. The user may think of some

of their variable letters being variables and some of them parameters

(as in the a,b vs, x,y example) but there cannot be a reliable way of

Sage guessing which is which.

There is also the issue of variable ordering. e.g.

sage: var('long_variable_name another_long_name')

(long_variable_name, another_long_name)

sage: f = long_variable_name - another_long_name

sage: f(1,2)

1

If I had had you all place bets on the final result, I wonder what

majority there would have been for -1 ? The order used is neither

alphabetical, nor is it the order of the variables in the list

returned by var(). So we just don't know.

sage: f.subs(long_variable_name=1,another_long_name=2)

-1

is at least unambiguous.

John

>

> Cheers,

>

> Burcin

>

>

> >

>

Nov 7, 2008, 5:52:03 AM11/7/08

to sage-...@googlegroups.com

Hi John,

On Fri, Nov 7, 2008 at 2:46 AM, John Cremona <john.c...@gmail.com> wrote:

> There is also the issue of variable ordering. e.g.

>

> sage: var('long_variable_name another_long_name')

> (long_variable_name, another_long_name)

> sage: f = long_variable_name - another_long_name

> sage: f(1,2)

> 1

>

> If I had had you all place bets on the final result, I wonder what

> majority there would have been for -1 ? The order used is neither

> alphabetical, nor is it the order of the variables in the list

> returned by var(). So we just don't know.

Actually, it is alphabetical and is the order that appears in f.variables().

sage: f.variables()

(another_long_name, long_variable_name)

--Mike

Nov 7, 2008, 6:06:02 AM11/7/08

to sage-...@googlegroups.com

I think it is very handy to be able to partially evaluate an

expression. Do you propose a syntax that lets you effectively do f(5)

and get a function back? For example, if I want to plot a level curve

of f at x=5 presuming that f(x,y)=2*x+3*y, say. Here are some

possibilities:

plot( f(x=5), (y, -10,10))

plot( f(x=5,y=y), (y, -10,10))

plot( f(5,None), (y, -10,10))

plot( f(5,y), (y, -10,10))

g(y) = f(5,y)

plot(g, (y, -10,10))

That last one seemed too verbose

Jason

Nov 7, 2008, 6:14:22 AM11/7/08

to sage-...@googlegroups.com

I guess you could also do:

plot( lambda y: f(5,y), (y, -10,10))

but then you give up things like fast_float.

Jason

Nov 7, 2008, 6:23:26 AM11/7/08

to sage-...@googlegroups.com

OK so I don't know my alphabet.

2008/11/7 Jason Grout <jason...@creativetrax.com>:

>

>

>

> I think it is very handy to be able to partially evaluate an

> expression. Do you propose a syntax that lets you effectively do f(5)

> and get a function back? For example, if I want to plot a level curve

> of f at x=5 presuming that f(x,y)=2*x+3*y, say. Here are some

> possibilities:

>

>

>

> plot( f(x=5), (y, -10,10))

>

> plot( f(x=5,y=y), (y, -10,10))

>

> plot( f(5,None), (y, -10,10))

>

I prefer this one:

> plot( f(5,y), (y, -10,10))

>

and it would be even better if y could be replaced by a dummy

variable, like this: plot( f(f,t), (t,-10,10) ) -- without having

to declare t as a variable too.

John

Nov 7, 2008, 6:26:35 AM11/7/08

to sage-...@googlegroups.com

On Fri, Nov 7, 2008 at 3:14 AM, Jason Grout <jason...@creativetrax.com> wrote:

>> plot( f(x=5), (y, -10,10))

>>

>> plot( f(x=5,y=y), (y, -10,10))

>>

>> plot( f(5,None), (y, -10,10))

>>

>> plot( f(5,y), (y, -10,10))

>>

>> g(y) = f(5,y)

>> plot(g, (y, -10,10))

>> That last one seemed too verbose

>

>

> I guess you could also do:

>

> plot( lambda y: f(5,y), (y, -10,10))

>

> but then you give up things like fast_float.

>> plot( f(x=5), (y, -10,10))

>>

>> plot( f(x=5,y=y), (y, -10,10))

>>

>> plot( f(5,None), (y, -10,10))

>>

>> plot( f(5,y), (y, -10,10))

>>

>> g(y) = f(5,y)

>> plot(g, (y, -10,10))

>> That last one seemed too verbose

>

>

> I guess you could also do:

>

> plot( lambda y: f(5,y), (y, -10,10))

>

> but then you give up things like fast_float.

You didn't mention

plot(f(5,y).function(y), (y, -10,10))

which is the one that'd be compatible with non-callable expressions.

--Mike

Nov 7, 2008, 7:30:44 AM11/7/08

to sage-...@googlegroups.com

If symbolic expressions cease to be callable, plot would need to be

changed to handle these cases:

sage: plot( x^2 )

This seems plausible, since at the moment we allow

sage: plot( sin )

for usability.

Going back to your example, f(5,y) would just return a symbolic

expression, so

sage: f(x,y)=2*x+3*y

sage: plot( f(5,y), (y, -10,10))

would be equivalent to

sage: plot( 10+3*y, (y, -10,10))

which would just work.

The current syntax allows this:

sage: f(x,y) = a*x + b*y

sage: f(5)

b*y + 5*a

sage: f(5)(5)

b*y + 25

I think the last line should be a syntax error.

Cheers,

Burcin

Nov 7, 2008, 7:40:17 AM11/7/08

to sage-...@googlegroups.com

I agree, since f was explicitly defined with variables x and y.

f(5) should return a function g(y) = b*y+5*a

I think this could be easily changed (just return a function that has

explicit variables, rather than just a symbolic expression).

Jason

Nov 7, 2008, 7:53:56 AM11/7/08

to sage-...@googlegroups.com

I would still like to check that the length of the arguments match, and

raise an error if they don't. So, continuing the above example,

sage: f(5)

should raise an error.

It might be better if

sage: f(5, None)

or

sage: f(5,y)

returned the function g(y) = b*y+5*a.

Cheers,

Burcin

Nov 7, 2008, 8:46:04 AM11/7/08

to sage-...@googlegroups.com

I agree with both of those alternatives, and agree that it would be

better to insist that f take two arguments.

Jason

Nov 7, 2008, 9:07:02 AM11/7/08

to sage-devel

> >>> The current syntax allows this:

>

> >>> sage: f(x,y) = a*x + b*y

> >>> sage: f(5)

> >>> b*y + 5*a

> >>> sage: f(5)(5)

> >>> b*y + 25

>

> >>> I think the last line should be a syntax error.

>

> >> I agree, since f was explicitly defined with variables x and y.

>

> >> f(5) should return a function g(y) = b*y+5*a

>

> >> I think this could be easily changed (just return a function that has

> >> explicit variables, rather than just a symbolic expression).

>

> > I would still like to check that the length of the arguments match, and

> > raise an error if they don't. So, continuing the above example,

>

> > sage: f(5)

>

> > should raise an error.

>

> > It might be better if

>

> > sage: f(5, None)

>

> > or

>

> > sage: f(5,y)

>

> > returned the function g(y) = b*y+5*a.

>

> I agree with both of those alternatives, and agree that it would be

> better to insist that f take two arguments.

>

> Jason

more than one argument/variable, very much in the spirit of the (very

important and useful) compromise to have 'x' predefined as a variable

but none others.

If x^2 isn't callable, though, I might as well not use Sage in the

undergraduate classroom, or at least not ask any students to use it.

Well, maybe that's a stretch for me to claim? I'm not sure, honestly,

but ... it's just that computer mathematics systems are pedantic

enough as it is - for obvious reasons, but with too much of it I would

rather teach 1900-style and have them learn to visualize and compute

on their own (radical idea, I know!), since that also has a lot of

benefits pedagogically and mathematically. But I would really rather

have both.

Just my two cents.

- kcrisman

Nov 7, 2008, 10:23:50 AM11/7/08

to sage-...@googlegroups.com

kcrisman wrote:

>

>

> If x^2 isn't callable, though, I might as well not use Sage in the

> undergraduate classroom, or at least not ask any students to use it.

> Well, maybe that's a stretch for me to claim? I'm not sure, honestly,

> but ... it's just that computer mathematics systems are pedantic

> enough as it is - for obvious reasons, but with too much of it I would

> rather teach 1900-style and have them learn to visualize and compute

> on their own (radical idea, I know!), since that also has a lot of

> benefits pedagogically and mathematically. But I would really rather

> have both.

>

How would x^2 being callable help? Can you give a use case for showing

that x^2 being callable is much easier/simpler than without it being

callable?

I'm not saying it shouldn't be callable; I'm just asking for your opinion.

Jason

Nov 7, 2008, 12:58:21 PM11/7/08

to sage-devel

> How would x^2 being callable help? Can you give a use case for showing

> that x^2 being callable is much easier/simpler than without it being

> callable?

>

> I'm not saying it shouldn't be callable; I'm just asking for your opinion.

thread was suggesting that perhaps if f=x^2 then f(2) should be 2x^2,

not 4, and my understanding was that this was what it meant to not be

callable. Also it sounded like then plot(x^2,0,1) would have to be

plot(x^2,x,0,1) in that case. If I am mistaken, that's fine.

I feel like by letting f=x^2 be available instead of f(x)=x^2, we are

lowering the bar to use of Sage; the more conventions like this to

remember, the harder it is to use - not because people can't use it,

but because the frustration quotient (especially in a big class) is

high enough to drop it, since there are better things to do with one's

time than have to explain this sort of thing again and again. It

doesn't mean I personally would stop using Sage, just that I might not

use it as often as I would like in a class. However, I am glad it's

being discussed - it is interesting to learn about the different

reasons for such things.

The real issue is that someone who has the option of getting a site

license for something else (or using an existing one) might decide to

use that instead of Sage - not because of this per se, but because

they weigh "larger user base and program I am familiar with, even if

it has minor annoyances" or whatever against "various minor

annoyances, including this one, in program I'm not very familiar with"

- even if both programs have the same behavior, which I don't know

since I don't have the opportunity to use them.

So if the goal of Sage is to compete with them, which for now (and

hopefully in the future too!) may mean needing to be even better than

them, then part of that should be to allow things like this. It is a

minor annoyance to somebody either way, but it seems like this is a

case where it's a minor annoyance (as opposed to the major annoyance

of all letters being predefined as variables) for some, where the

other way would be a slightly more major annoyance for others. At

least, that's how I view it, both in my research and teaching. So

far, I think Sage has done a pretty good job balancing these things,

as someone else said earlier in the thread.

- kcrisman

Nov 7, 2008, 1:18:48 PM11/7/08

to sage-devel

Here's an idea that could make everyone happy. How about:

--symbolic expressions are not callable, the functional notation is

required,

--on startup, SAGE has defined x to be... the identity ! so it is

callable.

one would need to make sure that f(g) means composition of functions,

so that, say sin(x) is really the sine function; and x should perhaps

have its __str__ modified so it prints as "x" and not as "foo --> foo"

or whatever. But this is all easy to arrange.

this way we would have a strong and logical symbolic system, and one

"exception" with x which is helpful for newbies/students/etc. This

seems in the spirit of what we have already.

just a thought.

pierre

--symbolic expressions are not callable, the functional notation is

required,

--on startup, SAGE has defined x to be... the identity ! so it is

callable.

one would need to make sure that f(g) means composition of functions,

so that, say sin(x) is really the sine function; and x should perhaps

have its __str__ modified so it prints as "x" and not as "foo --> foo"

or whatever. But this is all easy to arrange.

this way we would have a strong and logical symbolic system, and one

"exception" with x which is helpful for newbies/students/etc. This

seems in the spirit of what we have already.

just a thought.

pierre

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

to sage-...@googlegroups.com

> Here are some

> possibilities:

>

>

>

> plot( f(x=5), (y, -10,10))

>

> plot( f(x=5,y=y), (y, -10,10))

>

> plot( f(5,None), (y, -10,10))

>

> plot( f(5,y), (y, -10,10))

>

> g(y) = f(5,y)

> plot(g, (y, -10,10))

> That last one seemed too verbose

>

> Jason

>

Personally I like allowing calls, but just using kwargs, like f(x=5),

forcing explicit variable naming, at the same time it would be a

convenience function for .subs(). That is unless f is declared as a

function like f(x) = x^3 because the declaration would imply variable

order.

If one wants to keep the convenience of using f(5) at least it would be

better to only allow one substitution for x, since x already has an

established status (if one wants it even more generic, allow only

single-variable functions). That way calling f(5,3) would raise an error

and force the user to explicitly order the variables.

Ronan Paixão

Nov 7, 2008, 3:14:57 PM11/7/08

to sage-devel

Hi all,

summarizing ideas and arguments from this thread gives the following

proposal:

Sage would benefit from the possibility to work in two different

modes, a "classroom mode", and a "pedantic mode".

In the classroom mode, e.g. symbolic expressions would be callable,

and quite some guessing would happen behind the scene. Since Wolfram

Research is likely to have spent (compared to the other players) most

resources in usability issues, the Sage classroom mode could be

modeled quite closely after what they do. And we will get the same

strange erronuous behaviour in certain cases as they do, and as was

mentioned above (mma mailing lists). Calling non-commutative rings

modules in Sage might just barf and refuse to work in classroom-mode.

In the pedantic mode, e.g. variables just have to be defined. All the

plot functions might have a considerably more complicated syntax. The

user would have more freedom to exactly tell what he wants Sage to do

for him. But the user also would have now the greater responsibility

inevitably linked to being granted more power.

As for the details, for the user interface it essentially boils down

to have verbose error messages. E.g. a plot function called in

"pedantic mode", but with "classroom mode" style parameters not just

saying "No", but telling the user "In classroom mode, this would work.

You are in pedantic mode, so you probably want to do <Code Snippet> to

get the same behaviour".

Technically, alas, this proposal would imply a good deal of work, and

a whole new dimension of complexity. We would need many, many tests

being doubled (one for each of the two modes), to mention only one of

several areas. The Sage project does not seem to have the necessary

developer resources, at least for the near future.

What do you think?

Cheers,

gsw

summarizing ideas and arguments from this thread gives the following

proposal:

Sage would benefit from the possibility to work in two different

modes, a "classroom mode", and a "pedantic mode".

In the classroom mode, e.g. symbolic expressions would be callable,

and quite some guessing would happen behind the scene. Since Wolfram

Research is likely to have spent (compared to the other players) most

resources in usability issues, the Sage classroom mode could be

modeled quite closely after what they do. And we will get the same

strange erronuous behaviour in certain cases as they do, and as was

mentioned above (mma mailing lists). Calling non-commutative rings

modules in Sage might just barf and refuse to work in classroom-mode.

In the pedantic mode, e.g. variables just have to be defined. All the

plot functions might have a considerably more complicated syntax. The

user would have more freedom to exactly tell what he wants Sage to do

for him. But the user also would have now the greater responsibility

inevitably linked to being granted more power.

As for the details, for the user interface it essentially boils down

to have verbose error messages. E.g. a plot function called in

"pedantic mode", but with "classroom mode" style parameters not just

saying "No", but telling the user "In classroom mode, this would work.

You are in pedantic mode, so you probably want to do <Code Snippet> to

get the same behaviour".

Technically, alas, this proposal would imply a good deal of work, and

a whole new dimension of complexity. We would need many, many tests

being doubled (one for each of the two modes), to mention only one of

several areas. The Sage project does not seem to have the necessary

developer resources, at least for the near future.

What do you think?

Cheers,

gsw

Nov 7, 2008, 3:25:48 PM11/7/08

to sage-devel

Ahh,

better call it "graduate mode" instead of "pedantic mode", at least in

the documentation.

:-)

Cheers,

gsw

better call it "graduate mode" instead of "pedantic mode", at least in

the documentation.

:-)

Cheers,

gsw

Nov 7, 2008, 3:38:34 PM11/7/08

to sage-...@googlegroups.com

Em Sex, 2008-11-07 às 12:25 -0800, Georg S. Weber escreveu:

> Ahh,

>

> better call it "graduate mode" instead of "pedantic mode", at least in

> the documentation.

>

> :-)

>

> Cheers,

> gsw

I'd prefer blue-pill mode and red-pill mode :)> Ahh,

>

> better call it "graduate mode" instead of "pedantic mode", at least in

> the documentation.

>

> :-)

>

> Cheers,

> gsw

Ronan

Nov 7, 2008, 8:41:22 PM11/7/08

to sage-...@googlegroups.com

On Nov 7, 2008, at 4:53 AM, Burcin Erocal wrote:

[...]

>>> Going back to your example, f(5,y) would just return a symbolic

>>> expression, so

>>>

>>> sage: f(x,y)=2*x+3*y

>>> sage: plot( f(5,y), (y, -10,10))

>>>

>>> would be equivalent to

>>>

>>> sage: plot( 10+3*y, (y, -10,10))

>>>

>>> which would just work.

>>>

>>> The current syntax allows this:

>>>

>>> sage: f(x,y) = a*x + b*y

>>> sage: f(5)

>>> b*y + 5*a

>>> sage: f(5)(5)

>>> b*y + 25

>>>

>>>

>>> I think the last line should be a syntax error.

>>

>>

>> I agree, since f was explicitly defined with variables x and y.

>>

>> f(5) should return a function g(y) = b*y+5*a

>>

>> I think this could be easily changed (just return a function that has

>> explicit variables, rather than just a symbolic expression).

>

> I would still like to check that the length of the arguments match,

> and

> raise an error if they don't. So, continuing the above example,

>

> sage: f(5)

>

> should raise an error.

I agree here.

> It might be better if

>

> sage: f(5, None)

This makes sense to me, but would be quite strange to the "average

calculus student" (where the average is over the the undergrads that

I have interacted with).

> or

>

> sage: f(5,y)

>

> returned the function g(y) = b*y+5*a.

What about f(5,a), would it be a function of a? Or f(y,5)? Or is

there somehow special casing going on when the variable name plugged

in matches the name of the expected argument (I'd rather let f(...)

have the same return type no matter what the arguments are).

I think this is *the* key point that needs to be addressed here. I

doubt people are going to avoid using Sage because symbolic

expressions are callable. However, I could see a lot of people

wondering why

sage: f = x^2

sage: f(2)

or

sage: plot(f, -10, 10)

does not work, and finding it easier to go with a system that "just

works" (for them) than worry about always distinguishing between

callable vs. non-callable expressions (or, worrying about teaching

such a distinction to their calculus 101 students).

It seems that the core objections are about Sage's automatic

resolution of ambiguity. When I write x=var(x); f = x^2, (almost) all

of us agree what f(2) should be. But if I write f = a*x^2, f(2) now

has additional ambiguity, and in particular the interpretation

"2*x^2" is arguably the "wrong" one (though reverse-alphabetic or

some other ordering is potentially just as bad and even more confusing).

I would propose that *single variable* expressions behave like

callables in one variable, there is no ambiguity as to the ordering,

so one should be able to call, integrate, differentiate, plot, etc.

with them without having to specify the variable. On trying to use a

expression with more than one indeterminate, an error should be

raised with a clear explanation the ambiguity and of how to define a

mulit-variate function. The f(x=5) syntax should still be available

as all ambiguity is resolved.

- Robert

Nov 10, 2008, 6:48:45 AM11/10/08

to sage-...@googlegroups.com

Robert Bradshaw wrote:

>

> [snip]

>

> I would propose that *single variable* expressions behave like

> callables in one variable, there is no ambiguity as to the ordering,

> so one should be able to call, integrate, differentiate, plot, etc.

> with them without having to specify the variable. On trying to use a

> expression with more than one indeterminate, an error should be

> raised with a clear explanation the ambiguity and of how to define a

> mulit-variate function. The f(x=5) syntax should still be available

> as all ambiguity is resolved.

>

> - Robert

>

>

>

I do not see any advantage in making implicit assumptions such as x is a

variable but a, y or whatever isn't or that the arguments of a callable

function are assigned to variables in alphabetic order. As a beginner, I

fell for Fortran's implicit assumptions and it took me ages to find out

that I need to put "implicit none" at the beginning of all my code.

Meaningful error messages are more helpful for everyone than solving

ambiguity by implicit assumptions that one has to remember in order to

understand what the program does.

The problem of losing beginners to other software packages only occurs

if they get lost, for example if the error message does not tell them

what to do in order to advance. *Or* if the program does something they

don't understand because it makes a different implicit assumption than

they would, but doesn't tell them. In my opinion, consistency is very

easy to get used to, while the attempt to guess what different people

mean will result in a hell of a lot of confusion and scare many people off.

These are just my 5 cents.

Stan

Reply all

Reply to author