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.
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-variable... for something that can be done in the notebook that might help your
use case.
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.
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.
kcrisman <kcris...@gmail.com> writes:
> 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.
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.
On 2012-05-11, Keshav Kini <keshav.k...@gmail.com> wrote:
> kcrisman <kcris...@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.
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.
> On 2012-05-11, Keshav Kini <keshav.k...@gmail.com> wrote:
> > kcrisman <kcris...@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.
Nils Bruin <nbr...@sfu.ca> writes:
> 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.
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.
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
On 11 May 2012 08:53, Keshav Kini <keshav.k...@gmail.com> wrote:
> Nils Bruin <nbr...@sfu.ca> writes:
>> 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.
> 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.
> -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+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org
> 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:
> --
> To post to this group, send an email to sage-devel@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+unsubscribe@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org
> Nils Bruin <nbr...@sfu.ca> writes:
> > 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.
> 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.
Well, Sage has many constituencies, and this discussion is quite old.
In Sage terms, REALLY old.
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?
On Friday, May 11, 2012 3:37:54 PM UTC+8, Snark wrote:
> Le Fri, 11 May 2012 07:16:35 +0000 (UTC), > Simon King <simon.k...@uni-jena.de> a écrit :
> > Hi,
> > On 2012-05-11, Keshav Kini <keshav.k...@gmail.com> wrote: > > > kcrisman <kcris...@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
This is a good idea IMHO. It helps the uninitiated slowly start getting acquainted without having to jump into the docs.
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?
> > 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.
> 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?
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.
> 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.
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 :-)
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.
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.
> 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-s...@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).
> > 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).
