Extend meataxe to be able to detect invariant forms of reducible modules (just one possible form is returned)

[fingolfin]

No description provided.

[hulpke]

A main change seems a change from IsomorphismIrred to IsomorphismModules. What I want to make sure is that there will not be a chance of running in infinite recursion.

I have not looked again into the code of these two functions, but the former is a straightforward spinning algorithm, while the second is a rather elaborate calculation that uses a lot of other MeatAxe routines.
This means that with this change, InvariantXXXForm cannot be used within routines that might get called from IsomorphismModules. This means that the tests need to cover a variety of module structures (direct sums of multiple isomorphic and non-isomorphic indecomposable components).

[fingolfin]

Calls to MTX.Invariant*Form in GAP:

$ git grep -P -l '\.Invariant.*Form' grp lib
lib/meataxe.gi

So nothing outside of lib/meataxe.gi calls this.
Looking closer at those calls in lib/meataxe.gi:

• SMTX.InvariantQuadraticForm calls InvariantBilinearForm as a first step
• SMTX.OrthogonalSign calls MTX.InvariantBilinearForm and MTX.InvariantQuadraticForm
• however nothing in the library calls OrthogonalSign (only tests)

So all in all I don't see how this could cause a problem?

[fingolfin]

@ThomasBreuer @hulpke @jandebeule any ideas what the commented code above (inside SMTX.InvariantSesquilinearForm) is meant to be good for?

It looks to me like an attempt to "normalize" the isomorphism (and hence invariant form) we compute here). But the form can in fact be scaled by an arbitrary scalar (not just by a norm), so I don't understand why it we choose this specific one.

The reason I stumbled over this, and subsequently commented it out (to be deleted) is that it utterly fails if the given module is e.g. the sum of two isomorphic modules - then isot above in general won't be diagonal at all (test cases for that added below). On the other hand I can't really think of any reason why it would be useful. But I am sure whoever added this had a good reason, so I wonder what I am missing.

Any suggestions would be highly welcome!

[fingolfin]

@ThomasBreuer @hulpke @jandebeule any thoughts on this PR resp. my question above?

[ThomasBreuer]

No, I do not understand why this scaling happens, and which code may rely on it.

If we decide that this piece of code should get removed then also the line # Replace iso by a scalar multiple to get iso twisted symmetric above that code should get removed (and perhaps should now get another # in front of it).

[hulpke]

This got introduced after 4.B.1 and before 4.4.
I have no recall of implementing/committing it, but would not be surprised if I actually did the commit in the past, possibly with code from someone else (as the code formatting, and the long error message do not look as if I wrote it).
Alas this is amongst the commits that were deliberately not carried over when we moved to git.

[fingolfin]

I have a private git repository with the full commit history, and tracked the origin of the comment "Replace iso by a scalar multiple" to a commit made 2003-01-06 10:05:29 by @stevelinton with commit message "Derek Holt's code for Invariant forms."

So perhaps I should ask Derek about it...

[fingolfin]

Looking at this again I realize that of course this code is needed. Not sure why I was too dense to grasp it before: the reason why is right in this comment: to ensure we get a form which is twisted symmetric. I.e. the matrix M representing the isomorphism aka the form should satisfy $M = \overline{M}^T$.

Indeed in the code the matrix is called iso and that's it computes iso * isot^-1. If this is the identity, we are done. If it is a scalar matrix, we can hopefully scale M to satisfy the property, which is what the below does.

I'll restored the deleted code and add comments with details.

That then gets me back to the tests failing then, because now in the reducible case, iso * isot^-1 is not always diagonal. I did not yet look into the details, but surely this happens if there is a homogeneous reducible summand of the module, i.e., $A \oplus A$ -- then there are many automorphisms which are not "twisted symmetric". Gotta deal with that.

[fingolfin]

Here, too, we might get additional problems, i.e., iso may not be symmetric -- we ought to add a check for that.