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
33 matches
Mail list logo
