Groups of floats and matrices of floats

[Stefan-Kohl]

Groups of cyclotomics are not allowed in GAP due to the ambiguity between conjugation and exponentiation which would both be denoted by the operator ^. However groups of floats can be formed -- but they behave strangely:

gap> a := 2.0;; b := 3.0;;
gap> G := Group(a,b);
<group with 2 generators>
gap> IsAbelian(G);
true
gap> a^b = a;
false
gap> a^G;
2.^G
gap> Size(last);
( hangs ... )
gap> a in G;
true
gap> b in G;
true
gap> a*b in G;
( hangs ... )
gap> Size(G);
( hangs ... )
gap> a * One(G) = a;
false
gap> a * One(G);
0.
gap> One(G);
0.
gap> One(a);
1.
gap> Inverse(One(G)) = One(G);
false
gap> Inverse(One(G));
inf

[fingolfin]

We should prevent this. Operations on floats are not associative, after all.

[Stefan-Kohl]

There are similar issues with groups of matrices of floats -- e.g.:

gap> M := [[1.0,0.0],[0.0,1.0]];;
gap> Display(M);
[ [  1.,  0. ],
  [  0.,  1. ] ]
gap> IsMatrix(M);
true
gap> IsAbelian(H);
true
gap> Order(M);
1
gap> H := Group(M);
Group([ [ [ 1., 0. ], [ 0., 1. ] ] ])
gap> Size(H);
( hangs ... )
gap> M := [[2.0,0.0],[1.0,1.0]];
[ [ 2., 0. ], [ 1., 1. ] ]
gap> N := [[1.0,1.0],[0.0,1.0]];
[ [ 1., 1. ], [ 0., 1. ] ]
gap> M*(N*M) = (M*N)*M; # this is associative ...
true
gap> M^100*(N^-100*M^100) = (M^100*N^-100)*M^100; # ... this also ...
true
gap> M^1000*(N^-1000*M^1000) = (M^1000*N^-1000)*M^1000; # ... but this no more!
false

Rings and fields of floats are probably likewise not what one wants:

gap> Ring(1.0);
<ring with 1 generators>
gap> Ring(1.0) = Integers;
false
gap> Size(Ring(1.0));
( hangs ... )
gap> Field(1.0);
<algebra-with-one over Field( [ 1 ] )>
gap> Field(1.0) = Rationals;
false
gap> Characteristic(Field(1.0));
fail

[fingolfin]

Perhaps methods for GroupWithGenerators, DivisionRingByGenerators should get tighter filters, which IsMultiplicativeElementWithInverseCollection and IsAssociativeElementCollection (and maybe more) instead of just IsCollection ?

Or, if this leads to problems, they could test the elements accordingly... Hm

[fingolfin]

I have a fix for the group case, but for rings, the situations is more messy -- right now, our various ring constructors perform almost no validation on the given generators at all. Indeed, even IsRingElement is defined in weirdly broad way:

gap> IsRingElement;
<Category "((IsNearAdditiveElementWithInverse and IsAdditiveElement) and IsMultiplicativeElement)">
gap> IsRingElement(1.0);
true
gap> IsAssociativeElement(1.0);
false

Moreover, the reference manual chapter on Rings has this ominous remark:

Also, the SONATA package provides support for near-rings, and a related functionality for multiplicative semigroups of near-rings is available in the Smallsemi package.

This makes me wonder if rings and ring elements are defined so broadly for a (bad?) reason, i.e. to support functionality of some packages for near rings etc. ? Since dealing with associtivity (and commutativity of the additive group, etc.) for rings would require quite a bit more work than the group case did (and changes to many more function?), I skipped it for now.

Finally, note that this PR does not completely prevent the user from creating a group of floats: One can still use GroupWithGenerators for this purpose:

gap> GroupWithGenerators([1.0,2.0]);
<group with 2 generators>

The main reason I left it like that is that GroupWithGenerators currently performs virtually no input validation; this seems to be intentional?!

[fingolfin]

This was addressed in my pull request #1167, but so far nobody reviewed that.

[fingolfin]

Following a discussion on the gap mailing list, it seems the correct way to resolve this would be to disallow floats from forming groups, just like we do for cyclotomics.
See also https://mail.gap-system.org/pipermail/gap/2017-June/000946.html for a nice summary by Thomas Breuer of the discussion.

It seems the way to go is to install a method for IsGeneratorsOfMagmaWithInverses which excludes floats (supposedly, this is how we do it for cyclotomics, but I did not check).