I can highly recommend creating a "tensor" package (see https://www.tensorflow.org/)
This has four advantages. Tensors are much more general than the matrix approach. The tensorflow package does just about anything and is an extremely flexible data structure. (see https://www.tensorflow.org/api_docs/python/tf) If you scroll down to the "Classes" section you can see how this would easily fit into the category/domain hierarchy. Tensors also form the basis for most of the GPT work. This might be of great benefit for future development. Tensors work well with GPUs, supporting more future development. The API and Class structures are already designed and widely used. Tim On Saturday, May 6, 2023 at 10:07:20 PM UTC-4 Waldek Hebisch wrote: > In mail from 4 Nov 2019 Johannes Grabmeier proposed extending > two dimensional arrays to work as matrices of matrices. > > I have looked at possible ways to obtain desired functionality. > One is to generalize Matrix to allow more general entries and > define arithmetic operations when needed operations are defined > in base domain. Another way is to define domain for "infinite" > matrices having only finitely many nonzero entries. Such > matrices with entries from a ring again form a ring (without unit, > that is our Rng), so "infinite" matrices would be acceptable as > base ring. For specific purpose another possibility is to > create domain of "block" matrices. > > 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. There were few similar cases > (involwing different operations). Spad compiler seem > to be managable and with workarounds build goes on OK. > > Interpreter problems are more troubling. First, after generalization > interpreter can generate Matrix(Symbol), which alone is positive > fact. Interpretes stronly prefers Variable or polynomials > compared to Symbol, but sometimes generates Matrix(Symbol) > in cases where previously we got Matrix(Polynomial(Integer)) > or some other "mathematical" domain. Trouble is, that > when trying to do arithmetic on Matrix(Symbol) interpeter > needs coercions and coerce code is buggy. For example, > during coercion interpreter invented SQMATRIX(2, Symbol) > which is invalid type (SQMATRIX still requires base > domain satisfying Join(SemiRng, AbelianMonoid)). And > interpeter tries to use multiplcation form such illegal > domain (probably because multiplcation from SQMATRIX > is exported unconditionally) leading to "System error". > In effect we get bunch of testsuite failures. In several > other tests we get different types, like > Matrix(PositiveInteger), which is sensible but may cause > confusion. Another example of confusions is message: > > The argument to the side-effect producing operation setelt! is not > allowed to be converted from type Matrix(SquareMatrix(2, > Polynomial(Integer))) to type Matrix(Matrix(Polynomial(Integer))) > . > > 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. > > Note: interpreter bugs are not new, but they are more visible > with new types. > > Anyway, currently IMO we can not commit this code, we need solution > to interpreter problems first. We probably could commit change > to MatrixCategory (which is large part of changes), but this is > of limited use. > > -- > 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/35c75b01-d9c4-4953-9b17-b065b9ea620an%40googlegroups.com.
