On Sat, May 13, 2023 at 04:37:08PM +0200, Ralf Hemmecke wrote: > 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.
Well, finding out exact specification for new functionality is important part of implementation. Clearly, we want to work with block matrices. But I want various parts to be as general as possible. And there is question of interaction/cooperation with existing features. > 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. That is not so clear: for addition it is enough to have compatible shapes. > 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. Of course when we generalize matrices (as opposed to creating something different) first step is to generalize MatrixCategory. > 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. Well, with "+" : (R, R) -> R should be resonably good name for such type, but new word probably is easier for compiler/interpreter. > 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. Yes. > > 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 *. Well, in the past you wrote "mathematical domains". I can imagine mathematical operations on Matrix(Symbol). And it would be natural for interpreter to convert Matrix(Symbol) to matrix of polynomials. > 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. Interpreter considers 'setelt!' to be two argument operation. Normally interpreter will coerce arguments to required types and function selection assumes that if argument types are coercible to needed type, then they are OK. But 'setelt!' is special, it works by side effect, so it must work on argument "as given" and can not coerce it to new type (which would create copy). > > 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 ? I have put the code (diff) at http://www.math.uni.wroc.pl/~hebisch/fricas/matmat.diff -- Waldek Hebisch -- 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/20230513204109.fk5tjqu5vxgzabct%40fricas.math.uni.wroc.pl.
