Error in UnionOfRows

[zickgraf]

The following example throws an error:

julia> using MatricesForHomalg

julia> Q = HomalgFieldOfRationals();

julia> UnionOfRows( HomalgZeroMatrix( 5, 10, QQ ), HomalgIdentityMatrix( 10, QQ ), HomalgZeroMatrix( 5, 10, QQ ) )
ERROR: MethodError: Cannot `convert` an object of type 
  Vector{Rational{BigInt}} to an object of type 
  AbstractAlgebra.Generic.MatSpaceElem

Closest candidates are:
  convert(::Type{T}, ::T) where T
   @ Base Base.jl:84

Stacktrace:
 [1] UnionOfRows(R::AbstractAlgebra.Generic.MatSpaceElem{Rational{BigInt}}, nr_cols::AbstractAlgebra.Generic.MatSpaceElem{Rational{BigInt}}, list::AbstractAlgebra.Generic.MatSpaceElem{Rational{BigInt}})
   @ MatricesForHomalg ~/.julia/dev/MatricesForHomalg/src/MatricesForHomalg.jl:861
 [2] top-level scope
   @ REPL[3]:1

[mohamed-barakat]

Only the following is supported, also according to the documentation :)

UnionOfRows( QQ, 10, [ HomalgZeroMatrix( 5, 10, QQ ), HomalgIdentityMatrix( 10, QQ ), HomalgZeroMatrix( 5, 10, QQ ) ] )

[zickgraf]

I see, thanks! MatrixCategory and CategoryOfRows use UnionOfRows with three matrices. Should UnionOfRows with several matrices be discouraged, or shall I turn this issue into a feature request?

[mohamed-barakat]

MatrixCategory and CategoryOfRows use UnionOfRows with three matrices. Should UnionOfRows with several matrices be discouraged, or shall I turn this issue into a feature request?

I am for the former, since it carries more type information, something we generally encourage.

[mohamed-barakat]

Could this issue be closed?

[zickgraf]

I have not continued working on LinearAlgebraForCAP.jl, which is why this issue is still open. If we want to make porting code to Julia easy, the interfaces of MatricesForHomalg and MatricesForHomalg.jl should match as much as possible. If the interfaces differ, porting packages will always be a nuisance. That is, I suggest either implementing the convenience in MatricesForHomalg.jl or deprecating the convenience in MatricesForHomalg, if we want packages to be portable.

[zickgraf]

If the interfaces differ, porting packages will always be a nuisance.

I now experience this while porting ModulePresentationsForCAP: there are more than 30 occurrences of UnionOfRows and UnionOfColumns. Converting all of them is time-consuming and error-prone, so I will ignore those parts of the code for now.