Integrate most of the changes from PR #173 #178

Saethox · 2023-06-27T18:44:25Z

It's probably best to check out the branch locally and review this inside the IDE or run cargo doc, as this PR includes extensive documentation (yet there is still enough missing), which is not very nice to review on GitHub.

I decided to add the logging refactor here already because entangling this is not really worth it, as I would either merge incorrect documentation on other items or spend time rewriting documentation which is then immediately updated.

Changes

Closes #161
Closes #160
Closes #157
Closes #84

New concepts

Identifiers

Identifiers are zero-sized marker types that allow storing the same type T multiple times inside State by adding a I: Identifier type parameter together with a PhantomId to the type, which is handy in a bunch of places.

Lenses

Borrowed from functional programming, lenses (Lens, LensRef, LensMut) make it possible to extract any type T from the state without caring about the wrapper type that actually implements CustomState, which makes it possible to treat e.g. Iterations and Evaluations uniformly, as both just wrap an u32
IdLens<T> and ValueOf<T> implement Lens etc. and extract T and T::Target from the State, respectively

Documentation

Very much new documentation with many examples
Detailed module descriptions are mostly still missing, though, maybe we could update some documentation inside the docs folder for that
Especially documentation of many component and condition modules is still missing
I'd also like references for the heuristics and components that are implemented from literature

Problems

The Problem::default_evaluator method was removed in favor of specifying the Evaluator explicitly (either in Configuration::optimize or inserting through State::insert_evaluator)
Multiple evaluators are possible through identifiers

State

State is now a wrapper around StateRegistry, which is a fully-fledged set of types with dynamic borrowing through interior mutability, which means that borrowing multiple CustomState now feels really natural (this was very inspired from resman)
Many try_* methods which return a Result<_, StateError>

Components and Conditions

A proper require phase between init and execute (Split our component initialization phase into a initialize and require phase #157)
Component methods return a Result
Makes the implementation of many components more modular, often splitting the functionality into a functional module with unit tests

Logging

Trigger was removed in favor of using Condition directly: it is just so much easier to use Conditions which also support the boolean operators and such, we might want to think about temporary Conditions with a dummy Serialize implementation, though
Extracting data now happens primarily through lenses

- Remove MutState - Add StateRegistry as a generic state set - Make State a wrapper around StateRegistry - Add error handling - Move component state into components module

- Add Lens, LensRef, and LensMut - Add IdLens and ValueOf defaults - Add other defaults

- Add a default evaluator

- Rename initialize to init - Add a proper require phase - Split modules further - Add tested functional modules - Add error handling - Remove the concept of termination

HeleNoir · 2023-06-29T08:25:37Z

src/components/boundary.rs

For (future) documentation purposes: Which boundary constraint repair methods were implemented first was based on https://doi.org/10.1016/j.ins.2021.09.058, though individual papers for the different methods were not used.

If we want to include more different methods, https://dl.acm.org/doi/10.1145/3449726.3463214 and https://ieeexplore.ieee.org/document/9878135/ are good resources.

I'll add the first paper as a reference. Maybe open a new issue with the other references, so this won't get lost in this PR?

HeleNoir · 2023-06-29T09:17:15Z

src/components/control_flow.rs

-/// This corresponds to a `while` loop.
+/// # State
+///
+/// This component inserts and updates the current number of [`Iterations`].


Maybe we should put a disclaimer here that we can, of course, also terminate depending on the number of evaluations, as this is more common.

src/components/cro.rs

HeleNoir · 2023-06-29T09:29:29Z

src/components/mapping/common.rs

@@ -0,0 +1,175 @@
+//! Common state mappings.


A bit more documentation in terms of why this exists would be good.

I added some documentation to components::mapping.

HeleNoir · 2023-06-29T09:46:24Z

src/components/selection/common.rs

+    ) -> ExecResult<Vec<&'a Individual<P>>> {
+        let weights = f::proportional_weights(population, self.offset)
+            .wrap_err("population contains invalid objective values")
+            .note("roulette wheel note does work with infinite or negative objective values")?;


There are possible ways to make this work for negative objective values. I thought I had implemented one of those at some point. Ultimately, we should make this work, either by adapting this implementation or by offering a second roulette wheel variant (though that would be rather unnecessary).

I originally removed the handling of negative fitness values because I wasn't sure we were handling all corner cases correctly, and didn't have the time to research this in more detail.

I now have, so please take a look and verify the new implementation.

Looks good, thanks!

HeleNoir

I think we could merge this, though I commented some aspects, but for a more implementation-focused review we should wait if @luleyleo has time to take a look.

luleyleo · 2023-06-29T13:04:49Z

I think I'll find time for it this weekend :)

- Allow negative weights in roulette wheel - Handle ties in ranks correctly

luleyleo

The smaller comments aside, I still see two issues here.

The documentation is missing for many parts, some modules don't have any.
I'm not convinced that lenses are a good idea.

more on lenses

While I do think lenses are powerful and useful, I don't think they are easy to understand. Especially, people without a mathematical background seem to struggle with it. I've spent quite some time working on Druid, which is basically built around lenses as well, and it causes A LOT of confusion. Particularly when they escalate and turn into a whole meta programming language. That's the main reason I did not add them before and instead went with a less flexible but much simpler design. So, in short, I would prefer to avoid this concept and instead do things with normal procedural code instead of type-level meta-programming :)

examples/sphere.rs

src/components/mutation/common.rs

src/components/mutation/de.rs

src/components/mutation/functional.rs

src/problems/objective/mod.rs

src/problems/evaluate.rs

src/state/registry/mod.rs

Saethox · 2023-07-01T23:25:36Z

The documentation is missing for many parts, some modules don't have any.

Writing (good) documentation, unfortunately, takes so much time that I wanted to open this PR even if some stuff is missing documentation. I planned to do another PR focusing on documentation, but I could also make that part of this PR if you think that's better.

I'm not convinced that lenses are a good idea.

I agree that they add complexity, but they are just so elegant. They allow massive code reuse and integrate really well with logging. Why would I want a new component every time I want some parameter to decrease with iterations if I can just specify what parameter should decrease? But they certainly should be really well documented, which they are currently not really.

While I do think lenses are powerful and useful, I don't think they are easy to understand. Especially, people without a mathematical background seem to struggle with it.

One advantage of developing a "scientific" library is that we can assume some mathematical background of people who might want to use MAHF, so the benefit really outweighs the additional complexity (at least in my opinion), in this case. And not that we have to copy what others do, but e.g. CIlib also extensively relies on functional programming concepts like lenses.

src/components/mutation/common.rs

HeleNoir · 2023-07-03T07:36:29Z

The documentation is missing for many parts, some modules don't have any.

Writing (good) documentation, unfortunately, takes so much time that I wanted to open this PR even if some stuff is missing documentation. I planned to do another PR focusing on documentation, but I could also make that part of this PR if you think that's better.

I wouldn't mind if the documentation is completed in another PR. However, (thinking about presenting MAHF at GECCO) the parts that are most difficult to understand should have documentation.

I'm not convinced that lenses are a good idea.

I agree that they add complexity, but they are just so elegant. They allow massive code reuse and integrate really well with logging. Why would I want a new component every time I want some parameter to decrease with iterations if I can just specify what parameter should decrease? But they certainly should be really well documented, which they are currently not really.

While I do think lenses are powerful and useful, I don't think they are easy to understand. Especially, people without a mathematical background seem to struggle with it.

One advantage of developing a "scientific" library is that we can assume some mathematical background of people who might want to use MAHF, so the benefit really outweighs the additional complexity (at least in my opinion), in this case. And not that we have to copy what others do, but e.g. CIlib also extensively relies on functional programming concepts like lenses.

I'm quite torn on the topic of lenses. I can see that they are complex to really understand, but my feeling was that even without proper understanding, you can still implement and use them (maybe I will try later and see what happens). I just don't know if that's what we want. However, I also think that we can expect some background knowledge of possible users. So most important would definitely be a proper documentation, preferably in this PR.

And maybe a stupid idea: can we offer both options, i.e. lenses and components, without breaking the general logging implementation (or without having to do too much adaptation of the code)? Then people could choose depending on their experience when they want to write own extensions and we can use lenses.

src/components/selection/functional.rs

Saethox · 2023-07-03T20:37:36Z

I'm quite torn on the topic of lenses. I can see that they are complex to really understand, but my feeling was that even without proper understanding, you can still implement and use them (maybe I will try later and see what happens). I just don't know if that's what we want. However, I also think that we can expect some background knowledge of possible users. So most important would definitely be a proper documentation, preferably in this PR.

I think we can also hide most of the complexity of lenses by just adding methods for instantiating components with the lenses they are most commonly used with. For example, I added LessThanN::iterations and LessThanN::evaluations methods, which hide that internally just a ValueOf lens is created with the corresponding custom state.

And maybe a stupid idea: can we offer both options, i.e. lenses and components, without breaking the general logging implementation (or without having to do too much adaptation of the code)? Then people could choose depending on their experience when they want to write own extensions and we can use lenses.

Lenses in MAHF are not fully features lenses, but really basically what Extractor was in the old logging with a different name (my first implementation was actually named Extract when I didn't realize yet I'd just reimplemented a kind of lens) and a little bit more generic. You get the State as an argument, extract whatever you want from it and return it, that's basically it. And you can use it both in logging and components, in contrast to Extractor.

luleyleo · 2023-07-03T21:01:50Z

If we assume competent users, then lenses should be nice. Having simple helper functions such as LessThanN::iterations makes it much nicer to write / read too.

luleyleo

Looks good now!

Saethox added 12 commits June 27, 2023 20:36

Make multiple borrowing of state possible

e236638

- Remove MutState - Add StateRegistry as a generic state set - Make State a wrapper around StateRegistry - Add error handling - Move component state into components module

Add the concept of lenses

b86cffe

- Add Lens, LensRef, and LensMut - Add IdLens and ValueOf defaults - Add other defaults

Remove framework module fully

e45c301

Update problem definitions

8001b32

- Add a default evaluator

Refactor all components and conditions

9cbd2e8

- Rename initialize to init - Add a proper require phase - Split modules further - Add tested functional modules - Add error handling - Remove the concept of termination

Update the heuristic definitions

03381e7

Rename tracking to logging and do some refactoring

996434c

Add testing and utils

1339bb7

Add rudimentary utilities for experimentation

384c8ce

Update examples and add benchmark

eafceb2

Update Cargo.toml and README.md

0b4ca43

Make pre-1.70.0 clippy happy

7d5308f

Saethox requested review from luleyleo and HeleNoir June 27, 2023 20:18

Saethox added 3 commits June 28, 2023 14:13

Simplify evaluation

28447d0

Make loop more idiomatic

3504be6

Simply adding the global evaluator

7ef83a3

HeleNoir reviewed Jun 29, 2023

View reviewed changes

src/components/cro.rs Outdated Show resolved Hide resolved

HeleNoir reviewed Jun 29, 2023

View reviewed changes

HeleNoir approved these changes Jun 29, 2023

View reviewed changes

Saethox added 4 commits July 1, 2023 03:30

Improve selection methods

ea80af5

- Allow negative weights in roulette wheel - Handle ties in ranks correctly

Move CRO components into submodule

db3239e

Fix assert position

83d7136

Fix some documentation

4baf0a0

luleyleo reviewed Jul 1, 2023

View reviewed changes

Integrate some review feedback

402db2c

luleyleo reviewed Jul 2, 2023

View reviewed changes

src/components/mutation/common.rs Outdated Show resolved Hide resolved

luleyleo reviewed Jul 3, 2023

View reviewed changes

src/components/selection/functional.rs Outdated Show resolved Hide resolved

Integrate most remaining review feedback

b52d29e

Integrate missing review feedback

75fa51d

luleyleo approved these changes Jul 5, 2023

View reviewed changes

Saethox mentioned this pull request Jul 5, 2023

Prepare MAHF for crates.io #173

Closed

Saethox merged commit 5d7e4e4 into master Jul 5, 2023

Saethox deleted the state-lenses-and-more branch July 5, 2023 11:27

This was referenced Jul 6, 2023

Individual::evaluate_with does not take a mutable function. #177

Closed

Give Design-by-Contract a try. #152

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Integrate most of the changes from PR #173 #178

Integrate most of the changes from PR #173 #178

Saethox commented Jun 27, 2023 •

edited

Loading

HeleNoir Jun 29, 2023

Saethox Jul 3, 2023

HeleNoir Jun 29, 2023

HeleNoir Jun 29, 2023

Saethox Jul 4, 2023

HeleNoir Jun 29, 2023

Saethox Jul 3, 2023

HeleNoir Jul 5, 2023

HeleNoir left a comment

luleyleo commented Jun 29, 2023

luleyleo left a comment

Saethox commented Jul 1, 2023

HeleNoir commented Jul 3, 2023

Saethox commented Jul 3, 2023 •

edited

Loading

luleyleo commented Jul 3, 2023

luleyleo left a comment

Integrate most of the changes from PR #173 #178

Integrate most of the changes from PR #173 #178

Conversation

Saethox commented Jun 27, 2023 • edited Loading

Changes

New concepts

Identifiers

Lenses

Documentation

Problems

State

Components and Conditions

Logging

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HeleNoir left a comment

Choose a reason for hiding this comment

luleyleo commented Jun 29, 2023

luleyleo left a comment

Choose a reason for hiding this comment

more on lenses

Saethox commented Jul 1, 2023

HeleNoir commented Jul 3, 2023

Saethox commented Jul 3, 2023 • edited Loading

luleyleo commented Jul 3, 2023

luleyleo left a comment

Choose a reason for hiding this comment

Saethox commented Jun 27, 2023 •

edited

Loading

Saethox commented Jul 3, 2023 •

edited

Loading