Demo of `prng` use for the documentation.

Implements all mathematical basics functions compatible both with clj and cljs compiler and aiming at return the same results.

Calculation of gamma function

Randomness for optimization projects.

Probabilistic distributions.

Exponential distribution based on [inversion method](https://en.wikipedia.org/wiki/Inverse_transform_sampling).

See the [wiki article](https://en.wikipedia.org/wiki/Exponential_distribution).

Factory to create the distribution.

Proxy for kixi-stats distributions.

See the [github repo](https://github.com/MastodonC/kixi.stats).

`(registry)` returns all distributions available in `automaton-optimization`.

They are all implementing the `automaton-optimization.proba.distribution/Distribution` protocol.
Note that you can enrich them with your own distribution implementations if needed.

An uniform distribution, returning a double between `a` and `b`.

An uniform distribution of integers.

PRNG implementation built-in in your platform.

A stateful prng definition.

Statefulness is important to ensure:
* Each call to `rnd` is modifying the state of the prng.
* it is thread safe to use.

Creates a stateful prng based on a stateless one.

Implements PRNG without state.

Use this protocol to wrap some stateless implementations of a `prng`.
To use prng implementing protocol, wraps it again with `PrngStatefulImpl`.

Prng tests.

Adapted from `https://github.com/hugoduncan/criterium/blob/develop/src/criterium/well.clj`.

PRNG stateless implementation based on `xoroshoshiro128` algorithm.

See [xoroshiro128 repo](https://github.com/thedavidmeister/xoroshiro128] for more details.

A sample data stored in memory - a vector.

Functions manipulating set of numbers for probalistic analyzis.

Some functions are inspired from `https://github.com/MastodonC/kixi.stats`.
and optimization tips about `http://hugoduncan.org/criterium/0.4/uberdoc.html`.

Pseudo random number generator.
This protocol hides the complexity of the different random number generator. As many different implementations exists and none superseeds all others.

See [notion page](https://www.notion.so/hephaistox/Pseudo-Random-Number-Generator-1d76651744174b04848c294841e916fc?pvs=4) for the choice of generators.

Contains a list of numerical data

It could be whatever implements the operators: +, *, /, -, 0

`time-based` stores a `value` at a `bucket` in time.

A `tb-var` is a variable than stores one `value` for each `bucket`. You can choose among the following variant `tb-var-additive-deltas`, `tb-var-additive-contiguous`, `tb-var-latest-deltas`, `tb-var-latest-contiguous`, or even build you own as it implements the `opt-tb-protocol`.

The "`bucket`" concept is a natural integer (starting at `0`) representing the time in the internals of the simulation.
![Bucket entity diagram](archi/time_based/bucket.png)

Some `bucket` of a `tb-var` can be grouped in `bucket-aggregate`, note that this `bucket-aggregate` will be seen as the `bucket` of the newly created `tb-var`.
![Bucket aggregate entity diagram](archi/time_based/bucket-aggregate.png)

See `time_based.md` for explanations on the tests.

An `aggregate` is a value object used to define a group of `bucket`s that is homogeneously aggregated in `bucket-aggregate`.

* `start-bucket` is the first `bucket` of the aggregate (`start-bucket ∈ ℕ`).
* `end-bucket` is the last `bucket` concerned with that aggregate - `end-bucket` is excluded - (`end-bucket ∈ ℕ` or `nil`).
* `step` is the number of `bucket`s gathered in that `aggregate`, `step  ∈ ℕ*`

Note that without knowing the other `aggregate` in the `aggregates`, the targeted  `bucket-aggregate` are not fully defined.

![Aggregate entity diagram](archi/time_based/aggregate.png)

Aggregates defines how an `aggregator` will be able to turn a `bucket` into a `bucket-aggregate`.
It is a list of `aggregate` automatically sorted with their `start-bucket`.
This list is used by a `aggregator-item` to create the `aggregator`.

See the [[aggregator]] function, for details about the aggregation rules.

![Aggregates entity diagram](archi/time_based/aggregates.png)

An `aggregator` aggregates `bucket` into `bucket-aggregate` and the way back.

It is composed of `aggregator-item`, matching but completing the data `aggregate`.

![Aggregator entity diagram](archi/time_based/aggregator.png)

An `aggregator-item` enriches an `aggregate` with `start-bucket-aggregate` and `end-bucket-aggregate`.
Many `aggregator-item` are contained in an `aggregator`.

Note that no test mechanisms are here to check values of the `aggregator-item`, the `aggregate` and `aggregates` are here to deal with these tests and are responsible to built some valid `aggregator-item`.

![Aggregator-item entity diagram](archi/time_based/aggregator-item.png)

Strategies to store data in `tb-var`.

Note: `get-exact` and `get-measures` are redundant functionaly but are here to optimize performance.

Stores data in a contiguous data structure.

Adding an element outside the initial capacity will add chunk-size element, plus what's missing to store the element.

Stores data in a collection of time / data pair fashion.

`tb-var` that stores additive informations over time buckets.

* `default-value` is the default value for new or empty buckets, it should be the "`0`".
* If a value is set to an empty bucket, the value is replacing the `default-value`.
* If a value is already stored in that bucket, it will be added to the existing value.
* The values should be numerical to support +.

![Aggregate entity diagram](archi/time_based/tb_var_additive.png)

A `tb-var` storing data through an aggregator.

Note that the storage strategy and the way values are aggregated is the repsonsability of the `tb-var`.

![tb-var-aggregated entity diagram](archi/time_based/tb_var_aggregated.png)

A `tb-var` that stores a measure `m` done at bucket `b` that is true for all subsequent buckets after `b` unless a new measure is done, at a later `bucket`.

* Each update of an already existing value is overwritten.
* The get-measure is returning the value at bucket `b` or the value at the earlier non nil date (as this latest is still available according to this time based).
* The values can be whatever, as no operation is done on it.

For instance, a stock level is such, since a new stock level will be recorded at that moment.
Note that the order of the measures is not significant.

![tb var latest entity diagram](archi/time_based/tb_var_latest.png)

Time-based measures.
This namespace could be used to creates new `time-based` implementation.