Commit graph

6 commits

Author SHA1 Message Date
7e3e67c300
Add smoke tests
- extend `pytest` with an option to run only the minimum number
  of (unit) test cases to just keep the coverage at 100%
- rationale:
  + many of the unit test cases partly overlap with
    respect to the lines of source code executed
  + also, integration tests, by definition, do not
    contribute to a higher test coverage
- implementation: mark "redundant" test cases as one of:
  + `pytest.mark.integration_test`
    => code usage from the perspective of the end user
  + `pytest.mark.overlapping_test`
    => tests not contributing to the 100% coverage
  + `pytest.mark.sanity_test`
    => tests providing confidence in the test data
- add `tests.conftest` module
  => programatically convert the above markers into
     `@pytest.mark.no_cover` and collect the non-"redundant" tests
- add nox session "test-fast" to run only the minimum
  number of (unit) test while holding coverage at 100%
- refactor some test modules
  + wrap some test cases in a class
  + move sanity tests to the end of the files
2024-10-15 01:49:32 +02:00
153094eef5
Add Q, R, C, and GF2 fields
- add `lalib.fields.base.Field`, a blueprint for all concrete fields,
  providing a unified interface to be used outside of the
  `lalib.fields` sub-package
- implement `lalib.fields.complex_.ComplexField`, or `C` for short,
  the field over the complex numbers (modeled as `complex` numbers)
- implement `lalib.fields.galois.GaloisField2`, or `GF2` for short,
  the (finite) field over the two elements `one` and `zero`
  + adapt `lalib.elements.galois.GF2Element.__eq__()` to return
    `NotImplemented` instead of `False` for non-castable `other`s
    => this fixes a minor issue with `pytest.approx()`
- implement `lalib.fields.rational.RationalField`, or `Q` for short,
  the field over the rational numbers (modeled as `fractions.Fraction`s)
- implement `lalib.fields.real.RealField`, or `R` for short,
  the field over the real numbers (modeled as `float`s)
- organize top-level imports for `lalib.fields`,
  making `Q`, `R`, `C`, and `GF2` importable with
  `from lalib.fields import *`
- provide extensive unit and integration tests for the new objects:
  + test generic and common behavior in `tests.fields.test_base`
  + test specific behavior is other modules
  + test the well-known math axioms for all fields (integration tests)
  + test the new objects' docstrings
  + add "pytest-repeat" to run randomized tests many times
2024-10-14 15:17:42 +02:00
917c217ca0
Rename lalib.elements.gf2.GF2 & friends
- the future (concrete) Galois `Field` implementation
  shall receive the name `GF2` (as per common math notation)
  => name conflict with the current `GF2` class
     implementing the elements of the future Galois `Field`
  => rename the current `GF2` class into `GF2Element`
- because `GF2Element` is a bit tedius to type for the end user,
  we introduce a `gf2` alias in line with the naming convention
  for the built-in data types (e.g., `int` or `float`)
  that are also used as elements of (other) `Field`s
  => name conflict with the current `lalib.elements.gf2` module
  => rename the module into `lalib.elements.galois`
- adjust the docstrings to refer to "the `gf2` type"
- adjust the top-level imports and tests
2024-09-19 12:14:20 +02:00
3cfc0db136
Organize top-level imports for lalib.elements
- make `GF2`, `one`, and `zero`, defined in the `lalib.elements.gf2`
  module, available as top-level imports in the `lalib.elements`
  sub-package via `from lalib.elements import *`
- provide some code snippets in the sub-package's docstring
- test the star import
2024-09-18 18:29:40 +02:00
3cecf0d989
Add GF2 type for Galois field elements
- add `GF2` class in the `lalib.elements` sub-package
  implementing a typical Galois field with two elements
- the singleton objects `one` and `zero` are the concrete
  instances of the `GF2` type for the end users
- besides the typical Galois arithmetic, `one` and `zero`
  behave like the built-in numbers `1` and `0`
  and implement the `numbers.Rational` interface
- add exhaustive docstrings with usage examples
- add (unit) test cases with 100% coverage
2024-09-18 18:04:35 +02:00
01d270e39c
Add doctests to the test suite
- use xdoctest to validate code snippets in docstrings
- make xdoctest part of the nox session "test" via
  the new `test_docstrings()` test case
- add nox session "test-docstrings" for convenience;
  also, `xdoctest.doctest_module()` does not discover
  docstrings that are imported at the root of the package
  => each new module with docstrings must be added to
     `test_docstrings()` by hand, which is likely forgotten
  => the nox session "test-docstrings" should run on CI
2024-09-10 01:57:02 +02:00