On Sat, May 12, 2012 at 6:56 PM, kcrisman <kcris...@gmail.com> wrote:
>
>
> On May 12, 4:26 pm, Harald Schilly <harald.schi...@gmail.com> 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
>> > 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.
>
> 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 :)
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
--
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
