Nemocas
Make MatrixElem belong to AbstractArray{T, 2}
As our matrix types now no longer belong to Module (this turned out to be a bad idea), we could in theory make them members of Julia's AbstractArray class. This might be useful for various purposes.
Of course, some Julia functionality probably won't work because of zero and one not being defined for the (entry) element types, but it might make some things easier for both us and the Julia folks.
Sorry for this newbie question, but currently MatElem <: GroupElem, so do you mean to break that to inherit instead from AbtractMatrix ?
Also is there a specific reason we can't support zero and one? I just ran into this missing methods today.
Julia expects at various places to have zero working on the type. This does not work for us.
On our case the type does not determine the return value. Think of GF(2) and GF(3).
Julia expects at various places to have zero working on the type. This does not work for us.
Ah of course, thanks! My example was zero(fmpz) where this problem doesn't exist.
Sure, but I'm wondering if it is worth doing anyway, as most Julia people are coming to our system to use matrices over ZZ and QQ. I guess it could also be a motivation for them to clean up base so that it does zero(A[1, 1]) instead of zero(T), as we previously discussed with them.
Another thing we could do is define zero and one for the types. E.g. for Z/nZ we could return 0 in Z/1Z. This would provide further motivation for them to sort this out.
On Wed, Sep 25, 2019 at 05:45:29AM -0700, wbhart wrote:
Sure, but I'm wondering if it is worth doing anyway, as most Julia people are coming to our system to use matrices over ZZ and QQ. I guess it could also be a motivation for them to clean up base so that it does zero(A[1, 1]) instead of zero(T), as we previously discussed with them.
Does not work on empty matrices/ arrays...
-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/Nemocas/AbstractAlgebra.jl/issues/417#issuecomment-535004486
On Wed, Sep 25, 2019 at 05:47:19AM -0700, wbhart wrote:
Another thing we could do is define zero and one for the types. E.g. for Z/nZ we could return 0 in Z/1Z. This would provide further motivation for them to sort this out.
-- Do you really want "universal" zero and one for all types? AnticNumberField?
any operation then needs to checl if one/both/some input is zero or one and hope it makes sense. What is the trace of the universal 1? The degree of the parent?
You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/Nemocas/AbstractAlgebra.jl/issues/417#issuecomment-535005179
I am happy to add it for fmpq and fmpz and all element types with unique parents and throw errors for everything else :)
@thofma That's an even better idea.
@fieker The idea is they deal with that case separately, i.e. they should not need to create zero or one in such cases.
I'm adding the JuliaCommunity tag because this is an improvement that may be useful to the wider community, but not something that is high priority for us right now.