Prof. Dr. Johannes Grabmeier wrote:
>
> This is a good idea, many such inconsistencies are around and we should rea=
> lly work on that. Another example is inverting elements.
>
> In Monoid we have recip, in Group we have inv. For SquareMatrix we have an=
> additional
>
> if R has Field then inverse: % -> Union(%,"failed")
>
> which is really nonsense, as R being a field is not the criterium and we ha=
> ve to have case "failed" anyway. For domain Matrix we have the special prob=
> lem, that, as it is all embracing, not the right algebraic structures in ca=
> se one has a square matrix at hand, the user wants to invert it, if possibl=
> e, so he depends on coercion facilities, which in best case change the doma=
> in to be over Fraction Integer, although the result is over the integers ..=
> .=20
>
>
> (104) -> A := matrix [[1,2],[0,1]]
>
> +1 2+
> (104) | |
> +0 1+
> Type: Matrix(NonNegativeInteger)
> (105) -> recip A
>
> (105) "failed"
>
This is unfortunate choice of domain, since there is no inverse
with nonnegative entries. However:
(8) -> recip(A::Matrix(Integer))
(8) "failed"
Type: Union("failed",...)
is a bug, since inverse exists. Strictly speaking, we have:
(6) -> SquareMatrix(2, NonNegativeInteger) has unitsKnown
(6) false
Type: Boolean
so according to documentation 'recip' is allowed to return
useless result. But clearly, at least for IntegralDomain-s
we can do better.
> (106) -> inv A
> There are 4 exposed and 3 unexposed library operations named inv=20
> having 1 argument(s) but none was determined to be applicable.=20
> Use HyperDoc Browse, or issue
> )display op inv
> to learn more about the available operations. Perhaps=20
> package-calling the operation or using coercions on the arguments
> will allow you to apply the operation.
> =20
> Cannot find a definition or applicable library operation named inv=20
> with argument type(s)=20
> Matrix(NonNegativeInteger)
> =20
> Perhaps you should use "@" to indicate the required return type,=20
> or "$" to specify which version of the function you need.
> (106) -> inverse A
>
> +1 - 2+
> (106) | |
> +0 1 +
> Type: Union(Matrix(Fraction(Integer)),...)
In principle recip and inv are core operation, with 'inv' giving
error instead of "failed". Also 'inv' is only defined when
we expect non-invertiblity to be exceptional (that is for Group
and DivisionRing). At first glance inverse is redundant,
as recip should do the work. But 'recip' is only useful
when 'unitsKnown' are asserted. Looking at your
example I can guess another reason why it was done that way:
inverse forces coercion to a field which is what users typically
want when dealing with matrices.
>
> As a first step I have rewritten InnerMatrixLinearAlgebraFunctions to work =
> over a CommutativeRing, which I can provide, if required.
I am not sure if such extension should be done in
InnerMatrixLinearAlgebraFunctions or in a separate package,
but certainly ability to handle more general rings is
useful. Please, post your package.
--
Waldek Hebisch
[email protected]
--
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 post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
