Linear solvers

[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
heb...@math.uni.wroc.pl

[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

--
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...@googlegroups.com.
To post to this group, send email to fricas...@googlegroups.com.
Visit this group at http://groups.google.com/group/fricas-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Prof. Dr. Johannes Grabmeier]

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

[Ralf Hemmecke]

On 05/05/2013 11:43 AM, Prof. Dr. Johannes Grabmeier wrote:
> 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")

I agree and would call all these functions
inverse: % -> % and inverseIfCan: % -> Union(%,"failed").

But before I work more seriously on the library, I wait until the
"extend" keyword exists in SPAD. ;-)

Ralf

[Prof. Dr. Johannes Grabmeier]

>
>
> But before I work more seriously on the library, I wait until the
> "extend" keyword exists in SPAD. ;-)
>

Does anybody work on that?

[Ralf Hemmecke]

>> But before I work more seriously on the library, I wait until the
>> "extend" keyword exists in SPAD. ;-)

> Does anybody work on that?

I guess it's not one of Waldek's priorities. But otherwise the Aldor
compiler already has it. As far as I was told there are no legal issues
anymore releasing the Aldor compiler. It just doesn't happen. :-(

Ralf

[Bill Page]

On 2013-05-05 7:07 AM, "Ralf Hemmecke" <ra...@hemmecke.org> wrote:
> I was told there are no legal issues anymore releasing the Aldor compiler.

Does that mean that Aldor is no  longer restricted by the original license?  If so, what are we waiting for?

[Ralf Hemmecke]

> Does that mean that Aldor is no longer restricted by the original
> license?

Stephen told me in an IM in October last year that he got positive
permission from IBM and that he will put everything together to release
under Apache License 2.0 before the end of the year.

> If so, what are we waiting for?

For the official release.

Ralf

[Waldek Hebisch]

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
heb...@math.uni.wroc.pl

[Waldek Hebisch]

>
> 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.

I think we should try. Similar idea appeared to me when I looked
at resuls of comparisons:

(7) -> 2 = 3

(7) 2= 3
Type: Equation(PositiveInteger)

It makes sense to try to "simplify" them to Boolean values if
possible. However, such step should run only when interpreter
has results from algebra or user function and is going to
present it (in program code types should decide what is
needed).

However, only experiments can show if such facility is useful...

--
Waldek Hebisch
heb...@math.uni.wroc.pl