Comment #17 on issue 1924 by smichr: Eq() gets .as_basic() method
http://code.google.com/p/sympy/issues/detail?id=1924
In thinking about the above statement "there's no reason for the members of
the equality to be Exprs, so the result may be something that's not an
Expr, or it could even be undefined."
That's true but that's also true about all containers. If I says
sympify(list) I am responsible for making sure it will understand what I
feed it. If I send Eq to solve I am resopnsible to make sure that when it
takes the L and R sides of it that it gets something that makes sense.
I thought of giving an "as_foo" method to the Tuple class but we could just
as well change the semantics of solve to be that if it receives a tuple
that it automatically interpret this as "(left, right)" of an expression.
But that is already used by to pass multiple equations (unless we make a
tuple the lhs, rhs and a list a list of equations or tuple pairs):
solve((x, 3*y), [x, y]) -> {x: [-3*y], y: [-x/3]}
solve([x, 3*y], [x, y]) -> {x: 0, y: 0}
This means solve is not polymorphic. The sender has to get the equation
into form before sending it.
Another alternative is to use the Tuple without a spacial method assugned
to pass the LR pairs:
solve(Tuple(x, 3*y), x) -> [3*y]
Do we agree that it is good to be able to send the LR pairs separately?
If so, we need to agree on a container with which to send them.
Should that container be tuple, Tuple or Eq?
If the container is an iterable class, should it have a method for
automatically rewriting itself?
--
You received this message because you are subscribed to the Google Groups
"sympy-issues" group.
To post to this group, send email to sympy-iss...@googlegroups.com.
To unsubscribe from this group, send email to
sympy-issues+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy-issues?hl=en.
