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.
In that case one could even allow block matrices of the following form
a11 :+ matrix [[1]]
a12 := matrix [[2],[3]]
a21 := matrix [[22,33,44]]
ass := matrix [[7]]
mat := matrix [[a11,a22],[a21,a22]]
That doesn´t look like what on usually considers a block matrix, but mat
would be an object that is perfectly fine to do mat + mat or 3*mat.
Multiplication mat*mat should fail due to incompatibilities as would
addiion of incompatible sizes. So we could introduce +: (%, %) -> % as a
partial function that gives an aborts the computation if the arguemnts
are incompatible.
I see this as good and bad.
I usually expect a function to be total, however, already / is a clear
exception and turning the signature of / into
(%, %) -> Union(%,"failed")
is clearly an overkill.
I would in this discussion rather restrict to Matrix and clearly define
what the mathematical structure is. For example, if arguments are
compatible, then addition is allowed and yields a result, if furthermore
the argument type of Matrix(X) is commutative/associative then so is the
addition of matrices. Etc, etc.
I have the impression that you have no problem going this way.
Well,
with "+" : (R, R) -> R
should be resonably good name for such type, but new word probably
is easier for compiler/interpreter.
Hmm... you probably started this thread not because the implementation
is problematic, but the interaction with other parts of FriCAS (in
particular the interpreter) is.
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.
For me coercion counts as embedding and that should never cause problems
if we even require that to be a homomorphism, but the interpreter also
applies convert and retract (as far as I understand) and that might not
give what the user wanted.
Clearly the type system is good for programming, but I admit that it is
a quite difficult task to guess the types that the user intended. That
the interpreter fails is no surprise. In fact, sometimes I would have
liked more control over the exposed domains.
Although probably unnatural for most users, I would be happy with a
session starting with zero knowledge where I would have to say "import
from Integer" before I can do 1+1.
Side remark: Yes, I would rather like "import from XXX" instead of
)expose XXX.
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).
Yes. Clear. Do you mean the problem is that setelt! is currently not
treated special? Or what exactly is the problem. Can you give an example?
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/33a2d71f-335e-2624-3b5a-8ce0794a5207%40hemmecke.org.
