On Sun, May 14, 2023 at 12:26:20AM +0200, Ralf Hemmecke wrote:
> > 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.
With the patch I gave (after fixing typos) one can create 'mat' as
above. 'mat + mat' works. '3*mat' gives weird error, message is
rather confusing, but reason is simple: Matrix(Matrix(R)) has
multiplication by Matrix(R), but not by R...
> Multiplication mat*mat should fail due to incompatibilities as would addiion
> of incompatible sizes.
Yes.
> So we could introduce +: (%, %) -> % as a partial
> function that gives an aborts the computation if the arguemnts are
> incompatible.
Well, this already is the case, nothing really new here.
> 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.
Yes.
> 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.
My comment was about ArithmeticType.
> > 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.
The "best" which you can do ATM is
)set expose drop group basic
After that, given
vector([1, 2])
interpreter complains that it can not find exposed 'elt'. But
1 + 1
and
[1, 2]
still work, presumably due to hardcoded info.
> > > 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?
It is not treated special when selecting which operation to use.
Interpeter only realises that it is special when it should coerce
the first argument...
> Or what exactly is the problem. Can you give an example?
Example is from 'fixed.input':
msq := Matrix SquareMatrix(2,POLY INT)
m : msq := zero(2,2)
m(1,1) := matrix([[1,2],[a,b]])
--
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/20230514005149.xokdwopgzfoibspy%40fricas.math.uni.wroc.pl.
