Merge pull request #1116 from mrapp-ke/merge-feature

Merge feature into main branch

CHANGELOG.md

@@ -92,7 +92,7 @@ This release comes with several API changes. For an updated overview of the avai
 - Development versions of wheel packages are now regularly built via continuous integration, uploaded as artifacts, and published on [Test-PyPI](https://test.pypi.org/).
 - Continuous integration is now used to maintain separate branches for major, feature, and bugfix releases and keep them up-to-date.
 - The runtime of continuous integration jobs has been optimized by running individual steps only if necessary, caching files across subsequent runs, and making use of parallelization.
-- When tests are run via continuous integration, a summary of the test results is now added to merge requests and Github workflows.
+- When tests are run via continuous integration, a summary of the test results is now added to merge requests and GitHub workflows.
 - Markdown files are now used for writing the documentation.
 - A consistent style is now enforced for Markdown files by applying the tool `mdformat` via continuous integration.
 - C++ 17 or newer is now required for compiling the project.
@@ -149,7 +149,7 @@ This release comes with several API changes. For an updated overview of the avai
 
 ### Quality-of-Life Improvements
 
-- Continuous integration is now used to test the most common functionalites of the BOOMER algorithm and the corresponding command line API.
+- Continuous integration is now used to test the most common functionalities of the BOOMER algorithm and the corresponding command line API.
 - Successful generation of the documentation is now tested via continuous integration.
 - Style definitions for Python and C++ code are now enforced by applying the tools `clang-format`, `yapf`, and `isort` via continuous integration.
 
@@ -185,8 +185,8 @@ This release comes with changes to the command line API. For an updated overview
 A bugfix release that solves the following issues:
 
 - Fixes an issue preventing the use of dense representations of ground truth label matrices that was introduced in version 0.7.0.
-- Pre-built packages for MacOS systems are now available at [PyPI](https://pypi.org/project/mlrl-boomer/).
-- Linux and MacOS packages for Python 3.10 are now provided.
+- Pre-built packages for macOS systems are now available at [PyPI](https://pypi.org/project/mlrl-boomer/).
+- Linux and macOS packages for Python 3.10 are now provided.
 
 ## Version 0.7.0 (Dec. 5, 2021)
 
@@ -266,7 +266,7 @@ A major update to the BOOMER algorithm that features the following changes:
 - Includes many refactorings and quality of live improvements. Code that is not directly related with the algorithm, such as the implementation of baselines, has been removed.
 - The algorithm is now able to natively handle nominal features without the need for pre-processing techniques such as one-hot encoding.
 - Sparse feature matrices can now be used for training and prediction, which reduces the memory footprint and results in a significant speed-up of training times on some data sets.
-- Additional hyper-parameters (`min_coverage`, `max_conditions` and `max_head_refinements`) that provide fine-grained control over the specificity/generality of rules have been added.
+- Additional hyperparameters (`min_coverage`, `max_conditions` and `max_head_refinements`) that provide fine-grained control over the specificity/generality of rules have been added.
 
 ## Version 0.1.0 (Jun. 22, 2020)
 

README.md

@@ -39,7 +39,7 @@ The algorithm that is provided by this project currently supports the following
 - **Rules can be constructed via a greedy search or a beam search.** The latter may help to improve the quality of individual rules.
 - **Sampling techniques and stratification methods** can be used for learning new rules on a subset of the available training examples, features, or output variables.
 - **Shrinkage (a.k.a. the learning rate) can be adjusted** for controlling the impact of individual rules on the overall ensemble.
-- **Fine-grained control over the specificity/generality of rules** is provided via hyper-parameters.
+- **Fine-grained control over the specificity/generality of rules** is provided via hyperparameters.
 - **Incremental reduced error pruning** can be used for removing overly specific conditions from rules and preventing overfitting.
 - **Post- and pre-pruning (a.k.a. early stopping)** allows to determine the optimal number of rules to be included in an ensemble.
 - **Sequential post-optimization** may help improving the predictive performance of a model by reconstructing each rule in the context of the other rules.

doc/developer_guide/coding_standards.md

@@ -8,23 +8,23 @@ As it is common for Open Source projects, where everyone is invited to contribut
 
 ## Continuous Integration
 
-We make use of [Github Actions](https://docs.github.com/en/actions) as a [Continuous Integration](https://en.wikipedia.org/wiki/Continuous_integration) (CI) server for running predefined jobs, such as automated tests, in a controlled environment. Whenever certain parts of the project's repository have changed, relevant jobs are automatically executed.
+We make use of [GitHub Actions](https://docs.github.com/en/actions) as a [Continuous Integration](https://en.wikipedia.org/wiki/Continuous_integration) (CI) server for running predefined jobs, such as automated tests, in a controlled environment. Whenever certain parts of the project's repository have changed, relevant jobs are automatically executed.
 
 ```{tip}
-A track record of past runs can be found on Github in the [Actions](https://github.com/mrapp-ke/MLRL-Boomer/actions) tab.
+A track record of past runs can be found on GitHub in the [Actions](https://github.com/mrapp-ke/MLRL-Boomer/actions) tab.
 ```
 
 The workflow definitions of individual CI jobs can be found in the directory [.github/workflows/](https://github.com/mrapp-ke/MLRL-Boomer/tree/8ed4f36af5e449c5960a4676bc0a6a22de195979/.github/workflows). Currently, the following jobs are used in the project:
 
-- `publish.yml` is used for publishing pre-built packages on [PyPI](https://pypi.org/) (see {ref}`installation`). For this purpose, the project is built from source for each of the target platforms and architectures, using virtualization in some cases. The job is run automatically when a new release was published on [Github](https://github.com/mrapp-ke/MLRL-Boomer/releases). It does also increment the project's major version number and merge the release branch into its upstream branches (see {ref}`release-process`).
+- `publish.yml` is used for publishing pre-built packages on [PyPI](https://pypi.org/) (see {ref}`installation`). For this purpose, the project is built from source for each of the target platforms and architectures, using virtualization in some cases. The job is run automatically when a new release was published on [GitHub](https://github.com/mrapp-ke/MLRL-Boomer/releases). It does also increment the project's major version number and merge the release branch into its upstream branches (see {ref}`release-process`).
 - `publish_development.yml` publishes development versions of packages on [Test-PyPI](https://test.pypi.org/) whenever changes to the project's source code have been pushed to the main branch. The packages built by each of these runs are also saved as [artifacts](https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts) and can be downloaded as zip archives.
 - `test_publish.yml` ensures that the packages to be released for different architectures and Python versions can be built. The job is run for pull requests that modify relevant parts of the source code.
-- `test_build.yml` builds the project for each of the supported target platforms, i.e., Linux, Windows, and MacOS (see {ref}`compilation`). In the Linux environment, this job does also execute all available unit and integration tests (see {ref}`testing`). It is run for pull requests whenever relevant parts of the project's source code have been modified.
+- `test_build.yml` builds the project for each of the supported target platforms, i.e., Linux, Windows, and macOS (see {ref}`compilation`). In the Linux environment, this job does also execute all available unit and integration tests (see {ref}`testing`). It is run for pull requests whenever relevant parts of the project's source code have been modified.
 - `test_doc.yml` generates the latest documentation (see {ref}`documentation`) whenever relevant parts of the source code are affected by a pull request.
 - `test_format.yml` ensures that all source files in the project adhere to our coding style guidelines (see {ref}`code-style`). This job is run automatically for pull requests whenever they include any changes affecting the relevant source files.
 - `test_changelog.yml` ensures that all changelog files in the project adhere to the structure that is necessary to be processed automatically when publishing a new release. This job is run for pull requests if they modify one of the changelog files.
 - `merge_feature.yml` and `merge_bugfix.yml` are used to merge changes that have been pushed to the feature or bugfix branch into downstream branches via pull requests (see {ref}`release-process`).
-- `merge_release.yml` is used to merge all changes included in a new release published on [Github](https://github.com/mrapp-ke/MLRL-Boomer/releases) into upstream branches and update the version numbers of these branches.
+- `merge_release.yml` is used to merge all changes included in a new release published on [GitHub](https://github.com/mrapp-ke/MLRL-Boomer/releases) into upstream branches and update the version numbers of these branches.
 
 (testing)=
 
@@ -38,7 +38,7 @@ To be able to detect problems with the project's source code early during develo
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build tests
    ```
@@ -58,7 +58,7 @@ This will result in all tests being run and their results being reported. If the
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    SKIP_EARLY=true ./build tests
    ```
@@ -100,7 +100,7 @@ If you have modified the project's source code, you can check whether it adheres
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build test_format
    ```
@@ -124,7 +124,7 @@ In order to automatically format the project's source files according to our sty
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build format
    ```
@@ -178,7 +178,7 @@ To enable releasing new major, feature, or bugfix releases at any time, we maint
 
 We do not allow directly pushing to the above branches. Instead, all changes must be submitted via pull requests and require certain checks to pass.
 
-Once modifications to one of the branches have been merged, {ref}`Continuous Integration <ci>` jobs are used to automatically update downstream branches via pull requests. If all checks for such pull requests are successful, they are merged automatically. If there are any merge conflicts, they must be resolved manually. Following this procedure, changes to the feature brach are merged into the main branch (see `merge_feature.yml`), whereas changes to the bugfix branch are first merged into the feature branch and then into the main branch (see `merge_bugfix.yml`).
+Once modifications to one of the branches have been merged, {ref}`Continuous Integration <ci>` jobs are used to automatically update downstream branches via pull requests. If all checks for such pull requests are successful, they are merged automatically. If there are any merge conflicts, they must be resolved manually. Following this procedure, changes to the feature branch are merged into the main branch (see `merge_feature.yml`), whereas changes to the bugfix branch are first merged into the feature branch and then into the main branch (see `merge_bugfix.yml`).
 
 Whenever a new release has been published, the release branch is merged into the upstream branches (see `merge_release.yml`), i.e., major releases result in the feature and bugfix branches being updated, whereas minor releases result in the bugfix branch being updated. The version of the release branch and the affected branches are updated accordingly. The version of a branch is specified in the file `.version` in the project's root directory. Similarly, the file `.version-dev` is used to keep track of the version number used for development releases (see `publish_development.yml`).
 
@@ -200,7 +200,7 @@ To ease the life of developers, the following command provided by the project's
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build check_dependencies
    ```

doc/developer_guide/compilation.md

@@ -8,7 +8,7 @@ Unlike pure Python programs, the C++ and Cython source files must be compiled fo
 
 ## Prerequisites
 
-As a prerequisite, a supported version of Python, a suitable C++ compiler, as well as optional libraries for multi-threading and GPU support, must be available on the host system. The installation of these software components depends on the operation system at hand. In the following, we provide installation instructions for the supported platforms.
+As a prerequisite, a supported version of Python, a suitable C++ compiler, as well as optional libraries for multi-threading and GPU support, must be available on the host system. The installation of these software components depends on the operating system at hand. In the following, we provide installation instructions for the supported platforms.
 
 ```{tip}
 This project uses [Meson](https://mesonbuild.com/) as a build system for compiling C++ code. If available on the system, Meson automatically utilizes [Ccache](https://ccache.dev/) for caching previous compilations and detecting when the same compilation is being done again. Compared to the runtime without Ccache, where changes are only detected at the level of entire files, usage of this compiler cache can significantly speed up recompilation and therefore is strongly adviced.
@@ -29,12 +29,12 @@ This project uses [Meson](https://mesonbuild.com/) as a build system for compili
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```{list-table}
    * - **Python**
-     - Recent versions of MacOS do not include Python by default. A suitable Python version can manually be downloaded from the [project's website](https://www.python.org/downloads/macos/). Alternatively, the package manager [Homebrew](<https://en.wikipedia.org/wiki/Homebrew_(package_manager)>) can be used for installation via the command `brew install python`.
+     - Recent versions of macOS do not include Python by default. A suitable Python version can manually be downloaded from the [project's website](https://www.python.org/downloads/macos/). Alternatively, the package manager [Homebrew](<https://en.wikipedia.org/wiki/Homebrew_(package_manager)>) can be used for installation via the command `brew install python`.
    * - **C++ compiler**
-     - MacOS relies on the [Clang](https://en.wikipedia.org/wiki/Clang) compiler for building C++ code. It is part of the [Xcode](https://developer.apple.com/support/xcode/) developer toolset.
+     - macOS relies on the [Clang](https://en.wikipedia.org/wiki/Clang) compiler for building C++ code. It is part of the [Xcode](https://developer.apple.com/support/xcode/) developer toolset.
    * - **GoogleTest**
      - The [GoogleTest](https://github.com/google/googletest) framework must optionally be installed in order to compile the project with {ref}`testing support <testing-support>` enabled. It can easily be installed via [Homebrew](<https://en.wikipedia.org/wiki/Homebrew_(package_manager)>) by runnig the command `brew install googletest`.
    * - **OpenMP**
@@ -70,7 +70,7 @@ Instead of following the instructions below step by step, the following command,
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build
    ```
@@ -94,7 +94,7 @@ As shown in the section {ref}`project-structure`, this project is organized in t
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    SUBPROJECTS=common,boosting ./build
    ```
@@ -110,15 +110,15 @@ As shown in the section {ref}`project-structure`, this project is organized in t
 
 ## Creating a Virtual Environment
 
-The build process is based on an virtual Python environment that allows to install build- and run-time dependencies in an isolated manner and independently from the host system. Once the build process was completed, the resulting Python packages are installed into the virtual environment. To create new virtual environment and install all necessarily run-time dependencies, the following command must be executed:
+The build process is based on a virtual Python environment that allows to install build- and run-time dependencies in an isolated manner and independently of the host system. Once the build process was completed, the resulting Python packages are installed into the virtual environment. To create new virtual environment and install all necessarily run-time dependencies, the following command must be executed:
 
 ````{tab} Linux
    ```text
    ./build venv
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build venv
    ```
@@ -142,7 +142,7 @@ Once a new virtual environment has successfully been created, the compilation of
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build compile_cpp
    ```
@@ -166,7 +166,7 @@ Once the compilation of the C++ code has completed, the Cython code, which allow
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build compile_cython
    ```
@@ -186,15 +186,15 @@ Instead of performing the previous steps one after the other, the build target `
 
 ## Installing Shared Libraries
 
-The shared libraries that have been created in the previous steps from the C++ source files must afterwards be copied into the Python source tree. This can be achieved by executing the following command:
+The shared libraries that have been created in the previous steps from the C++ source files must afterward be copied into the Python source tree. This can be achieved by executing the following command:
 
 ````{tab} Linux
    ```text
    ./build install_cpp
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build install_cpp
    ```
@@ -222,7 +222,7 @@ Similar to the previous step, the Python extension modules that have been built
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build install_cython
    ```
@@ -250,7 +250,7 @@ Once the compilation files have been copied into the Python source tree, wheel p
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build build_wheels
    ```
@@ -274,7 +274,7 @@ The wheel packages that have previously been created can finally be installed in
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build install_wheels
    ```
@@ -298,7 +298,7 @@ It is possible to delete the compilation files that result from an individual st
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build --clean compile_cpp
    ```
@@ -318,7 +318,7 @@ If you want to delete all compilation files that have previously been created, i
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build --clean
    ```

doc/developer_guide/documentation.md

@@ -21,7 +21,7 @@ It is not necessary to execute the steps below one after the other. Instead, run
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build doc
    ```
@@ -46,7 +46,7 @@ By running the following command, the C++ API documentation is generated via Dox
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build apidoc_cpp
    ```
@@ -70,7 +70,7 @@ Similarly, the following command generates an API documentation from the project
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build apidoc_python
    ```
@@ -96,7 +96,7 @@ To generate the final documentation's HTML files via [sphinx](https://www.sphinx
    ```
 ````
 
-````{tab} MacOS
+````{tab} macOS
    ```text
    ./build doc
    ```
@@ -108,7 +108,7 @@ To generate the final documentation's HTML files via [sphinx](https://www.sphinx
    ```
 ````
 
-Afterwards, the generated files can be found in the directory `doc/_build/html/`.
+Afterward, the generated files can be found in the directory `doc/_build/html/`.
 
 ## Cleaning up Build Files