default behaviour of "SquareMatrix(n, FRAC INT) * INT"

[oldk1331]

The default behaviour of "SquareMatrix(n, FRAC INT) * INT"
is to treat the INT as DirectProduct and return DirectProduct:

y := [[1,2],[3,4]];
 

                                            Type: List(List(PositiveInteger))
y::SQMATRIX(2,FRAC INT)*1
 

   (2)  [3,7]
                                     Type: DirectProduct(2,Fraction(Integer))
y::SQMATRIX(2,INT)*1
 

        ┌1  2┐
   (3)  │    │
        └3  4┘
                                                Type: SquareMatrix(2,Integer)
y::SQMATRIX(2,FRAC INT)*(1::FRAC INT)
 

        ┌1  2┐
   (4)  │    │
        └3  4┘
                                      Type: SquareMatrix(2,Fraction(Integer))

This problem doesn't happen for Matrix FRAC INT.

I think this is a bug.

[Waldek Hebisch]

oldk1331 wrote:
>
> The default behaviour of "SquareMatrix(n, FRAC INT) * INT"
> is to treat the INT as DirectProduct and return DirectProduct:
>
> y := [[1,2],[3,4]];
>
>
> Type: List(List(PositiveInteger))
> y::SQMATRIX(2,FRAC INT)*1
>
>
> (2) [3,7]
> Type: DirectProduct(2,Fraction(Integer))

<snip>

> This problem doesn't happen for Matrix FRAC INT.
>
> I think this is a bug.

IIRC very similar problem was discussed in the past.
When types do not match exactly intepreter has to do
some coercions. Note that there is coercion from
INT (or more generally any ring R) into
direct product of R-s. Also, matrices acts on columns
and in case of SQMATRIX columns are of type DirectProduct.
Apparently interpreter decided to coerce first from Integer
to DirectProduct(2, Integer) and then from DirectProduct(2, Integer)
to DirectProduct(2, Fraction(Integer)). I am not sure why
interpreter prefered this to coercing from Integer to
Fraction(Integer) and using multiplication by scalar.

How to fix this? One way is to disable coercion from
Integer to DirectProduct. Another is to change type
of columns in SQMATRIX so to they no longer are DirectProduct-s.
Each may have unwanted consequences...

--
Waldek Hebisch

[oldk1331]

I'm a little confused: don't you think this is a bug in interpreter,
of the part doing automatic type lifting?  And should be fixed
there?

[Bill Page]

Including the line following

-- try to favor homogeneous multiplication

in i-funsel.boot

https://github.com/fricas/fricas/blob/master/src/interp/i-funsel.boot#L629

solves the problem since then apparently coercion to SQMATRIX is
favored. This seems intuitively reasonable but I was not able to find
any reference to why/when this hack was disabled. Perhaps it was an
experiment inherited with the original Axiom source?

> --
> 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 https://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.

[oldk1331]

> in i-funsel.boot
>
> https://github.com/fricas/fricas/blob/master/src/interp/i-funsel.boot#L629

That's an interesting finding, where the magic of priority of type
lifting is.

> Perhaps it was an
> experiment inherited with the original Axiom source?

At least not in the open source Axiom, I checked back to 2005, that line
was still commented.

[Bill Page]

There is some (very old) documentation here:

http://axiom-wiki.newsynthesis.org/public/refs/axiom-p56-sutor.pdf

and some experiments documented here:

http://axiom-wiki.newsynthesis.org/SandBoxInterpIFunselBoot

I think it might make sense to favor homogeneous operations in
(almost?) all cases. For example this code:

https://github.com/billpage/fricas/blob/funsel/src/interp/i-funsel.boot#L630

Both the original Axiom patch and this one cause a few minor
regressions in the result types. See for example

src/input/collect.input

in expressions like

[10^j for j in 0..3]

[reduce(+,[10^j for j in 0..i]) for i in 1..]

But in my opinion these changes could be considered desirable. Having
a more intuitive and easy to explain principle for function selection
in the interpreter is very desirable.

[Waldek Hebisch]

The bug is effect of interactions from several parts:

- declarations in algebra
- rules used in interpreter

Concerning interpreter: there is somewhat general method
but there is also several ad-hoc rules. General method
could be improved, in particular there are known cases
when interpreter can not find types, but in fact types
exist. OTOH I am not sure if changes to interpreter
are good fix for this: given declarations in algebra
current choice made by interpreter is defensible.

We could "fix" this problem by an ad-hoc rule in interpreter.
But I would very much prefer solution that is general.

--
Waldek Hebisch