kcrisman <kcris...@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"...
-Keshav
----
Join us in #sagemath on irc.freenode.net !
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
