Hi Luis,
On 16 Dez., 20:12, luisfe <lftab...@yahoo.es> wrote:
> What does it mean 'deprecation'? Will this mean that at some point
>
> sage: var('x')
> sage: QQ[x]
>
> will be invalid code?
I think it should be invalid code.
Or, at least PolynomialRing(QQ,[singular]) should be invalid.
Currently, it yields a polynomial ring in variable Singular (upper
case). Similar for gap or any object in Sage whose string
representation can be interpreted as (comma separated list of)
variable names.
> sage: QQ['x']
>
> Is just unconfortable when you are creating several rings with
> variables with the same names.
OK, but in some doc tests one actually finds something like
sage: x,y,z = var('x y z')
sage: P = QQ[x,y,z]
Then,
sage: x,y,z = 'x','y','z'
sage: P = QQ[x,y,z]
is shorter and not less comfortable.
I mean, what's the point of defining a symbolic variable if the only
thing you want to do with it is creating a polynomial ring? Why taking
the risk of accidentally multiplying an element of P with one of these
symbolic variables, ending with something that is *not* in P:
# current behaviour:
sage: x,y,z=var('x y z')
sage: P = QQ[x,y,z]
sage: P.one()*x in P
False
> If this feature of current sage for creating QQ[x] makes people less
> like to try sage, ... I do not think
> that eliminating options in the language is a good option.
If this feature of current sage for creating QQ[x] makes beginners
more likely to create unexpected (for them) results such as "P.one()*x
not in P", therefore frustratedly dropping Sage soon after starting, I
*do* think eliminating that language option is a good option.
Cheers,
Simon
--
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
