Remove trailing spaces (thofma#382)

This reflects the settings in `.editorconfig`: due to those, whenever I open and edit a file in Hecke.jl, as a side effect all trailing spaces are removed, which unnecessarily blows up my commits (or I have to manually remove those changes again). So, let's get rid of them in one swoop now; new ones should hopefully not be added as long as everyone uses an editor which honors `.editorconfig`.
HechtiDerLachs · Aug 18, 2021 · 0a50220 · 0a50220
1 parent 6463533
commit 0a50220
Show file tree

Hide file tree

Showing 295 changed files with 2,814 additions and 2,814 deletions.
diff --git a/README.md b/README.md
@@ -18,7 +18,7 @@ Hecke is part of the [OSCAR](https://oscar.computeralgebra.de/) project and the
 - <https://thofma.github.io/Hecke.jl/dev/> (Online documentation)
 
 So far, Hecke provides the following features:
-  
+
   - Number fields (absolute, relative, simple and non-simple)
   - Orders and ideals in number fields
   - Class and unit group computations of orders
@@ -72,16 +72,16 @@ Here is a quick example of using Hecke:
 julia> using Hecke
 ...
 
-Welcome to 
+Welcome to
 
-  _    _           _        
- | |  | |         | |       
- | |__| | ___  ___| | _____ 
+  _    _           _
+ | |  | |         | |
+ | |__| | ___  ___| | _____
  |  __  |/ _ \/ __| |/ / _ \
  | |  | |  __/ (__|   <  __/
  |_|  |_|\___|\___|_|\_\___|
-  
-Version 0.10.12... 
+
+Version 0.10.12...
  ... which comes with absolutely no warrant whatsoever
 (c) 2015-2019 by Claus Fieker, Tommy Hofmann and Carlo Sircana
 
@@ -90,7 +90,7 @@ julia> f = x^3 + 2;
 julia> K, a = NumberField(f, "a");
 julia> O = maximal_order(K);
 julia> O
-Maximal order of Number field over Rational Field with defining polynomial x^3 + 2 
+Maximal order of Number field over Rational Field with defining polynomial x^3 + 2
 with basis [1,a,a^2]
 ```
 

diff --git a/TODO.md b/TODO.md
@@ -10,7 +10,7 @@
  * [ ] implement Montes--Nart algorithm
  * [ ] composite Dedekind criterion
  * [ ] composite Round Two algorithm
- * [ ] implement information about containment (O_1 \sub O_2) 
+ * [ ] implement information about containment (O_1 \sub O_2)
  * [ ] save prime factors of discriminant
  * [x] `princ_gen` should be cached
  * [ ] Clean up uniformizer (p-uniformizer? strong uniformizer?)
@@ -37,13 +37,13 @@
  * [ ] `coeff(z, i)` and `coefficients(z)` "inconsistencies"
 
  ## Renaming
- 
+
  * [x] `DiagonalGroup` and `AbelianGroup` to `abelian_group`.
  * [x] `princ_gen` to `principal_generator`
  * [ ] `nf` to `number_field`
  * [x] Group algebra renaming
  * [ ] Make `has*` and `*_known` consistent.
-  
+
  ## Misc
  * [ ] `exp_map_unit_grp_mod`
  * [ ] `charpoly` should have `parent = ` keyword.

diff --git a/deps/_build.jl b/deps/_build.jl
@@ -3,7 +3,7 @@ using Pkg, Nemo, Libdl
 oldwdir = pwd()
 
 nemo_pkgdir = joinpath(dirname(pathof(Nemo)), "..")
-#nemo_pkgdir = Pkg.dir("Nemo") 
+#nemo_pkgdir = Pkg.dir("Nemo")
 nemo_wdir = joinpath(nemo_pkgdir, "deps")
 nemo_vdir = joinpath(nemo_pkgdir, "local")
 

diff --git a/deps/hecke/Makefile.in b/deps/hecke/Makefile.in
@@ -14,11 +14,11 @@ AT=@
 BUILD_DIRS = antic \
    $(EXTRA_BUILD_DIRS)
 
-TEMPLATE_DIRS = 
+TEMPLATE_DIRS =
 
 export
 
-SOURCES = 
+SOURCES =
 LIB_SOURCES = $(wildcard $(patsubst %, %/*.c, $(BUILD_DIRS)))  $(patsubst %, %/*.c, $(TEMPLATE_DIRS))
 
 HEADERS = $(patsubst %, %.h, $(BUILD_DIRS))

diff --git a/deps/hecke/configure b/deps/hecke/configure
@@ -375,20 +375,20 @@ case "$OS" in
       ;;
    *)
       ;;
-esac 
+esac
 
 #test for popcnt flag and set needed CFLAGS
 
 mkdir -p build
 rm -f build/test-popcnt > /dev/null 2>&1
 MSG="Testing __builtin_popcountl..."
 printf "%s" "$MSG"
-echo "int main(int argc, char ** argv) { 
+echo "int main(int argc, char ** argv) {
 #if defined(_WIN64)
 return __builtin_popcountll(argc) == 100;
 #else
 return __builtin_popcountl(argc) == 100;
-#endif 
+#endif
 }" > build/test-popcnt.c
 $CC build/test-popcnt.c -o ./build/test-popcnt > /dev/null 2>&1
 if [ $? -eq 0 ]; then

diff --git a/docs/src/FacElem.md b/docs/src/FacElem.md
@@ -15,29 +15,29 @@ products of smaller elements, allowing the computer to handle them.
 Mathematically, one can think of factored elements to formally
 live in the ring $Z[K]$ the group ring of the non-zero field
 elements. Thus elements are of the form $ \prod a_i^{e_i}$ where
-$a_i$ are elements in $K$, typically _small_ and the $e_i\in Z$ are frequently 
-large exponents. We refer to the $a_i$ as the *base* and the $e_i$ as the 
+$a_i$ are elements in $K$, typically _small_ and the $e_i\in Z$ are frequently
+large exponents. We refer to the $a_i$ as the *base* and the $e_i$ as the
 *exponents* of the factored element.
 
 Since $K$ is, in general, no PID, this presentation
 is non-unique, elements in this form can easily be multiplied, raised
 to large powers, but in general not compared and not added.
 
-In Hecke, this is caputured more generally by the type `FacElem`, 
-parametrized by the type of the elements in the base and the type of their 
+In Hecke, this is caputured more generally by the type `FacElem`,
+parametrized by the type of the elements in the base and the type of their
 parent.
 
 Important special cases are
  * ```FacElem{fmpz, FlintIntegerRing}```, factored integers
  * ```FacElem{nf_elem, AnticNumberField}```, factored algerbaic numbers
  * ```FacElem{NfAbsOrdIdl, NfAbsOrdIdlSet}```, factored ideals
 
-It should be noted that an object of type ```FacElem{fmpz, FlintIntegerRing}`` 
+It should be noted that an object of type ```FacElem{fmpz, FlintIntegerRing}``
 will, in general, not represent an integer as the exponents can be
 negative.
 
-## Construction 
-In general one can define factored elements by giving 2 arrays, the 
+## Construction
+In general one can define factored elements by giving 2 arrays, the
 base and the exponent, or a dictionary containing the pairs:
 
 ```@docs

diff --git a/docs/src/abelian/elements.md b/docs/src/abelian/elements.md
@@ -40,5 +40,5 @@ G = abelian_group(fmpz[1 2; 3 4])
 for g = G
   println(g)
 end
-``` 
+```
 
diff --git a/docs/src/abelian/maps.md b/docs/src/abelian/maps.md
@@ -4,7 +4,7 @@ and can be created in a variety of situations.
 ## Maps
 Maps between abelian groups can be constructed via
  - images of the generators
- - pairs of elements 
+ - pairs of elements
  - via composition
  - and isomorphism/ inclusion testing
 

diff --git a/docs/src/abelian/structural.md b/docs/src/abelian/structural.md
@@ -62,7 +62,7 @@ quo(G::GrpAbFinGen, n::fmpz)
 quo(G::GrpAbFinGen, U::GrpAbFinGen)
 ```
 
-For 2 subgroups `U` and `V` of the same group `G`, `U+V` returns 
+For 2 subgroups `U` and `V` of the same group `G`, `U+V` returns
 the smallest subgroup of `G` containing both. Similarly, $U\cap V$
 computes the intersection and `U \subset V` tests for inclusion.
 The difference between `issubset =` $\subset$ and

diff --git a/docs/src/class_fields/intro.md b/docs/src/class_fields/intro.md
@@ -101,10 +101,10 @@ maximal_abelian_subfield(K::NfRel{nf_elem})
 ## Invariants
 ```@docs
 degree(C::ClassField)
-base_ring(A::Hecke.ClassField) 
-base_field(A::Hecke.ClassField) 
+base_ring(A::Hecke.ClassField)
+base_field(A::Hecke.ClassField)
 discriminant(C::Hecke.ClassField)
-conductor(C::Hecke.ClassField) 
+conductor(C::Hecke.ClassField)
 defining_modulus(C::ClassField)
 iscyclic(C::ClassField)
 isconductor(C::Hecke.ClassField, m::NfOrdIdl, inf_plc::Vector{InfPlc})
@@ -122,7 +122,7 @@ prime_decomposition_type(C::Hecke.ClassField, p::Hecke.NfAbsOrdIdl)
 Hecke.issubfield(a::ClassField, b::ClassField)
 Hecke.islocal_norm(r::Hecke.ClassField, a::Hecke.NfAbsOrdElem)
 Hecke.islocal_norm(r::Hecke.ClassField, a::Hecke.NfAbsOrdElem, p::Hecke.NfAbsOrdIdl)
-Hecke.normal_closure(r::Hecke.ClassField) 
+Hecke.normal_closure(r::Hecke.ClassField)
 subfields(r::ClassField)
 subfields(r::ClassField, d::Int)
 ```

diff --git a/docs/src/function_fields/elements.md b/docs/src/function_fields/elements.md
@@ -5,5 +5,5 @@ CurrentModule = Hecke
 ```
 
 For details on element arithmetic in rational function fields and extensions, refer
-to the AbstractAlgebra documentation which can be found at 
+to the AbstractAlgebra documentation which can be found at
 [https://nemocas.github.io/AbstractAlgebra.jl/latest/function_field/](https://nemocas.github.io/AbstractAlgebra.jl/latest/function_field/).
diff --git a/docs/src/function_fields/intro.md b/docs/src/function_fields/intro.md
@@ -6,7 +6,7 @@ CurrentModule = Hecke
 
 ## [Introduction](@id FunctionFieldsLink)
 
-By definition, a (univariate) function field can be written as a finite extension of a rational 
+By definition, a (univariate) function field can be written as a finite extension of a rational
 function field $k(x)$ for a field $k$ (commonly $k = \mathbb{Q}$ or $k = \mathbb{F}_p$).
 In Hecke, a function field $L$ is currently defined as being a (univariate) rational function
 field $k(x)$ or a finite extension thereof. In other words, the extension

diff --git a/docs/src/index.md b/docs/src/index.md
@@ -44,16 +44,16 @@ Here is a quick example of using Hecke:
 julia> using Hecke
 ...
 
-Welcome to 
+Welcome to
 
-  _    _           _        
- | |  | |         | |       
- | |__| | ___  ___| | _____ 
+  _    _           _
+ | |  | |         | |
+ | |__| | ___  ___| | _____
  |  __  |/ _ \/ __| |/ / _ \
  | |  | |  __/ (__|   <  __/
  |_|  |_|\___|\___|_|\_\___|
-  
-Version 0.9.0 ... 
+
+Version 0.9.0 ...
  ... which comes with absolutely no warranty whatsoever
 (c) 2015-2018 by Claus Fieker, Tommy Hofmann and Carlo Sircana
 
@@ -62,7 +62,7 @@ julia> f = x^3 + 2;
 julia> K, a = NumberField(f, "a");
 julia> O = maximal_order(K);
 julia> O
-Maximal order of Number field over Rational Field with defining polynomial x^3 + 2 
+Maximal order of Number field over Rational Field with defining polynomial x^3 + 2
 with basis [1,a,a^2]
 ```
 

diff --git a/docs/src/number_fields/conventions.md b/docs/src/number_fields/conventions.md
@@ -44,7 +44,7 @@ determinant $\det(B)^{-1}$ is in fact equal to $[ \mathcal O : \mathbf Z[\alpha]
 and is called the *index* of $\mathcal O$.
 The matrix
 ```math
-\begin{pmatrix} 
+\begin{pmatrix}
 \sigma_1(\omega_1) & \dotsc & \sigma_r(\omega_1) & \sqrt{2}\operatorname{Re}(\sigma_{r+1}(\omega_1)) & \sqrt{2}\operatorname{Im}(\sigma_{r+1}(\omega_1)) & \dotsc & \sqrt{2}\operatorname{Im}(\sigma_{r+s}(\omega_1)) \\\\
 \sigma_1(\omega_2) & \dotsc & \sigma_r(\omega_2) & \sqrt{2}\operatorname{Re}(\sigma_{r+1}(\omega_2)) & \sqrt{2}\operatorname{Im}(\sigma_{r+1}(\omega_2)) & \dotsc  & \sqrt{2}\operatorname{Im}(\sigma_{r+s}(\omega_2)) \\\\
 \vdots & \ddots & \vdots & \vdots & \vdots & \ddots & \vdots\\\\

diff --git a/docs/src/number_fields/fields.md b/docs/src/number_fields/fields.md
@@ -138,7 +138,7 @@ inertia_subgroup(::AnticNumberField, ::NfOrdIdl, ::Map)
 infinite_places(K::NumField)
 real_places(K::AnticNumberField)
 complex_places(K::AnticNumberField)
-isreal(::Plc) 
+isreal(::Plc)
 iscomplex(::Plc)
 infinite_places_uniformizers(::AnticNumberField)
 ```

diff --git a/docs/src/number_fields/internal.md b/docs/src/number_fields/internal.md
@@ -12,7 +12,7 @@ different types:
  - `NfAbsNS`: a finite extension of $\mathbf{Q}$ given by several polynomials.
    We will refer to this as a non-simple field - even though mathematically
    we can find a primitive elements.
- - `NfRel`: a finite simple extension of a number field. This is 
+ - `NfRel`: a finite simple extension of a number field. This is
    actually parametried by the (element) type of the coefficient field.
    The complete type of an extension of an absolute field (`AnticNumberField`)
    is `NfRel{nf_elem}`. The next extension thus will be
@@ -28,7 +28,7 @@ called absolute.
 Internally, simple fields are essentially just (univariate) polynomial
 quotients in a dense representation, while non-simple fields are
 multivariate quotient rings, thus have a sparse presentation.
-In general, simple fields allow much faster arithmetic, while 
+In general, simple fields allow much faster arithmetic, while
 the non-simple fields give easy access to large degree fields.
 
 ## Absolute simple fields

diff --git a/docs/src/orders/elements.md b/docs/src/orders/elements.md
@@ -4,18 +4,18 @@ CurrentModule = Hecke
 ```
 
 
-Elements in orders have two representations: they can be viewed as 
+Elements in orders have two representations: they can be viewed as
 elements in the $Z^n$ giving the coefficients wrt to the order basis
 where they are elements in. On the other hand, as every order is
 in a field, they also have a representation as number field elements.
-Since, asymptotically, operations are more efficient in the 
+Since, asymptotically, operations are more efficient in the
 field (due to fast polynomial arithmetic) than in the order, the primary
 representation is that as a field element.
 
 ## Creation
 
 Elements are constructed either as linear combinations of basis elements
-or via explicit coercion. Elements will be of type `NfOrdElem`, 
+or via explicit coercion. Elements will be of type `NfOrdElem`,
 the type if actually parametrized by the type of the surrounding field and
 the type of the field elements. E.g. the type of any element in any
 order of an absolute simple field will be

diff --git a/docs/src/orders/ideals.md b/docs/src/orders/ideals.md
@@ -6,7 +6,7 @@ CurrentModule = Hecke
 
 (Integral) ideals in orders are always free $Z$-module of the same rank as the
 order, hence have a representation via a $Z$-basis. This can be made unique
-by normalising the corresponding matrix to be in reduced row echelon form 
+by normalising the corresponding matrix to be in reduced row echelon form
 (HNF).
 
 For ideals in maximal orders $Z_K$, we also have a second presentation coming
@@ -89,7 +89,7 @@ mc \ ans
 
 
 The class group, or more precisely the information used to compute it
-also allows for principal ideal testing and related tasks. 
+also allows for principal ideal testing and related tasks.
 In general, due to the size of the objetcs, the ```fac_elem``` versions are
 more effcient.
 

diff --git a/docs/src/orders/introduction.md b/docs/src/orders/introduction.md
@@ -3,7 +3,7 @@
 CurrentModule = Hecke
 ```
 
-This chapter deals with number fields and orders there of. 
+This chapter deals with number fields and orders there of.
 We follow the common terminology and conventions as e.g. used in
 [Cohen1](@cite), [Cohen2](@cite), [PoZa](@cite) or [Marcus](@cite).
 
@@ -16,7 +16,7 @@ and of relative number fields is the same.
 
 ## Orders of absolute number fields
 
-Assume that $K$ is defined as an absolute field. 
+Assume that $K$ is defined as an absolute field.
 An order $\mathcal O$ of such a field are constructed (implicitely) by
 specifying a $\mathbf Z$-basis, which is refered to as the *basis* of $\mathcal
 O$. If $(\omega_1,\dotsc,\omega_d)$ is the basis of $\mathcal O$ and
@@ -40,7 +40,7 @@ finitly generated torsion-free module over the Dedekind domain $\mathcal O_K$. A
 the order $\mathcal O$ is unitary and has $L$ as a fraction field.
 Due to $\mathcal O_K$ in general not being a principal
 ideal domain, the module structure is more complicated
-and requires so called pseudo-matrices. See 
+and requires so called pseudo-matrices. See
 [here](@ref PMatLink) for details on pseudo-matrices, or [Cohen2](@cite),
 Chapter 1 for an introduction.
 

diff --git a/docs/src/orders/orders.md b/docs/src/orders/orders.md
@@ -101,7 +101,7 @@ All of the functions have a very similar interface: they return
 an abelian group and a map converting elements of the group
 into the objects required. The maps also
 allow a point-wise inverse to server as the *discrete logarithm* map.
-For more information on abelian group, see [here](@ref AbelianGroupLink), 
+For more information on abelian group, see [here](@ref AbelianGroupLink),
 for ideals, [here](@ref NfOrdIdlLink).
 
 - [`torsion_unit_group(::NfOrd)`](@ref)

diff --git a/docs/src/pmat/introduction.md b/docs/src/pmat/introduction.md
@@ -13,7 +13,7 @@ Let $R$ be a Dedekind domain, typically, the maximal order of
 some number field $K$, further fix some finite dimensional
 $K$-vectorspace $V$ (with some basis), frequently $K^n$ or the $K$-structure of
 some extension of $K$. Since in general $R$ is not a PID, the $R$-modules
-in $V$ are usually not free, but still projective. 
+in $V$ are usually not free, but still projective.
 
 Any finitely generated $R$-module $M\subset V$
 can be represented as a pseudo-matrix `PMat` as follows:
@@ -26,7 +26,7 @@ Following Cohen we call modules of the form $\mathfrak A\omega$ for
 some ideal $\mathfrak A$ and $\omega \in V$ a *pseudo element*.
 A system $(\mathfrak A_i, \omega_i)$ is called a pseudo-generating
 system for $M$ if $\langle \mathfrak A_i\omega_i|i\langle = M$.
-A pseudo-generating system is called a pseudo-basis if the 
+A pseudo-generating system is called a pseudo-basis if the
 $\omega_i$ are $K$-linear independent.
 
 A *pseudo-matrix* $X$ is a tuple containing a vector of ideals

diff --git a/docs/src/quad_forms/basics.md b/docs/src/quad_forms/basics.md
@@ -1,4 +1,4 @@
-# Basics 
+# Basics
 ```@meta
 CurrentModule = Hecke
 ```
-Original file line number
+Diff line change
@@ Expand Up / @@ -40,5 +40,5 @@ G = abelian_group(fmpz[1 2; 3 4]) @@
     for g = G
       println(g)
     end
-    ```
+    ```