On 07.05.23 04:49, Waldek Hebisch wrote:
In mail from 4 Nov 2019 Johannes Grabmeier proposed extending
two dimensional arrays to work as matrices of matrices.
Link:
https://www.mail-archive.com/[email protected]/msg13038.html
I have looked at possible ways to obtain desired functionality.
I must admit that I did not completely understand what the expected
result should be. So my guess is that FriCAS should be able to work with
block matrices.
We already have Matrix. That allows any rectangular form of a matrix.
So from a naive point of view matrices can be entries of a "meta" matrix.
Of course, one wants to restrict the shapes of the entries so that the
result can be seen just as one matrix with a substructure.
And certainly, one can have matrices of matrices of matrices.
I actually see no big problem in implementing this, it is just that one
would have to take care of the compatibility of the + and * operations.
The only thing is that this new type constructor shouldn't be (as a
first approach) of type MatrixCategory, since this requires its entry
type to be an abelian monoid. If we do not require this, but only
require an operation +: (R, R) -> R that would be sufficient.
AFAIR Bronstein introduced a so-called ArithmeticType into the
Aldor-Library. that would be a + with no properties. No commutativity or
associativity. Also a bit quesionable, but an idea. For matrices, we
would even run into the problem that + is not defined for all input.
But that is also fine. The operation just fails for block matrices if
the dimensions of the blocks are not appropriate.
I have now mostly implemented the first possiblity, that is
generalization of Matrix. AFAICS generalized domain works
fine. However, it uncovered troubles with interpeter and
Spad compiler. Namely, Spad compiler has trouble with
condition like
if UP has zero? : UP -> Boolean then
where UP is domain parameter which satisfies
UnivariatePolynomialCategory(F) and F is UniqueFactorizationDomain.
This imples that conditon above is satisfies, but Spad
compiler can not infer this, so I had to add extra
conditionals as workarounds.
Oh yes, but that is only a weakness of the compiler and not the main
point why Matrix(Matrix Integer) shouldn´t be possible.
Interpreter problems are more troubling. First, after generalization
interpreter can generate Matrix(Symbol), which alone is positive
fact.
Hmmmm... then you see this different from me. Already in my first
reaction to Johannes' mail I spoke about data domains and arithmetic
domains. When I hear Matrix, I immediately think of being able to add or
multiply these structure. So a two dimensional array of Symbol shold be
ok, but I would require the input type of Matrix to at least provide +
and *.
But OK, if you are in favour of generalizing that requirement, I am not
completely against. Already no we require only AbelianMonoid, but no
multiplicative structure.
Apparently, with generalized matrices interpeter decided that
Matrix(Matrix(Polynomial(Integer))) would be good type. But
'setelt!' can not change type and interpeter has limited
capablitiy for backtracking, so instead of trying someting else
it produces error message.
Admittedly, an error message is not so nice, but as long as a user can
give the right types to the entries and then things work fine, I see no
problem.
In fact, I actually do not understand "setelt! cannot change type". What
exactly is the problem.
Anyway, currently IMO we can not commit this code, we need solution
to interpreter problems first.
Can you push the code to a new branch of *your* github fricas repo under
https://github.com/hebisch ?
Thanks
Ralf
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/62713c8d-9e84-1363-3564-8c8f6dd27add%40hemmecke.org.
