Short answer: no.
Workaround: conceive some prefix to make a really unlikely name; something
like _my_internal_symbol_t_ or so.
Ameliorating circumstance: for the most part, symbolic variables are just
immutable place-holders, so it shouldn't matter who uses them. Probably the
most serious cas
On Sun, May 13, 2012 at 1:18 AM, Robert Bradshaw
wrote:
> On Sat, May 12, 2012 at 6:56 PM, kcrisman wrote:
>>
>>
>> On May 12, 4:26 pm, Harald Schilly wrote:
>>> On Thursday, May 10, 2012 5:28:38 PM UTC+2, 3DRaven wrote:
>>>
>>> > There is a suggestion to developers. The construction of
>>> > x
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
--
To post to this group, send an email to sage-devel@googlegroups.com
To un
On Sat, May 12, 2012 at 6:56 PM, kcrisman wrote:
>
>
> On May 12, 4:26 pm, Harald Schilly wrote:
>> 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 n
On May 12, 4:26 pm, Harald Schilly wrote:
> 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
> > uniniti
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 th
Hi,
On 2012-05-12, Michael Orlitzky 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 domai
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 oth
kcrisman 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 final
On May 11, 12:31 pm, Robert Bradshaw
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,
> > 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 m
On Fri, May 11, 2012 at 1:39 PM, Jason Grout
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 d
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
--
To post to this group, send an email
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 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 wrote:
> On May 11, 12:37 am, Julien Puydt wrote:
>
>> NameError: name 'y' is not defined -- perhaps you need to type var('y')
>> fir
On May 11, 12:37 am, Julien Puydt 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 n
Le vendredi 11 mai, Nils Bruin a écrit:
> On May 11, 10:29 am, kcrisman 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
On May 11, 10:29 am, kcrisman 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
On May 11, 10:27 am, Nils Bruin wrote:
> On May 11, 6:17 am, kcrisman 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 lin
> > 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 l
On May 11, 6:17 am, kcrisman 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
On Friday, May 11, 2012 3:37:54 PM UTC+8, Snark wrote:
>
> Le Fri, 11 May 2012 07:16:35 + (UTC),
> Simon King a écrit :
>
> > Hi,
> >
> > On 2012-05-11, Keshav Kini wrote:
> > > kcrisman writes:
> > >> To be clear, are you complaining about defining *only* x or that x
> > >> *is*, i
On May 11, 3:53 am, Keshav Kini wrote:
> Nils Bruin writes:
> > On May 11, 12:16 am, Simon King 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:
>
On 11 May 2012 09:32, Nils Bruin wrote:
> On May 11, 1:14 am, John Cremona 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:
>
On May 11, 1:14 am, John Cremona 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
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. = NumberField(x^3-2)
which means that when the doctest is run, there is an unnecessary
overhead involced sinc
Nils Bruin writes:
> On May 11, 12:16 am, Simon King 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 comma
Le Fri, 11 May 2012 07:16:35 + (UTC),
Simon King a écrit :
> Hi,
>
> On 2012-05-11, Keshav Kini wrote:
> > kcrisman 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
On May 11, 12:16 am, Simon King 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"
Hi,
On 2012-05-11, Keshav Kini wrote:
> kcrisman 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 pu
kcrisman writes:
> On May 10, 7:01 pm, Keshav Kini wrote:
>> kcrisman 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 whe
On May 10, 7:01 pm, Keshav Kini wrote:
> kcrisman 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. Yuc
kcrisman 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.freenod
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
On Jun 9, 2007, at 12:33 PM, William Stein wrote:
> I have another objection. If we "use the preparser to
> give constant literal implicit multiplication on the left", it
> is really strange an inconsistent when the same notation
> doesn't work for variables. E.g., in Mathematica putting
> two
On Jun 9, 2007, at 1:49 PM, [EMAIL PROTECTED] wrote:
> y only objection:
>>>
>>> 2x != x2
>>
>> I don't think anyone would usually write the latter (on paper or a
>> program).
>
> I use a variable named x2 quite frequently. Sometimes I want two
> variables named x -- so they get x1 and x2. So
y only objection:
>>
>> 2x != x2
>
> I don't think anyone would usually write the latter (on paper or a
> program).
I use a variable named x2 quite frequently. Sometimes I want two variables
named x -- so they get x1 and x2. Sometimes, I keep a copy of 2*x around so I
don't need to multiply a
On 6/9/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
\> >>> 2 x == x 2
> >>
> >> Another object:
> >>
> >> This breaks Python's 9390834L notation for long and our 392908340r
> >> notation
> >> for non preparsed.
> >
> > I also add an objection. It's hard enough for math folks to
> > remember the
On Jun 9, 2007, at 11:39 AM, Joel B. Mohler wrote:
> On Saturday 09 June 2007 13:40, William Stein wrote:
sage: 2x
2*x
sage: 10 x^2 - 3x + 2
10*x^2 - 3*x + 2
sage: 1.5(2+1)
4.5
sage: 21 degrees # from a possible future units package,
preparsed to
21
On Jun 9, 2007, at 10:40 AM, William Stein wrote:
> On 6/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>> On a different note (though related to the x(x+1) example), is there
>>> anyone else out there who likes the idea of using the preparser to
>>> give constant literal implicit multiplica
On Saturday 09 June 2007 13:40, William Stein wrote:
> > > sage: 2x
> > > 2*x
> > > sage: 10 x^2 - 3x + 2
> > > 10*x^2 - 3*x + 2
> > > sage: 1.5(2+1)
> > > 4.5
> > > sage: 21 degrees # from a possible future units package, preparsed to
> > > 21 * degrees
> > > 21 degrees
> >
> > My only objection:
On Jun 9, 2007, at 10:23 AM, [EMAIL PROTECTED] wrote:
>
>> On a different note (though related to the x(x+1) example), is there
>> anyone else out there who likes the idea of using the preparser to
>> give constant literal implicit multiplication on the left? E.g.
>>
>> sage: 2x
>> 2*x
>> sage: 1
On 6/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > On a different note (though related to the x(x+1) example), is there
> > anyone else out there who likes the idea of using the preparser to
> > give constant literal implicit multiplication on the left? E.g.
> >
> > sage: 2x
> > 2*x
> > s
> On a different note (though related to the x(x+1) example), is there
> anyone else out there who likes the idea of using the preparser to
> give constant literal implicit multiplication on the left? E.g.
>
> sage: 2x
> 2*x
> sage: 10 x^2 - 3x + 2
> 10*x^2 - 3*x + 2
> sage: 1.5(2+1)
> 4.5
> sage:
On Jun 7, 2007, at 10:46 AM, jason wrote:
> On Jun 7, 6:50 am, "William Stein" <[EMAIL PROTECTED]> wrote:
>> On 6/7/07, Iftikhar Burhanuddin <[EMAIL PROTECTED]> wrote:
>>
>> I do think it's an interesting example even if it is off topic.
>> It illustrates
>> one of the subtle potential points
On Jun 7, 6:50 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> On 6/7/07, Iftikhar Burhanuddin <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 7 Jun 2007, William Stein wrote:
> > > That's pretty amusing. What you're really doing is the following:
>
> > sage: version(); type(x(x-1)); x(x-1)
> > 'SAGE
OK, William's response clarifies things, and I would just modify my
comment to
suggest that predefining any single character variable is
questionable. I see that
ALL upper and lower case alphabetic characters are so defined.
I was thrown off by the definition of R (a ring to me), and am glad to
On 6/7/07, Iftikhar Burhanuddin <[EMAIL PROTECTED]> wrote:
> On Thu, 7 Jun 2007, William Stein wrote:
> > That's pretty amusing. What you're really doing is the following:
>
> sage: version(); type(x(x-1)); x(x-1)
> 'SAGE Version 2.3, Release Date: 2007-03-06'
>
> x - 1
>
> Regards,
> Ifti
>
> p
On Thu, 7 Jun 2007, William Stein wrote:
> That's pretty amusing. What you're really doing is the following:
Amusing indeed. Thanks for clearing that up.
I got confused because I obtained the following:
sage: version(); type(x(x-1)); x(x-1)
'SAGE Version 2.6, Release Date: 2007-06-02'
x - 1
On 6/7/07, Iftikhar Burhanuddin <[EMAIL PROTECTED]> wrote:
>
> I'm glad this topic has been broached.
>
> On March 27th, 2007, I noticed the following disturbing behavior when I
> forgot to insert a * between x and x-1.
>
> sage: x(x-1)
> x - 1
>
That's pretty amusing. What you're really doing
I'm glad this topic has been broached.
On March 27th, 2007, I noticed the following disturbing behavior when I
forgot to insert a * between x and x-1.
sage: x(x-1)
x - 1
Regards,
Ifti
ps:
(Apologies for not bringing it up earlier. I was writhing and writing my
dissertation and slinking on the
On 6/7/07, David Kohel <[EMAIL PROTECTED]> wrote:
> I suggest that this automatic construction is too permissive:
>
> sage: x
> x
> sage: type(x)
>
>
Just some clarification before this thread goes further.
This x above is *not* an automatic construction. I repeat,
the variable x is not automat
52 matches
Mail list logo