Symbolic variables and uninitialized variables.

[3DRaven]

Hello! I do not speak English, use a translator.

There is a suggestion to developers. The construction of
x = var('x')
solve(x^2 + 3*x + 2, x)
is inconvenient and not beautiful. Can do whatever in the sage of any
uninitialized variable was considered a symbolic? Then there will be
enough to write
solve(x^2 + 3*x + 2, x), and he decides to Eq.

Have a nice day.

[kcrisman]

On May 10, 11:28 am, 3DRaven <3dra...@gmail.com> wrote:
> Hello! I do not speak English, use a translator.
>
> There is a suggestion to developers. The construction of
> x = var('x')
> solve(x^2 + 3*x + 2, x)

----------------------------------------------------------------------
| Sage Version 4.8, Release Date: 2012-01-20 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
sage: solve(x^2+3*x+2,x)
[x == -2, x == -1]
sage:

This only works for x, though.

> is inconvenient and not beautiful. Can do whatever in the sage of any
> uninitialized variable was considered a symbolic? Then there will be
> enough to write
> solve(x^2 + 3*x + 2, x), and he decides to Eq.

Unfortunately, this leads to things where typos could lead to answers
instead of errors. The compromise was to leave x as a predefined
variable, and no others. See http://ask.sagemath.org/question/559/how-to-magically-define-variables-and-use
for something that can be done in the notebook that might help your
use case.

- kcrisman

[Keshav Kini]

kcrisman <kcri...@gmail.com> writes:
> This only works for x, though.

I feel obligated to jump in here and say that this is one of the most
confusing and "not beautiful" things I've seen in Sage - and you run
into it almost immediately when learning the ropes. Yuck.

-Keshav

----
Join us in #sagemath on irc.freenode.net !

[kcrisman]

On May 10, 7:01 pm, Keshav Kini <keshav.k...@gmail.com> wrote:

> kcrisman <kcris...@gmail.com> writes:
> > This only works for x, though.
>
> I feel obligated to jump in here and say that this is one of the most
> confusing and "not beautiful" things I've seen in Sage - and you run
> into it almost immediately when learning the ropes. Yuck.
>

To be clear, are you complaining about defining *only* x or that x
*is*, in fact, predefined? In any case, this is a discussion we
probably don't need to rehash now, granted that there will never be
peace between the Python purists and Maple wannabes.

[Keshav Kini]

That x *is*, in fact, predefined. It misleads the user into expecting
that other variable names will also be predefined, whereas in fact they
are not.

FWIW I don't think it's feasible to implement Mathematica-style (or
Maple-style, I gather) "every undefined symbol is treated as a symbolic
atom rather than an error" behavior and still claim that Sage is
basically Python. That's too much of a modification. Though I like the
idea, it just doesn't seem to me to fit well with Sage, to me.

But regardless of which way we go, we should be consistent. Having one
seemingly arbitrary variable "x" be magically defined and others not is
really bad design, IMO.

[Simon King]

Hi,

On 2012-05-11, Keshav Kini <kesha...@gmail.com> wrote:

> kcrisman <kcri...@gmail.com> writes:
>> To be clear, are you complaining about defining *only* x or that x
>> *is*, in fact, predefined? In any case, this is a discussion we
>> probably don't need to rehash now, granted that there will never be
>> peace between the Python purists and Maple wannabes.
>
> That x *is*, in fact, predefined. It misleads the user into expecting
> that other variable names will also be predefined, whereas in fact they
> are not.

IIRC, the canonical answer to the request "do not predefine x" is:
"That's not gonna happen, because way too many people expect to have a
variable x handy."

Anyway.

I don't like pre-defining x either.

> FWIW I don't think it's feasible to implement Mathematica-style (or
> Maple-style, I gather) "every undefined symbol is treated as a symbolic
> atom rather than an error" behavior and still claim that Sage is
> basically Python. That's too much of a modification. Though I like the
> idea, it just doesn't seem to me to fit well with Sage, to me.

Isn't there such thing already, optionally? I don't know how it can be
switched on and would recommend against using it, but I recall that there is the
possibility to implicitly assume (in an interactive session, by
abuse/enhancement of the preparser) that all undefined variable names
refer to a symbolic variable.

Cheers,
Simon

[Nils Bruin]

On May 11, 12:16 am, Simon King <simon.k...@uni-jena.de> wrote:
> IIRC, the canonical answer to the request "do not predefine x" is:
> "That's not gonna happen, because way too many people expect to have a
> variable x handy."

Or perhaps:

"If you don't like x predefined, then put the command 'del x' in .sage/
init.sage".

While reasonable defaults are nice to have, it's even more important
to make it easy for people to tweak the setting to their liking -- and
it is easy.

[Julien Puydt]

Le Fri, 11 May 2012 07:16:35 +0000 (UTC),
Simon King <simon...@uni-jena.de> a écrit :

> Hi,
>
> On 2012-05-11, Keshav Kini <kesha...@gmail.com> wrote:
> > kcrisman <kcri...@gmail.com> writes:
> >> To be clear, are you complaining about defining *only* x or that x
> >> *is*, in fact, predefined? In any case, this is a discussion we
> >> probably don't need to rehash now, granted that there will never be
> >> peace between the Python purists and Maple wannabes.
> >
> > That x *is*, in fact, predefined. It misleads the user into
> > expecting that other variable names will also be predefined,
> > whereas in fact they are not.
>
> IIRC, the canonical answer to the request "do not predefine x" is:
> "That's not gonna happen, because way too many people expect to have a
> variable x handy."
>
> Anyway.
>
> I don't like pre-defining x either.

Would the following be possible -- instead of :
<<<
sage: y
---------------------------------------------------------------------------
NameError Traceback (most recent call
last)

/home/jpuydt/sage-5.0.beta14/<ipython console> in <module>()

NameError: name 'y' is not defined
>>>
have :
<<<
sage: y
---------------------------------------------------------------------------
NameError Traceback (most recent call
last)

/home/jpuydt/sage-5.0.beta14/<ipython console> in <module>()

NameError: name 'y' is not defined -- perhaps you need to type var('y')
first ?
>>>
?

That way sage still doesn't define things in the user's back, which
would cause problems, as already mentioned in this thread -- but
newcomers wouldn't get stuck needlessly either.

Snark on #sagemath

[Keshav Kini]

I think those two goals are sort of orthogonal. My objection to
predefining x is not because I personally find it annoying to have it
defined. Actually I find it useful too. It's the predefinition of x *as
a default* that bothers me, because of what it suggests about our
official system design specs. Conversely I'm sure you can imagine that I
have stuff in my init.sage which I would never argue for making a
default setting. So "If you don't like x predefined then get rid of it
in your init.sage" does not really address my complaint, I think.

Oh well.

Also in regards to your wording "reasonable defaults", I would point out
that defining x as a variable is not exactly a choice of a default for a
setting. Choosing to make n() output 53 bits of precision unless
otherwise specified is a default - it's a choice of one setting among
many possible choices, all of which are more or less equally plausible
to some extent. Choosing to make polynomials print in grevlex term order
is also a default. Predefining x as a symbolic variable, on the other
hand, is a bolt from the blue and not a default setting chosen among
similar other options. I think that makes it more reasonable to talk
about changing or removing it.

[John Cremona]

Maybe this is only a minor point, but having x predefined means that
in many doctests where a number field is needed (and there are a lot),
the doctest starts with something like

sage: K.<a> = NumberField(x^3-2)

which means that when the doctest is run, there is an unnecessary
overhead involced since x^3-2 is evaluated in the SR and then
converted to a polynomial (or somthing like that). I would be
interested to see how many doctests fail if the automattice
predefinition iof x is turned off. How might that be done?

John

> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org

[Nils Bruin]

On May 11, 1:14 am, John Cremona <john.crem...@gmail.com> wrote:
> I would be
> interested to see how many doctests fail if the automattice
> predefinition iof x is turned off.  How might that be done?

sage/all_cmdline.py
sage/all_notebook.py

both contain the line:

from sage.calculus.predefined import x


I'd expect that removing that and then running "make test" should give
you a nice list.

sage/all.py

contains a nice relic in this respect, by the way:

#x = PolynomialRing(QQ,'x').gen()

[John Cremona]

Now that's why I call "x" !

John

[kcrisman]

Well, Sage has many constituencies, and this discussion is quite old.
In Sage terms, REALLY old.

http://groups.google.com/group/sage-devel/browse_thread/thread/74a0aad809edd5c4/19fae110d7a2e970

Naturally, it's come back various times. For me, it comes down to
this:


sage: plot(x) # okay

sage: plot(y)
---------------------------------------------------------------------------

NameError: name 'y' is not defined

There should be at least one thing that a user who has never heard of
"variables" in computers can do without var or actually defining a
function.


sage: f(x) = x
sage: plot(f) # works but two liner to plot even the simplest non-
constant function


I've introduced this concept to probably hundreds of people in many
talks, workshops, and Joint Meetings discussions, and I have a strong
suspicion that dumping 'x' will lead to more dumps of Sage than you
think - by those who are not yet using it but are starting to finally
consider it. To be honest, the var('y') is already a hard sell,
though one I've learned to just barely justify to users. (For similar
reasons, I never understood why Maple required "with(plots)" or
something silly like that to plot; it doesn't take much marginal
effort required for a lot of people without CS background to figure
it's not worth it - see the iPhone for a product that understands
this.)

Notice that some people in the thread referenced above want us to
import nearly everything explicitly; well, that's probably what sage -
ipython is for, I suppose. Anyway, be careful what you wish for -
see Robert Bradshaw's comment in that thread about having to remember
which notebook cell defined a given thing. In the same thread, by the
way, the following is introduced by William.


$ export SAGE_IMPORTALL="no"
$ ../../sage
----------------------------------------------------------------------
| Sage Version 5.0.beta14, Release Date: 2012-04-27 |

| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------

**********************************************************************
* *
* Warning: this is a prerelease version, and it may be unstable. *
* *
**********************************************************************
sage: x
---------------------------------------------------------------------------
NameError: name 'x' is not defined

Presumably this could even be added as a command-line switch, like

$ sage --noimport

or something, and that would solve 99% of the problem for 'practical
CS-aware users'. Or?

- kcrisman

[P Purkayastha]

This is a good idea IMHO. It helps the uninitiated slowly start getting acquainted without having to jump into the docs. 

[Nils Bruin]

On May 11, 6:17 am, kcrisman <kcris...@gmail.com> wrote:
> There should be at least one thing that a user who has never heard of
> "variables" in computers can do without var or actually defining a
> function.
>
> sage: f(x) = x
> sage: plot(f)  # works but two liner to plot even the simplest non-
> constant function
>
> I've introduced this concept to probably hundreds of people in many
> talks, workshops, and Joint Meetings discussions, and I have a strong
> suspicion that dumping 'x' will lead to more dumps of Sage than you
> think - by those who are not yet using it but are starting to finally
> consider it.  To be honest, the var('y') is already a hard sell,
> though one I've learned to just barely justify to users.

Perhaps you can just tell them to use

sage: _(y)=y

instead then? That doesn't even need quotes!
then, by extension?

[kcrisman]

> > sage: f(x) = x
> > sage: plot(f)  # works but two liner to plot even the simplest non-
> > constant function
>
> > I've introduced this concept to probably hundreds of people in many
> > talks, workshops, and Joint Meetings discussions, and I have a strong
> > suspicion that dumping 'x' will lead to more dumps of Sage than you
> > think - by those who are not yet using it but are starting to finally
> > consider it.  To be honest, the var('y') is already a hard sell,
> > though one I've learned to just barely justify to users.
>
> Perhaps you can just tell them to use
>
>   sage: _(y)=y

I thought underscore only worked to give the previous command, but I
guess the preparser makes this work right.

> instead then? That doesn't even need quotes!
> then, by extension?

Well, opaque commands aren't necessarily a better sell :-)

More seriously, then they might as well do f(y) = y, even if they
later redefine f, and at least that has the advantage of being
intelligible.

[Andrey Novoseltsev]

And who can understand what does it mean???

[Nils Bruin]

On May 11, 10:29 am, kcrisman <kcris...@gmail.com> wrote:
>> sage: _(y)=y
> I thought underscore only worked to give the previous command, but I
> guess the preparser makes this work right.

No, as far as I can tell, _ is an ordinary variable for python. It's
just that the toplevel assigns the latest return value to it, if that
value is not None. I don't think you could make the preparser do this
for you if Python, IPython or the notebook didn't.

I didn't mean it as a serious suggestion.

[Julien Puydt]

Le vendredi 11 mai, Nils Bruin a écrit:

Thanks for clarifying ; the fact that it was a joke was at the top spot
in my interpretation list, but there was still a shadow of doubt :-)

Snark on #sagemath

[Nils Bruin]

On May 11, 12:37 am, Julien Puydt <julien.pu...@laposte.net> wrote:

> NameError: name 'y' is not defined -- perhaps you need to type var('y')
> first ?

A nice idea, but I don't think NameError is sufficiently aware of the
context it is raised in to make reliable suggestions:

sage: sinus(pi/3)
NameError: name 'sinus' is not defined -- perhaps you need to type
var('sinus') first?
sage: var('sinus')
sage: sinus(pi/3)
[Deprecation warning]
1/3*pi
sage: sinus(pi/3)
1/3*pi

Following the advice indeed makes the error go away, but likely
doesn't produce the result the user intended.

Also, I'm afraid NameError gets raised somewhere in the innards of
Python, so to implement this idea we probably would need to patch
Python.

[Robert Bradshaw]

I should not that all single-case letters used to be defined, and I
for one was often bitten by this in strange ways.

On Fri, May 11, 2012 at 11:13 AM, Nils Bruin <nbr...@sfu.ca> wrote:
> On May 11, 12:37 am, Julien Puydt <julien.pu...@laposte.net> wrote:
>
>> NameError: name 'y' is not defined -- perhaps you need to type var('y')
>> first ?
>
> A nice idea, but I don't think NameError is sufficiently aware of the
> context it is raised in to make reliable suggestions:
>
> sage: sinus(pi/3)
> NameError: name 'sinus' is not defined --  perhaps you need to type
> var('sinus') first?
> sage: var('sinus')
> sage: sinus(pi/3)
> [Deprecation warning]
> 1/3*pi
> sage: sinus(pi/3)
> 1/3*pi
>
> Following the advice indeed makes the error go away, but likely
> doesn't produce the result the user intended.

When the declaration warning becomes an error, it will be a bit
better. Certainly an argument for not making all undefined symbols
into symbolic variables. One can write SR("a*x+b") and it defines the
variables for you (though not globally IIRC).

> Also, I'm afraid NameError gets raised somewhere in the innards of
> Python, so to implement this idea we probably would need to patch
> Python.

I bet we could catch this and re-throw a modified version; we have
hooks into the read-eval-print loop to do preparsing, for example.

- Robert

[Jason Grout]

On 5/11/12 2:31 PM, Robert Bradshaw wrote:

> When the declaration warning becomes an error, it will be a bit
> better. Certainly an argument for not making all undefined symbols
> into symbolic variables. One can write SR("a*x+b") and it defines the
> variables for you (though not globally IIRC).
>
>> Also, I'm afraid NameError gets raised somewhere in the innards of
>> Python, so to implement this idea we probably would need to patch
>> Python.
>
> I bet we could catch this and re-throw a modified version; we have
> hooks into the read-eval-print loop to do preparsing, for example.

Changing the NameError assumes that the user wants a symbolic variable.
There is a *lot* more to Sage than symbolic variables, and I would
guess that in many people's typical code, symbolic variables play little
or no part.

How does Matlab handle this? You also have to declare symbolic
variables there, IIRC.

Jason

[John H Palmieri]

On Friday, May 11, 2012 12:31:55 PM UTC-7, Robert Bradshaw wrote:

I should not that all single-case letters used to be defined, and I
for one was often bitten by this in strange ways.

Wow. Even "n" and "i"? I'm glad that was changed.

--
John

[Robert Bradshaw]

On Fri, May 11, 2012 at 1:39 PM, Jason Grout
<jason...@creativetrax.com> wrote:
> On 5/11/12 2:31 PM, Robert Bradshaw wrote:
>
>> When the declaration warning becomes an error, it will be a bit
>> better. Certainly an argument for not making all undefined symbols
>> into symbolic variables. One can write SR("a*x+b") and it defines the
>> variables for you (though not globally IIRC).
>>
>>> Also, I'm afraid NameError gets raised somewhere in the innards of
>>> Python, so to implement this idea we probably would need to patch
>>> Python.
>>
>>
>> I bet we could catch this and re-throw a modified version; we have
>> hooks into the read-eval-print loop to do preparsing, for example.
>
> Changing the NameError assumes that the user wants a symbolic variable.
>  There is a *lot* more to Sage than symbolic variables, and I would guess
> that in many people's typical code, symbolic variables play little or no
> part.

Oh, I agree. I certainly fall into that boat. But it may be worth a
suggestion 'cause the people that want/expect a symbolic variable are
(guessing) likely to be in large overlap with those who would be
mystified by the raw NameError. This should probably be in an
easy-to-locate FAQ as well (if it's not as well).

- Robert

[kcrisman]

> > Changing the NameError assumes that the user wants a symbolic variable.
> >  There is a *lot* more to Sage than symbolic variables, and I would guess
> > that in many people's typical code, symbolic variables play little or no
> > part.
>
> Oh, I agree. I certainly fall into that boat. But it may be worth a
> suggestion 'cause the people that want/expect a symbolic variable are
> (guessing) likely to be in large overlap with those who would be
> mystified by the raw NameError. This should probably be in an
> easy-to-locate FAQ as well (if it's not as well).

Maybe the command giving rise to the NameError could be parsed
(naively, of course) for things like "plot", "integra{tl}", etc. and
in those cases give the extra message; I agree that even I don't want
that extra message for generic typos I make (the vast majority of my
NameErrors, and probably others' as well).

- kcrisman

[Nils Bruin]

On May 11, 12:31 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:

> One can write SR("a*x+b") and it defines the
> variables for you (though not globally IIRC).

Thanks! That is very good to know. So SR has its own parser! It even
works for SR("f(t)"). It doesn't do the expected thing for
SR("diff(sin(x),x)"), though, so care should be taken.

The error SR("integrate(sin(x),x)") produces versus the result of
SR("integral(sin(x),x)") puzzles me.

By the way, I would have expected slightly more rigour from you.
SR(...) doesn't "define variables". It creates the symbolic variable
objects (I guess you could call that "defining variables"), but it
does not inject bindings into the global Python namespace.

[Keshav Kini]

kcrisman <kcri...@gmail.com> writes:
> I've introduced this concept to probably hundreds of people in many
> talks, workshops, and Joint Meetings discussions, and I have a strong
> suspicion that dumping 'x' will lead to more dumps of Sage than you
> think - by those who are not yet using it but are starting to finally
> consider it. To be honest, the var('y') is already a hard sell,
> though one I've learned to just barely justify to users.

I cannot imagine how this exchange:

A: So how do I make a plot?
B: Try "var('x') ; plot(x^2, (x, 0, 2))"
A: What's the "var('x')" about?
B: We're defining x as a symbolic variable so we can use it in
symbolic expressions such as "x^2" which are left uncomputed until
a value is substituted in (such as during plotting the graph of
x^2). Compare with, say, "3^2" where you get out "9" immediately.
A: Cool, now how do I make an implicit plot?
B: Try "var('y') ; implicit_plot(x^2 == y^3, (x, -5, 5), (y, -5, 5))"
A: You don't need "var('x')"?
B: No, because we already defined x as a symbolic expression earlier.
If you want to "undefine" it, just do "del x"
A: OK.

is supposed to be more off-putting to a newbie than this one:

A: So how do I make a plot?
B: Try "plot(x^2, (x, 0, 2))"
A: Cool, now how do I make an implicit plot?
B: Try "var('y') ; implicit_plot(x^2 == y^3, (x, -5, 5), (y, -5, 5))"
A: Why do you have to write "var('y')" first here? You didn't write
"var('x')", even though we used x as well. And you didn't even
write it when we used x earlier, either.
B: We're defining y as a symbolic variable so we can use it in
symbolic expressions such as "y^3" which are left uncomputed until
a value is substituted in (such as during plotting the graph of x^2
== y^3). Compare with, say, "3^2 == 2^3" where you get out "False"
immediately. x was already defined as a symbolic variable for you
so you wouldn't have to encounter this var() business until you
needed more than one variable name for something.
A: Uh, well I guess I'm glad I happened to ask you about implicit
plots, then...

The latter conversation is an approximation of one that I had about five
times near the beginning of our semester-long Sage class for
undergraduates last fall, and which I'm sure other tutors for the class
must have gone through as well with other students. While I might be
underestimating the number of people who would drop Sage because of
needing to type var('x'), I suspect you may be underestimating the
number of people who dump Sage when they find out about var('y') once
they get home, and realize they've been duped! :P

> Notice that some people in the thread referenced above want us to
> import nearly everything explicitly; well, that's probably what sage -
> ipython is for, I suppose. Anyway, be careful what you wish for -
> see Robert Bradshaw's comment in that thread about having to remember
> which notebook cell defined a given thing. In the same thread, by the
> way, the following is introduced by William.
>
>
> $ export SAGE_IMPORTALL="no"
> $ ../../sage
> ----------------------------------------------------------------------
> | Sage Version 5.0.beta14, Release Date: 2012-04-27 |
> | Type notebook() for the GUI, and license() for information. |
> ----------------------------------------------------------------------
> **********************************************************************
> * *
> * Warning: this is a prerelease version, and it may be unstable. *
> * *
> **********************************************************************
> sage: x
> ---------------------------------------------------------------------------
> NameError: name 'x' is not defined
>
> Presumably this could even be added as a command-line switch, like
>
> $ sage --noimport
>
> or something, and that would solve 99% of the problem for 'practical
> CS-aware users'. Or?

This has nothing to do with having functions available in the global
namespace at Sage startup. Functions are individual things which exist
somewhere in the Sage library, whereas symbolic variables are created by
the user in order to be used in symbolic expressions. The only thing
which is somewhat similar to this is the inclusion of constants like pi
in the default namespace, but at least that's justified because there is
no simple way to input the exact value of pi. I am perfectly fine with
most of the default items in the starting namespace. x is one exception.

And in any case, as I explained to Nils above, telling me to run
something like `sage --noimport` is besides the point because I'm
complaining about the *defaults*. I personally like to have x defined as
a symbolic variable when I start up Sage. But I don't think that that is
what a newbie should see. In particular I don't buy this argument:

> There should be at least one thing that a user who has never heard of
> "variables" in computers can do without var or actually defining a
> function.

People who are able to do one thing should also be able to do another
thing which logically extends from the first one instead of running into
a wall. If you cannot logically reason about how a software system works
without running into caveats, loopholes, and weird behavior constantly,
it means that it is not a well-designed software system.

And we certainly ran into caveats, loopholes, and weird behavior quite
frequently during our undergraduate Sage course, this business about x
being one example. At least most of the others were bugs, many of which
are solved and all or most of which have been put on trac, but this one
is apparently a "feature"...

[Michael Orlitzky]

On 05/12/2012 08:19 AM, Keshav Kini wrote:
>
> The latter conversation is an approximation of one that I had about five
> times near the beginning of our semester-long Sage class for
> undergraduates last fall, and which I'm sure other tutors for the class
> must have gone through as well with other students. While I might be
> underestimating the number of people who would drop Sage because of
> needing to type var('x'), I suspect you may be underestimating the
> number of people who dump Sage when they find out about var('y') once
> they get home, and realize they've been duped! :P
>

(Hijacking because I deleted the rest of the thread)

I agree that having 'x' predefined is convenient, but think that
consistency is better in the long run.

I often open up a sage prompt while I'm writing python code just to see
if some idea I had will work at all. I usually do something stupid like,

sage: p = plot(x,x,0,1)
sage: p.<tab>

just to see the methods on a plot. It's nice having 'x' predefined
there, but of course that would be fine in init.sage.

On the other hand, almost all of the examples I saw when I started using
sage relied on the predefined 'x'. It took me years to figure out all of
the different ways to declare symbolic variables (or even to realize
that there was a better way to create polynomials than by using the
default 'x').

If there was no predefined 'x', the first documentation you would run
into would (have to) tell you how to define symbolic variables, and
explain the differences between the methods. It could also explain the
polynomial thing, the different domains, etc. In the long run (I'm
thinking weeks, here), it will have been better to have learned that at
the beginning.

[Simon King]

Hi,

On 2012-05-12, Michael Orlitzky <mic...@orlitzky.com> wrote:
> If there was no predefined 'x', the first documentation you would run
> into would (have to) tell you how to define symbolic variables, and
> explain the differences between the methods. It could also explain the
> polynomial thing, the different domains, etc. In the long run (I'm
> thinking weeks, here), it will have been better to have learned that at
> the beginning.

+1, although I doubt that +1 would have any effect here.

Cheers,
Simon

[Harald Schilly]

On Thursday, May 10, 2012 5:28:38 PM UTC+2, 3DRaven wrote:

There is a suggestion to developers. The construction of
x = var('x')
solve(x^2 + 3*x + 2, x)
is inconvenient and not beautiful. Can do whatever in the sage of any
uninitialized variable was considered a symbolic?

in the notebook (and only there), you can execute

automatic_names(True)

once. Then, it does what you want.

The remaining discussion about x vs. y is just a good example that Sage is not 100% pure - as Kini would like :)

It is also influenced by a tradeoff for general usability.

H

h

 

[kcrisman]

Exactly. To take Keshav's idea, I'm okay with "duping" people with
multivariable functions in this way; it seems like the same thing, but
in practice I've found that people who make it beyond the first few
things to try in Sage are already hooked enough that this seems much
less onerous. Certainly no less so than the "dot" notation, though
I'm hesitant to do the automatic_names thing too much due to typo
proliferation.

Actually, I think it's silly that we have to declare variables for
said plots, provided that we require variables in the ranges in that
case. So, on startup, why couldn't

sage: implicit_plot(x == y^2, (x,-1,1), (y,-1,1), color='puce')

work? Must be a way to preparse that. If there was a list of
specific places where it's very annoying to do this and they could all
be preparsed away (since the "f(x) = ..." notation solves a lot of
those problems), it might be possible to get rid of 'x'; however, it
seems more worth maintaining a pretty reasonable concession which has
lasted for nearly all of Sage's existence outside of the number theory
world, which is only really troubling to people who definitely have
the skills to bypass it :)

[Robert Bradshaw]

And even in the "number theory world" it's handy to have at least one
indeterminate right away, e.g. for defining number fields. Sage is
pragmatic, not always pure.

- Robert

[Harald Schilly]

On Sunday, May 13, 2012 3:56:32 AM UTC+2, kcrisman wrote:

Actually, I think it's silly that we have to declare variables for
said plots,

Personally, I'm happy with having y and z predefined, just like x is. 

H 

[William Stein]

Much of number theory is *very* one-dimensional, so having exactly one
variable makes good sense to (some of) us number theorists.

William

>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org