On Sunday, December 2, 2018 at 10:22:25 AM UTC-8, saad khalid wrote:
>
> I appreciate the help with solving my problem, though I do have some
> comments/questions to make with regard to usability for new users:
>
> Why can't matrices be allowed in SR in a nontrivial way?
>
>From a mathematical point of you, you DO want them to have different
parents: One generally first defines a ring (SR in this case) and THEN
considers the space of n-by-m matrices over that ring. It's very natural
for them to NOT have the same parent (e.g., a square matrix would have a
"determinant" method on it -- a method generally not available on SR
elements). Hence:
sage: M=matrix(2,2,[1,0,0,x])
sage: M.parent()
Full MatrixSpace of 2 by 2 dense matrices over Symbolic Ring
Many "symbolic" methods are now available on this object:
sage: M.variables()
(x,)
sage: M.simplify_trig()
[1 0]
[0 x]
but also matrix-specific ones, including some confusing ones:
sage: M.characteristic_polynomial()
x^2 + (-x - 1)*x + x
sage: M.characteristic_polynomial('t')
t^2 + (-x - 1)*t + x
(note the two different objects that print as "x" in the first expression)
To see the problem that arises from putting matrices into SR, consider for
instance
sage: A=matrix(2,2,[0,M,M,0])
sage: B=matrix(2,2,[0,SR(M),SR(M),0])
sage: parent(A)
Full MatrixSpace of 2 by 2 dense matrices over Full MatrixSpace of 2 by 2
dense matrices over Symbolic Ring
sage: parent(B)
Full MatrixSpace of 2 by 2 dense matrices over Symbolic Ring
Especially when you take into account that SR.is_commutative() == True, you
see that "B" has no chance of acting appropriately, whereas A would
(matrices over non-commutative rings haven't received much attention in
Sage yet, so I'd tread carefully, though).
Or, for some function H(s), why cant the behavior H(1) = H(s=1) be the
> default behavior?
>
sage: var('x,y')
(x, y)
sage: f=x+2*y
Should f(1) return "1+2y" or "x+2" ? It's abmiguous, and therefore
deprecated. Compare instead
sage: g=f.function(x)
sage: parent(g)
Callable function ring with argument x
Now it's completely clear what g(1) should return.
I guess my issue is that there doesn't seem to be a simple/consistent way
> to define a function that works, and I believe there should be. Mathematica
> manages this functionality somehow, what makes it difficult here? I am
> certainly a fan of using lambda functions, but iirc they are from python
> and are not inherently Sage/mathematical objects, right?
>
Sage is built on top of python, so there is nothing wrong with using python
constructs in sage. In fact. that's part of the design: It means that sage
didn't have to develop all usual programming language infrastructure. The
functionality provided by "symbolic function" that is not covered between
symbolic expressions and "lambda" functions is really quite limited. In
principle, "M.function(x)" could be implemented, returning a "Callable
matrix over SR with argument x", but there hasn't been suficient demand for
it.
The most compelling use for "callable expressions" comes from differential
operators, and doing that for vector-valued functions is quite a different
beast -- "sage manifolds" deals with that in a more general setting.
Lambda functions aren't the "suggested" way to make functions in the Sage
> tutorial. Perhaps it is just not known to me, but I would love for there to
> be some *simple* consistent standard with defining functions such that,
> if I define one in this way and try to plot it or plug in values with a
> certain notation, it will Always work and not give me something weird like
> this.
>
I'd think "lambda functions". There you know exactly what happens when you
plug something in, because you specify it!
> Does such a consistent notation exist that I haven't seen? The page "Some
> Common Issues with Functions" in the documentation essentially comments on
> the existence of this issue.
>
Indeed, that page addresses a lot of the issues. Whenever you run into a
question where "lambda functions" wouldn't do what you want (because of the
presence of matrices, for instance), there's a good chance that a "callable
expression" wouldn't do what you want either, because likely you're trying
to take a derivative or something like that, rather than just evaluate the
function.
These kinds of problems are fundamental to using a computer algebra system,
and different systems deal with them in different ways. This means that
there will be some differences between how "easily" certain tasks are
completed with different systems. Usually, once you get used to the gotchas
of a specific system (there always are!) it becomes easier to deal with
them.
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
