the quantum theory of inbreeding

Important
there was a bug on main so !133 (merged) needs to be checked out

when running a given recoding strategy inside an environment with a given loss pattern, we would like to get the same measurements for a given time step

$t$

regardless of previous measurements, right?

with the following experiment

const PRNG_SEED = "0000000000000000000000000000000000000000000000000000000000000000"

const OPTS = {
    nb_bytes: (10 * 1_024),
    k: 5,
    n: 20,
    nb_measurements: 10,
    nb_scenarii: 10,
    measurement_schedule: null,    # this will be set later
    measurement_schedule_start: 0,
    max_t: 50,
    strategies: [
        "single:1",
    ],
    environment: "random-fixed:0.5:1",
}

we would like to get the same measurements for any

$t$

regardless of $.measurement_schedule!

quantum measures

however, in the current state of the bins/inbreeding crate, the same mutable rng is used for both the scenario and the measures...

use ./bins/inbreeding
use ./bins/inbreeding/consts.nu CACHE

inbreeding build

let experiment = $"($PRNG_SEED)-($OPTS.environment)-($OPTS.k)-($OPTS.n)-($OPTS.nb_bytes)"

inbreeding run --options ($OPTS | update measurement_schedule 1) --prng-seed $PRNG_SEED
inbreeding load $experiment | reject diversity.e | inbreeding plot --options { k: $OPTS.k } --save /tmp/000_1.1.png
rm -r ($CACHE | path join $PRNG_SEED)

inbreeding run --options ($OPTS | update measurement_schedule 5) --prng-seed $PRNG_SEED
inbreeding load $experiment | reject diversity.e | inbreeding plot --options { k: $OPTS.k } --save /tmp/000_1.2.png
rm -r ($CACHE | path join $PRNG_SEED)

• with a schedule of
  $1$
  
• with a schedule of
  $5$
  

we see that all measurements for any

$t$

where

$t$

is a multiple of

$5$

are different from one run to the other

seeing the path of the RNG

Note
in the following flowcharts,

• labels in the nodes show the state of the RNG: it starts at
  $0$
• labels on the link show the operation: "strta+env" will advance the state of the RNG by
  $1$
  and "measure" will advance it by
  $3$
  , as if there were multiple measures

currently

the path that takes the mutable RNG is the following:

• with a schedule of
  $1$

flowchart LR;
    init((start))
    init -- create rng --> 0;

    0  == measure   ==> 3
    3  -- strat+env --> 4;
    4  == measure   ==> 7
    7  -- strat+env --> 8;
    8  == measure   ==> 11
    11 -- strat+env --> 12;
    12 == measure   ==> 15
    15 -- strat+env --> 16;
    16 == measure   ==> 19;

• with a schedule of
  $2$

flowchart LR;
    init((start))
    init-- create rng -->0;

    0  == measure   ==> 3
    3  -- strat+env --> 4;
    4  -- strat+env --> 5;
    5  == measure   ==> 8
    8  -- strat+env --> 9;
    9  -- strat+env --> 10;
    10 == measure   ==> 13;

Note
we see that the measures influence the state of the RNG and that different measurement schedules will result in different results...

desired behaviour

what we really would like are measurements that do not influence the environment, e.g. with RNG that branches out of the main one

• with a schedule of
  $1$

flowchart LR;
    init((start))
    init -- create rng --> 0;

    0 == measure   ==> 1';
    0 -- strat+env --> 1;
    1 == measure   ==> 2';
    1 -- strat+env --> 2;
    2 == measure   ==> 3';
    2 -- strat+env --> 3;
    3 == measure   ==> 4';
    3 -- strat+env --> 4;
    4 == measure   ==> 5';

• with a schedule of
  $2$

flowchart LR;
    init((start))
    init-- create rng -->0;

    0 == measure   ==> 1';
    0 -- strat+env --> 1;
    1 -- strat+env --> 2;
    2 == measure   ==> 3';
    2 -- strat+env --> 3;
    3 -- strat+env --> 4;
    4 == measure   ==> 5';

Note
we see that, here, the measures do NOT influence the state of the RNG and that different measurement schedules will result in the SAME results!

mentioned in merge request !130 (merged)

changed the description

i've created a branch rng-branching with a crate sharing the same name where i show some results

let's consider the following snippet

cargo run --package rng-branching -- ...[
    -t 10
    --nb-measurements 3
    --measurement-schedule-start 0
    --measurement-schedule $schedule
    --prng-seed "0000000000000000000000000000000000000000000000000000000000000000"
]

Note
in the following, "measurement" lines and the time

$t$

have been omitted for brevity

• running with let schedule = 1

283806532254715438641103320620325336219
81206884938241675898828448293685089547
123964601935091884825232504775228394674
284406681018252490522340331140950135008
85703689343023125787665504916288092148
164580138679377160428399333089130026141
19087608222015339104507127205409595495
308807372251785100552010867183017832184
296672560145027014677796306678600169021
11705409593519411709767015458421390187
41186183280699008755881768423383544768

• running with let schedule = 3

283806532254715438641103320620325336219
126389230668593402136447050683563321604
161568593295957235818501358343383704581
90099576812755920061571028250717398338
30010950376599711846369572565685772009
123964601935091884825232504775228394674
284406681018252490522340331140950135008
186652953085389247658351422588531644666
64731802431096962879021470230485730002
138125047763148648678027006575379776401
275408836722227900364180206703609592169

we see that we start out with the same state 283806532254715438641103320620325336219 but we end up in two completely different ones, 41186183280699008755881768423383544768 and 275408836722227900364180206703609592169 respectively...

mentioned in merge request !133 (merged)

mentioned in commit 3b26bad1

changed the description

mentioned in commit a3a5f2e2

added theory label