Devel matrices #147
Devel matrices #147
Conversation
…e. Update all examples and remove the use of Tuple as an input
|
There's still a problem with the |
|
The # after simplifications, the expression can be reduced to 0 in some cases
# here's an example;
# if b is a Vector and u and v are scalar functions,
# we should have the following
# cross(b*u,b*v) = u*v*cross(b,b) = 0
if a == b:
return S.Zeroready to merge. |
| class Matrix(MatrixSymbolicExpr): | ||
| def __new__(cls, mat, *, name): |
There was a problem hiding this comment.
Looking at the code one more time, I find myself unsure about the necessity of giving a "name" to the class instances. This is not a purely symbolic class, but rather a container for symbolic objects. So why do we care about giving the objects a string name?
There was a problem hiding this comment.
In fact, both Vector and Matrix should be used in two different ways;
- as a container; like the
Tuple, but allow for algebraic operations, which is not the case ofTuple. In this case, we don't need them to have thenameattribute. - as a variable; like the
Constant, in which case, we'll be able to pass it as an argument when doing the assembly. This will make our code much more readable.
This means that the actual implementation needs improvements (addis_realoris_complexetc then update psydac).
So I suggest that we keep it this way, then we'll open an issue to make them work as variables.
| b1 = Vector([1, 2, 3], name='b1') | ||
| assert not b1 == b |
There was a problem hiding this comment.
See my previous comment. It is quite strange that by comparing two identical vectors the equality is not satisfied, because they have different names. Then what is the meaning of equality for this class?
There was a problem hiding this comment.
see my remark on the Matrix case.
This PR solves #145 issue.
In this PR, we introduce the objects
VectorandMatrix. They are meant to be immutable and only as an API for the user.All examples using
Tupleas an element of user expressions have been updated, and we should from now on, remove the use ofTupleas it not an algebraic object.Internally, we convert these new objects to
sympy, either through the objects methodto_sympy()or when evaluating symbolic expressions, for instance insideTerminalExpror mapping evaluation operators.