- this class models domains from linear algebra
and is needed for the `Vector` class to be created
- `Domain` wraps Python's built-in `frozenset` type
+ they must contain at least one label
+ as a convenience, so-called canonical `Domain`s
(i.e., with labels `0`, `1`, ...) can be created
by passing in a positive `int`eger to `Domain()`
- the `Domain.is_canonical` property indicates
what kind a `Domain` is
- add unit tests for the class
- add extensive documentation for the class
- so far, `gf2()` runs in a `strict` mode by default
=> `gf2(42)` results in a `ValueError`
- we adapt `gf2()` (a.k.a. `lalib.elements.galois.GF2Element`)
such that it behaves more like the built-in `bool()`
=> `gf2(42)` returns `one`, like `bool(42)` returns `True`
- further, the `GF2Element` class is adjusted such that
`one` and `zero` assume their counterparts to be
`1`-like or `0`-like objects during binary operations;
other values result in an error
=> for example, `one + 1` works but `one + 42` does not
=> so, when used in binary operations, `one` and `zero`
continue to cast their counterparts in `strict` mode
- simplify the casting logic
- make `value` a positional-only argument in `gf2()`
(like most of the built-in constructors)
- provide more usage examples in the docstrings
clarifying when `strict` mode is used and when not
- propagate the above changes to the test suite:
+ adapt test cases with regard to the `strict` mode logic
+ add new test cases to `assert` how `gf2()`
can process `str`ings directly
+ rename two test cases involving `complex` numbers
to mimic the naming from the newly added test cases
- 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
- 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
- the `gf2` sub-classes `GF2One` and `GF2Zero` have no purpose
other than to provide unique `help(one)` and `help(zero)` messages
- delete them at the bottom of `lalib.elements.galois`
to prevent them from being imported at all
(`type(one)` and `type(zero)` still appear to be the `gf2` class,
which is a little white lie, provided by some meta class)
- differentiate between official and inofficial API in the test suite
- `to_gf2()` is only to be used within `GF2Element.__new__()`
=> rename it into `_to_gf2()`
- the test cases in `TestGF2ConstructorWithCastedValue`
cover everything in `TestGF2Casting`
=> retire the redundant test cases
and make the test suite run faster
- 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
- make `GF2`, `one`, and `zero`, defined in the `lalib.elements.gf2`
module, available as top-level imports for the `lalib` package
via `from lalib import *`
- provide some code snippets in the package's docstring
- test the star import
- 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
- 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
- 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
- `lalib.__version__` is dynamically assigned
- the format is "x.y.z[.dev0|aN|bN|rcN|.postM]"
where x, y, z, M, and N are non-negative integers
+ x, y, and z model the "major", "minor", and "patch"
parts of semantic versioning
(See: https://semver.org/#semantic-versioning-200)
+ M is a single digit and N either 1 or 2
=> This complies with (a strict subset of) PEP440
- add unit tests for the `__version__` identifier
- use pytest as the test suite and
measure test coverage with coverage.py
- add package for the test suite under tests/
- add nox session "test" to run the test suite
for all supported Python versions
- use flake8 to lint pytest for consistent style
