Another idea:
when the interpreter uses coercions, why shouldn't we have same facility to use
retractions as far back to the original domain, as possible.
Mit freundlichen Grüßen
Johannes Grabmeier
Prof. Dr. Johannes Grabmeier
Köckstraße 1, D-94469 Deggendorf
Tel. +49-(0)-991-2979584, Tel. +49-(0)-151-681-70756
Tel. +49-(0)-991-3615-100 (d), Fax: +49-(0)-3224-192688
Am 05.05.2013 um 11:43 schrieb Prof. Dr. Johannes Grabmeier:
> This is a good idea, many such inconsistencies are around and we should
> really 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 have
> to have case "failed" anyway. For domain Matrix we have the special problem,
> that, as it is all embracing, not the right algebraic structures in case one
> has a square matrix at hand, the user wants to invert it, if possible, so he
> depends on coercion facilities, which in best case change the domain to be
> over Fraction Integer, although the result is over the integers ...
>
>
> (104) -> A := matrix [[1,2],[0,1]]
>
> +1 2+
> (104) | |
> +0 1+
> Type: Matrix(NonNegativeInteger)
> (105) -> recip A
>
> (105) "failed"
> Type: Union("failed",...)
> (106) -> inv A
> There are 4 exposed and 3 unexposed library operations named inv
> having 1 argument(s) but none was determined to be applicable.
> Use HyperDoc Browse, or issue
> )display op inv
> to learn more about the available operations. Perhaps
> package-calling the operation or using coercions on the arguments
> will allow you to apply the operation.
>
> Cannot find a definition or applicable library operation named inv
> with argument type(s)
> Matrix(NonNegativeInteger)
>
> Perhaps you should use "@" to indicate the required return type,
> or "$" to specify which version of the function you need.
> (106) -> inverse A
>
> +1 - 2+
> (106) | |
> +0 1 +
> Type: Union(Matrix(Fraction(Integer)),...)
>
>
>
> As a first step I have rewritten InnerMatrixLinearAlgebraFunctions to work
> over a CommutativeRing, which I can provide, if required.
>
> Mit freundlichen Grüßen
>
> Johannes Grabmeier
>
> Prof. Dr. Johannes Grabmeier
> Köckstraße 1, D-94469 Deggendorf
> Tel. +49-(0)-991-2979584, Tel. +49-(0)-151-681-70756
> Tel. +49-(0)-991-3615-100 (d), Fax: +49-(0)-3224-192688
>
> Am 05.05.2013 um 03:40 schrieb Waldek Hebisch:
>
>> I have noticed that we have inconsistent convention with
>> our solvers. In LinearSystemMatrixPackage we have
>> 'particularSolution' and 'solve' which gives both
>> particular solution and basis of the null space.
>> However, in LinearDependence we have 'solveLinear'
>> which corresponds to 'particularSolution' in
>> LinearSystemMatrixPackage. I think we should
>> rename current 'solveLinear' to 'particularSolution'
>> and add new 'solveLinear' corresponding to 'solve'.
>>
>> Also, LinearSystemMatrixPackage requires argument
>> to be a field, but it makes sense to have arguments
>> from IntegralDomain and solutions over field. This
>> is a frequent use case which would avoid conversion
>> on the user side.
>>
>> Additionaly, I wonder if it make sense to add
>> interface specially designed for rings, where
>> we return solution as a vector of numerators
>> and denominator. For null space we can choose
>> basis having coordinates from the ring...
>>
>> For PID-s we can find basis of null module (since
>> it is free), however this is somewhat different
>> than solving over quotient field.
>>
>> BTW. Over some rings in principle we can use modular
>> algorithms which produce solutions in form of
>> vector of numeratos and denomonator, so such
>> interface could spare four useless convertions
>> (to quotient field for using LinearSystemMatrixPackage,
>> from quotient field to ring for using modular solver,
>> from ring to quotient field to present result
>> in form LinearSystemMatrixPackage promises,
>> and computation of common denominator when
>> user needs result from in the ring).
>>
>> --
>> 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.
>>
>>
>
>
> --
> 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.
>
>
--
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.
