Matrix usability issues

[lkastner]

Matrices in Oscar can be hard to use, especially when trying to interoperate with Julia matrices. This issue is for collecting those problems and then work out solutions, like adding to the interoperability layer or enhancing our docs. If you know of such an issue, please add a link or the details as a reply.

[lkastner]

I cannot multiply a ZZMatrix with a Julia matrix containing ZZRingElem.

ERROR: MethodError: no method matching *(::ZZMatrix, ::Matrix{ZZRingElem})

The second matrix is one I got when I called ones(ZZRingElem, *, *).

[lgoettgens]

nrows and ncols work for some subtypes of AbstractMatrix, e.g. Polymake.Matrix, but not for all.

[fingolfin]

Some notes from discussion in KL:

• we could provide methods for ones(ZZ, *, *) and zeroes(ZZ, *, *), etc.
• we could provide one for ones(ZZRingElem, *, *) but I think strictly speaking this would be type piracy?
• in general ones(SomeRingElemType, *, *) is not meaningful at all (as the type does not specify the ring)
• *(::ZZMatrix, ::Matrix{ZZRingElem}): what should the result be? I don't think we should support it. But we could install a dedicated method to print a more helpful error with instructions how to deal with it

[fingolfin]

nrows and ncols work for some subtypes of AbstractMatrix, e.g. Polymake.Matrix, but not for all.

We could provide methods nrows(m::AbstractMatrix) = size(m,1) and so on, in AbstractAlgebra. However, in the end this can't support our full matrix API...

A PR to AA would probably be merged?

[lgoettgens]

• we could provide one for ones(ZZRingElem, *, *) but I think strictly speaking this would be type piracy?

If implemented in Nemo, it wouldn't be type piracy, as Nemo owns ZZRingElem.

[lgoettgens]

nrows and ncols work for some subtypes of AbstractMatrix, e.g. Polymake.Matrix, but not for all.

We could provide methods nrows(m::AbstractMatrix) = size(m,1) and so on, in AbstractAlgebra. However, in the end this can't support our full matrix API...

A PR to AA would probably be merged?

See Nemocas/AbstractAlgebra.jl#1395. @thofma wasn't a fan of it. Thus I wanted to mention it here to get some other opinions.

[fingolfin]

OK, but there is no discussion on Nemocas/AbstractAlgebra.jl#1395 so maybe @thofma can briefly summarize what's problematic about it?

[thofma]

I discussed it privately with @lgoettgens:

Ok, ich mag es nicht, das Interface für AbstractMatrix halbherzig zu implementieren

I would prefer not to implement anything at all, because eventually we cannot implement even the simplest things (e.g. parent or base_ring). And I foresee endless issues of the form "why doesn't x work with y". And instead of trying to explain why the AbstractMatrix interface is absolutely useless, one always has to explain it awkwardly with (for the user) unsatisfactory explanations.

[fingolfin]

Brief update: ones(ZZRingElem, *, *) actually works and returns a Matrix{ZZRingElem} and we should not change that. Similar for zeros.

For ones(R, *, *) I just made Nemocas/AbstractAlgebra.jl#1886 -- as it turns out we already supported zeros(R, *, *).

We don't want to support multiplications of a mix of Julia and OSCAR matrices, as it is unclear how this should even be defined in general, e.g. what should the output be?

Beyond that I don't think it helps to have this issue open? If people encountered inconsistencies or have ideas for little convenience helpers, they most likely won't find this issue (or even search for it), it's easier to just open a new issue (or PR) for each idea?

[lkastner]

We don't want to support multiplications of a mix of Julia and OSCAR matrices, as it is unclear how this should even be defined in general, e.g. what should the output be?

We already support loads of interactions of our types with Julia types. E.g. the following works:

julia> M = matrix(QQ,[1 1;1 2])
[1   1]
[1   2]

julia> 2*M
[2   2]
[2   4]

This can also be viewed as a multiplication of a 2*Julia unit Int matrix with an OSCAR matrix. Basically all of our polynomials, module elements etc. can be multiplied with Julias Int. We can multiply OSCAR rationals with Julia rationals. We always made the choice that the return type is an OSCAR type. So why not have matrices do the same intuitive things whenever possible? Would make it easier on the user.

I am totally fine if you as PIs decide against this. But I do not agree with your argument.

Beyond that I don't think it helps to have this issue open? If people encountered inconsistencies or have ideas for little convenience helpers, they most likely won't find this issue (or even search for it), it's easier to just open a new issue (or PR) for each idea?

Fine with me.