Fix cardinality of special linear group

[RuchitJagodara]

• Fixed infinite recursion of the cardinality and order functions
• Improved pycodestyle
• Add more doctests to cover all cases

This patch fixes #36876 and fixes #35490. In this PR, I have implemented a method to fix the
answer given by cardinality function for finite special linear groups
(before it was going into infinite recursion). This also fixes the answer given by is_finite()
function for finite special linear groups.

📝 Checklist

• The title is concise, informative, and self-explanatory.
• The description explains in detail what this PR is about.
• I have linked a relevant issue or discussion.
• I have created tests covering the changes.

⌛ Dependencies

None

[RuchitJagodara]

@dimpase, @jukkakohonen and @videlec can you please review this PR ?

[mantepse]

Have you located the reason for the infinite recursion?

[RuchitJagodara]

Yes, the is_finite() function is calling this cardinality function, and it seems that it is calling the order function (Considering that other classes have their own order function). I didn't find any special function that calculates the cardinality of these special linear groups. So, maybe it is not implemented yet, so it is calling the order function of some class from which it is derived, but that function is calling back this cardinality function.

[dimpase]

Orders of special linear groups over fields are known, you can just implement formulae.

Less sure for more general cases

[RuchitJagodara]

Orders of special linear groups over fields are known, you can just implement formulae.

I checked and found that order function is implemented only for gap-based groups and there is only one function available for other groups which is going in infinite recursion. Here below is a example of a gap-based special linear group which is working perfect.

sage: F = FiniteField(3)
sage: SL(2,F).order()
24

But when it comes to other groups which are not gap-based then it is going in infinite recursion like below

sage: q = 7
....: FqT.<T> = GF(q)[]
....: N = T^2+1
....: FqTN = QuotientRing(FqT, N*FqT)
....: S = SL(2,FqTN)
....: S.order()
---------------------------------------------------------------------------
RecursionError                            Traceback (most recent call last)
...

This is happening because in below code it is first trying to make an object of LinearMatrixGroup_gap but if it fails then it is simply making an object of LinearMatrixGroup_generic and that class does not have properties of gap and because of that it is not able to calculate order/cardinality of the gorup.

sage/src/sage/groups/matrix_gps/linear.py

Lines 308 to 316 in 879ac37

	try:
	cmd = 'SL({0}, {1})'.format(degree, ring._gap_init_())
	return LinearMatrixGroup_gap(degree, ring, True, name, ltx, cmd,
	category=cat)
	except ValueError:
	pass
	return LinearMatrixGroup_generic(degree, ring, True, name, ltx,
	category=cat)

[mantepse]

But when it comes to other groups which are not gap-based then it is going in infinite recursion like below

sage: q = 7
....: FqT.<T> = GF(q)[]
....: N = T^2+1
....: FqTN = QuotientRing(FqT, N*FqT)
....: S = SL(2,FqTN)

Should we be able to iterate over such a group?

[dimpase]

There should be a special .order() method for SL. For finite fields $\mathbb{F}_q$ one has

$|SL(n,q)|={\frac{1}{q-1}} \Pi_{k=0}^{n-1} (q^n-q^k).$

Here FqTN is isomorphic to $\mathbb{F}_{49}$, so just use the forrmula, with $n=2$, $q=49$.

[RuchitJagodara]

I have implemented the order function for linear matrix groups. I discovered that GAP does not support linear matrix groups over the rational field (and some other fields), which was the main cause of the error. Consequently, I attempted to address this issue in GAP, but it proved to be very non-trivial. Therefore, I implemented the function in Sage. Additionally, I have another question: Why do we use functions from GAP when we can implement all of those functions from scratch in Sage as well? In this case, we would have the flexibility to construct functions according to our needs. I understand it may take considerable time, but we can proceed step by step. The same can be applied to Magma, which was also causing some errors, as can be found in the Discussion and in issue #36841.

[RuchitJagodara]

@dimpase and @mantepse, can you please review this pr...

[RuchitJagodara]

I have also included a documentation change in this pr only because it is a very small change. Is it okay ?

[github-actions]

Documentation preview for this PR (built with commit baa3b50; changes) is ready! 🎉

[mantepse]

Thank you!

[grhkm21]

This should be //.

[mantepse]

Possibly yes, but it doesn't look serious to me. Since this ticket is about to be merged, please open a new one!

[grhkm21]

Yes but also no, rational numbers behave weirdly, e.g. is_prime(7 / 1) is False. But I will open a new PR

[RuchitJagodara]

@grhkm21, have you made another PR for the changes you suggested? If not then, should I create a new PR for this?