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
--------
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
>>
> 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
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
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
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
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
>
> >
>
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
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
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
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
>
> William Stein wrote:
>
>> Would you consider this weird if you read it in a paper, or
>> would you know how to interpret it?
>>
>> "Let $f = x^3 + x + 1$ and consider $f(10)$."
>
> I'm not so sure I know what to do with that.
I find this bizarre. I am absolutely certain that I want to view $f$
as a polynomial in one variable and evaluate it at 10.
I can think of lots of alternate ideas (evaluate everything to
bottom!) but I believe none of them are common. Can you cite a paper
that uses the notion of $x^3$ denoting the three-fold composition of a
function $x$ and considering $f = x^3$ and $f(10)$ intending the three-
fold composition of $x$?
Nick
John
2008/11/6 Nick Alexander <ncale...@gmail.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
--
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
> 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
> 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
>
> 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
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
>
>
> >
>
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
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
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
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
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
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
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
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
I agree with both of those alternatives, and agree that it would be
better to insist that f take two arguments.
Jason
> 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
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
Ronan
[...]
>>> 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
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