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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/20230507024955.2cshjirge7s4fevx%40fricas.math.uni.wroc.pl.
