#11576: make it possible to generate sequences of variables easily
-------------------------------+--------------------------------------------
Reporter: kcrisman | Owner: burcin
Type: enhancement | Status: new
Priority: major | Milestone: sage-5.6
Component: symbolics | Resolution:
Keywords: Cernay2012 | Work issues:
Report Upstream: N/A | Reviewers:
Authors: | Merged in:
Dependencies: | Stopgaps:
-------------------------------+--------------------------------------------
Comment (by mjo):
Replying to [comment:10 kcrisman]:
> I like a lot of it. Obviously needs tests in the new class.
[[BR]]
I just updated the patch, each of the individual class methods now have
their own examples.
[[BR]]
> A few questions, which may betray ignorance:
> * Is it okay that we don't overwrite the global variables? I like that
in principle, but there is similar confusion at times with
!PolynomialRings that have an x which isn't in SR while `sage: x` still
returns the symbolic `x`. Just asking.
[[BR]]
Having two different `x`-things floating around -- one a python variable
and one a symbol name -- is a little bad, but clobbering them is in my
opinion worse. Essentially what I'm trying to do is make this act like
`SR.symbol()` instead of `SR.var()`.
The `symbol()` function leaves the variables alone:
{{{
sage: y = 7
sage: SR.symbol('y')
y
sage: y
7
}}}
Now there's a symbol floating around somewhere called `y`, but it isn't
the python variable. The alternative is, in my opinion, much worse:
{{{
sage: y = 7
sage: var('y')
y
sage: y
y
}}}
You could argue that people expect that from `var()` these days, but they
certainly wouldn't expect it from indexing some object. So this is what I
'''don't''' want:
{{{
sage: y1 = 7
sage: ys = SR.symbols('y')
sage: foo = ys[1]
sage: y1
y1
}}}
The user never even wrote 'y1' anywhere, so I think it's dangerous to
overwrite it.
[[BR]]
> * One thing I don't like, or need explanation for, is the confusion in
multi-index situations between the string (not LaTeX) reps of `x_{1}_{1}`
and `x_{11}`, which are apparently both `x11`. It's almost ''too''
flexible, because you don't have to say how many indices there will be
ahead of time - which is useful, of course, but there might have to be
something with the reps.
[[BR]]
You're right... my motivation was simply, "make it easy to create a bunch
of symbols," but I don't like this:
{{{
sage: a = SR.symbols('a')
sage: bool(a[11] == a[1,1])
True
}}}
The next-best thing I can think of is to use underscores, like the latex
representation. This makes everything a little uglier, but avoids the
ambiguity. Thoughts?
[[BR]]
> * Should `SymbolSequence` inherit from something?
[[BR]]
I dunno. I think this is the first standalone class I've written for the
sage library. Anyone know?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11576#comment:11>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
