From 8d54ec5ca467907b013fa2d19968a59e2eb96c8f Mon Sep 17 00:00:00 2001 From: Alan R R Freitas Date: Tue, 15 Sep 2020 01:38:44 -0300 Subject: [PATCH] Update use cases --- .github/ISSUE_TEMPLATE/feature-request.md | 6 +++- .github/workflows/build.yml | 7 ++-- README.md | 41 ++++++++++++----------- 3 files changed, 32 insertions(+), 22 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/feature-request.md b/.github/ISSUE_TEMPLATE/feature-request.md index c4b866c..33de2c2 100644 --- a/.github/ISSUE_TEMPLATE/feature-request.md +++ b/.github/ISSUE_TEMPLATE/feature-request.md @@ -8,9 +8,13 @@ assignees: '' --- **Feature category** -- [ ] *enhancement - code* +- [ ] *enhancement - indicators* +- [ ] *enhancement - data structures* +- [ ] *enhancement - bindings* - [ ] *enhancement - build system* - [ ] *enhancement - documentation* +- [ ] *enhancement - query types* +- [ ] *enhancement - dominance types* **The problem** diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index b48210f..ff7adb0 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -38,6 +38,7 @@ jobs: get_core_cmd: "WMIC CPU Get DeviceID,NumberOfCores,NumberOfLogicalProcessors", sudocmd: "", artifact_name: "Windows", + cores: 2, } - { name: "Linux/Static/X64/Release", @@ -47,6 +48,7 @@ jobs: get_core_cmd: "lscpu", sudocmd: "sudo", artifact_name: "Linux", + cores: 2, } - { name: "MacOSX/Static/X64/Release", @@ -56,6 +58,7 @@ jobs: get_core_cmd: "system_profiler SPHardwareDataType", sudocmd: "sudo", artifact_name: "MacOSX", + cores: 4, } steps: - uses: actions/checkout@v2 @@ -76,7 +79,7 @@ jobs: cmake .. ${{ matrix.config.args }} -DCMAKE_BUILD_TYPE=${{ matrix.config.config }} -DBUILD_LONG_TESTS=ON -DMAX_NUM_DIMENSIONS_PYTHON=10 -DBUILD_BINDING_FOR_ALL_STRUCTURES=ON - name: Build working-directory: ./build - run: cmake --build . -j 2 --config ${{ matrix.config.config }} + run: cmake --build . -j ${{ matrix.config.cores }} --config ${{ matrix.config.config }} - name: Archive Python Binding uses: actions/upload-artifact@v2 with: @@ -86,7 +89,7 @@ jobs: build/bindings/Release/pyfront.cp*-*.* - name: Test working-directory: ./build - run: ctest -j 2 -C Release + run: ctest -j ${{ matrix.config.cores }} -C Release - name: Install working-directory: ./build run: ${{ matrix.config.sudocmd }} cmake --install . diff --git a/README.md b/README.md index 4e3ca57..08f2c7e 100644 --- a/README.md +++ b/README.md @@ -14,16 +14,19 @@ Whenever we push an element to a front, all other elements that might be worse i While there are many libraries for multi-objective optimization, there are no libraries focused on efficient container types for storing these fronts in general applications. -This library provides a STL-like container representing a data structure to cache and query multi-dimensional Pareto fronts and archives with its most expensive operations in time. +This library provides a STL-like container representing a data structure to cache and query multi-dimensional Pareto fronts and archives with its most expensive operations in time. Some use cases are to store objects with the best values according to the following trade-offs: -* Quality vs. robustness -* Mean quality vs. standard deviation -* Model accuracy vs. model complexity -* Efficiency vs. price vs. quality -* Return vs. risk -* Trust vs. speed +* Machine Learning: Model accuracy vs. model complexity +* Approximation algorithms: error vs. time +* Product design: investment vs. profit vs. safety +* P2P networks: latency vs. trust +* Robust optimization: quality vs. sensitivity / robustness +* Design: Mean quality vs. standard deviation +* Systems control: Performance vs. price vs. quality +* Portfolio optimization: expected return vs. risk +* [More applications](https://en.wikipedia.org/wiki/Multi-objective_optimization#Examples_of_applications) @@ -58,15 +61,15 @@ Some use cases are to store objects with the best values according to the follow ## Design goals - Intuitive syntax: interface like any other native data structure. -- Lots of indicators: get statistics with one line of code. +- Lots of indicators: calculate statistics with one line of code. - Easy integration: C++ and Python interfaces. -- Speed: spatial indexes. No pairwise comparisons on linear lists (unless you want to). +- Performance: spatial indexes. No pairwise comparisons on linear lists (unless you want to). - Efficient memory allocation to make small fronts competitive with linear lists. - Stability: lots of unit tests, benchmarks, and continuous integration. ## Examples -For very complete examples, see the directory [examples](./examples/). +For complete examples, see the directory [examples](./examples/). ### Constructing fronts @@ -171,7 +174,7 @@ We use `operator()` for C++ because the `operator[]` does not allow more than on ### Reference points -We can find any extreme value in time, and iterators to the extreme elements in time. +We can find any extreme value in time, and iterators to the extreme elements in time. ```python print('Ideal point:', pf.ideal()) @@ -474,17 +477,17 @@ Assuming the well-known $O(m \log n)$ average time complexity for search, insert | Operation | Front | Archive | |-----|------|---------| | Space | | | -| Search | | | -| Insert | | | -| Delete | | | +| Search | | | +| Insert | | | +| Delete | | | | Allocation | | | | Deallocation | | | | Extreme value | | | -| Extreme element | | | +| Extreme element | | | | Extreme point | | | -| Next Nearest Element | | | -| Next Query Element | | | -| Front Dominance | | | +| Next Nearest Element | | | +| Next Query Element | | | +| Front Dominance | | | | Exact hypervolume | | | | Monte-Carlo hypervolume | | | | C-metric | | | @@ -494,7 +497,7 @@ Assuming the well-known $O(m \log n)$ average time complexity for search, insert ## Benchmarks -The default tag for fronts and archives is converted to an appropriate data structure according the the parameters. This section presents some benchmarks comparing these data structures. We use the notation `L`, `Q`, `K`, `B`, `R`, and `*` for Lists, Quadtrees, $k$-d trees, Boost.Geomtry R-trees, Point R-trees, and R*-Trees. The tree data structures in the benchmark used a [memory pool allocator](sources/pareto_front/memory_pool.h). If using this code in production, it is more prudent to use `std::pmr::unsynchronized_pool_resource`, `std::allocator`, or execute *many* tests to make sure `pareto::fast_memory_pool` is works properly on your system. +The default tag for fronts and archives is converted to an appropriate data structure according to the front or archive parameters. This section presents some benchmarks comparing these data structures. We use the notation `L`, `Q`, `K`, `B`, `R`, and `*` for Lists, Quadtrees, $k$-d trees, Boost.Geomtry R-trees, Point R-trees, and R*-Trees. The tree data structures in the benchmark used a [memory pool allocator](sources/pareto_front/memory_pool.h) for faster allocation. This is intented to make trees more competitive with linear lists for small fronts. If using this code in production, it is more prudent to use [`std::pmr::unsynchronized_pool_resource`](https://en.cppreference.com/w/cpp/memory/unsynchronized_pool_resource/unsynchronized_pool_resource) (if your compiler supports it), [`std::allocator`](https://en.cppreference.com/w/cpp/memory/allocator) (if you want to be conservative), or execute *many* tests to make sure [`pareto::fast_memory_pool`](sources/pareto_front/memory_pool.h) works properly on your system.
Constructor