MR58: Bruhat iwahori tsb bruhat decompositions

[f588ca1e-f96a-4dea-804d-c55eab873dab]

This ticket corresponds to the Merge Request https://gitlab.com/sagemath/sage/-/merge_requests/58.

---

This ticket contains implementations for several decompositions: Bruhat_Iwahori, TSB and Bruhat (see description below). It was originally part of ​https://github.com/sagemath/sage-prod/issues/30690, which later became ​https://github.com/sagemath/sage-prod/issues/33404. In order to make the reviewing process easier, this ticket contains only some of the decompositions from the original ticket. The remaining decompositions (Iwasawa and Cartan) have been moved to another ticket (https://github.com/sagemath/sage-prod/issues/34026).

The ticket contains the following decompositions:

• Bruhat decomposition for square matrices over any field.
• Bruhat-Iwahori decomposition for square matrices over non-archimedean local fields.
• TSB decomposition (T - invertible upper-triangular, S - permutation matrix (possibly with some zero-rows), B - iwahori matrix), for square matrices over non-archimedean local fields.

Notes and Issues:

1. In the above decompositions, Some of the returned matrices could be defined over the integer-ring of the field, but I did not coerce them into the integer-ring, because of the bug described at: #29931.
2. To prevent any of the above decompositions from making changes to the original matrix, I relied on the fact that the matrix_over_field method returns a deep copy of the original matrix (even when the original is already defined over a field).
3. A point for consideration: as padics and formal laurent-series over finite fields are both non-archimedean local fields, I needed to make sure that the implemented methods work for both. Having a more uniform API for padics and laurent-series could be helpful in avoiding awkward nested functions that fit different implementations for each type. For example, for getting the unit-part of an element, I had to use the unit_part method for padics, and valuation_zero_part for laurent.

Component: linear algebra

Keywords: formal laurent series, decomposition

Author: n-vi

Branch/Commit: u/galois/mrs/58/bruhat_iwahori_tsb_bruhat_decompositions @ ac4c3e2

Issue created by migration from https://trac.sagemath.org/ticket/34027

[333767a0-8bb0-4499-a032-33e52572d678]

Description changed:

--- 
+++ 
@@ -1,4 +1,4 @@
-n-vi ([@n-vi](https://gitlab.com/sagemath/dev/tracmirror/n-vi)) opened a merge request at https://gitlab.com/sagemath/sage/-/merge_requests/58:
+This ticket corresponds to the Merge Request https://gitlab.com/sagemath/sage/-/merge_requests/58.

 ---

[333767a0-8bb0-4499-a032-33e52572d678]

comment:1

This ticket contains implementations for several decompositions: Bruhat_Iwahori, TSB and Bruhat (see description below).

It was originally part of https://github.com/sagemath/sage-prod/issues/30690, which later became https://github.com/sagemath/sage-prod/issues/33404. In order to make the reviewing process easier, this ticket contains only some of the decompositions from the original ticket. The remaining decompositions (Iwasawa and Cartan) have been moved to another ticket ().

The ticket contains the following decompositions:

• Bruhat decomposition for square matrices over any field.
• Bruhat-Iwahori decomposition for square matrices over non-archimedean local fields.
• TSB decomposition (T - invertible upper-triangular, S - permutation matrix (possibly with some zero-rows), B - iwahori matrix), for square matrices over non-archimedean local fields.

Notes and Issues:

1. In the above decompositions, Some of the returned matrices could be defined over the integer-ring of the field, but I did not coerce them into the integer-ring, because of the bug described at: #29931.
2. To prevent any of the above decompositions from making changes to the original matrix, I relied on the fact that the matrix_over_field method returns a deep copy of the original matrix (even when the original is already defined over a field).
3. A point for consideration: as padics and formal laurent-series over finite fields are both non-archimedean local fields, I needed to make sure that the implemented methods work for both. Having a more uniform API for padics and laurent-series could be helpful in avoiding awkward nested functions that fit different implementations for each type. For example, for getting the unit-part of an element, I had to use the unit_part method for padics, and valuation_zero_part for laurent.

[333767a0-8bb0-4499-a032-33e52572d678]

Changed keywords from none to formal laurent series, decomposition

[333767a0-8bb0-4499-a032-33e52572d678]

Description changed:

--- 
+++ 
@@ -2,9 +2,17 @@

 ---

+This ticket contains implementations for several decompositions: Bruhat_Iwahori, TSB and Bruhat (see description below).
+It was originally part of ​https://github.com/sagemath/sage-prod/issues/30690, which later became ​https://github.com/sagemath/sage-prod/issues/33404. In order to make the reviewing process easier, this ticket contains only some of the decompositions from the original ticket. The remaining decompositions (Iwasawa and Cartan) have been moved to another ticket (https://github.com/sagemath/sage-prod/issues/34026).

+The ticket contains the following decompositions:

+* Bruhat decomposition for square matrices over any field.
+* Bruhat-Iwahori decomposition for square matrices over non-archimedean local fields.
+* TSB decomposition (T - invertible upper-triangular, S - permutation matrix (possibly with some zero-rows), B - iwahori matrix), for square matrices over non-archimedean local fields.

+Notes and Issues:

-
-
+1. In the above decompositions, Some of the returned matrices could be defined over the integer-ring of the field, but I did not coerce them into the integer-ring, because of the bug described at: #29931.
+2. To prevent any of the above decompositions from making changes to the original matrix, I relied on the fact that the matrix_over_field method returns a deep copy of the original matrix (even when the original is already defined over a field).
+3. A point for consideration: as padics and formal laurent-series over finite fields are both non-archimedean local fields, I needed to make sure that the implemented methods work for both. Having a more uniform API for padics and laurent-series could be helpful in avoiding awkward nested functions that fit different implementations for each type. For example, for getting the unit-part of an element, I had to use the unit_part method for padics, and valuation_zero_part for laurent.