13 SS13 Results
| Pos | Car | Code | Time (s) | Gap | Diff |
|---|---|---|---|---|---|
| 1 | 25 | GRY | 854.0 | 37.6 | 15.2 |
| 2 | 22 | LAP | 861.6 | 45.2 | 7.6 |
| 3 | 23 | OST | 863.2 | 46.8 | 1.6 |
| 4 | 24 | SUN | 863.9 | 47.5 | 0.7 |
| 5 | 30 | SOL | 869.9 | 53.5 | 4.5 |
| 6 | 26 | CAM | 875.3 | 58.9 | 5.4 |
| 7 | 21 | BUL | 880.1 | 63.7 | 4.8 |
| 8 | 28 | PRO | 902.6 | 86.2 | 3.0 |
| 9 | 31 | KRI | 919.1 | 102.7 | 1.9 |
13.1 Stage SS13 Splits Analysis
Reports on splits
13.1.1 Split Locations
Length of each split section in km:
| full_split_distances | stage_dist | |
|---|---|---|
| split_1 | 7.95 | 7.95 |
| split_2 | 3.20 | 11.15 |
| split_3 | 3.34 | 14.49 |
| split_4 | 5.68 | 20.17 |
| split_N | 2.20 | 22.37 |
13.1.2 Stage Split Times & Result
Summary of stage split times and overall stage result:
| code | split_1 | split_2 | split_3 | split_4 | split_N | diffFirstS | position |
|---|---|---|---|---|---|---|---|
| GRY | 322.4 | 434.5 | 575.7 | 769.2 | 854.0 | 0.0 | 8 |
| LAP | 324.5 | 437.0 | 580.3 | 775.8 | 861.6 | 7.6 | 9 |
| OST | 326.9 | 439.6 | 582.9 | 778.1 | 863.2 | 9.2 | 10 |
| SUN | 327.0 | 438.4 | 582.6 | 777.6 | 863.9 | 9.9 | 11 |
| SOL | 329.9 | 443.8 | 587.6 | 784.3 | 869.9 | 15.9 | 13 |
| CAM | 330.7 | 444.8 | 589.4 | 788.4 | 875.3 | 21.3 | 14 |
| BUL | 337.6 | 451.5 | 596.8 | 793.6 | 880.1 | 26.1 | 15 |
| PRO | 342.6 | 460.2 | 607.6 | 812.8 | 902.6 | 48.6 | 23 |
| KRI | 341.7 | 463.8 | 616.8 | 826.5 | 919.1 | 65.1 | 28 |
13.1.3 Split Time Rankings
Rank of each split time:
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | 1 | 1 | 1 | 1 | 1 |
| LAP | 2 | 2 | 2 | 2 | 2 |
| OST | 3 | 4 | 4 | 4 | 3 |
| SUN | 4 | 3 | 3 | 3 | 4 |
| SOL | 5 | 5 | 5 | 5 | 5 |
| CAM | 6 | 6 | 6 | 6 | 6 |
| BUL | 7 | 7 | 7 | 7 | 7 |
| PRO | 9 | 8 | 8 | 8 | 8 |
| KRI | 8 | 9 | 9 | 9 | 9 |
Rank on each split section:
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | 1 | 1 | 1 | 1 | 1 |
| LAP | 2 | 2 | 2 | 2 | 2 |
| OST | 3 | 4 | 4 | 4 | 3 |
| SUN | 4 | 3 | 3 | 3 | 4 |
| SOL | 5 | 5 | 5 | 5 | 5 |
| CAM | 6 | 6 | 6 | 6 | 6 |
| BUL | 7 | 7 | 7 | 7 | 7 |
| PRO | 9 | 8 | 8 | 8 | 8 |
| KRI | 8 | 9 | 9 | 9 | 9 |
13.1.4 Split Section Pace
Pace is measured in seconds per kilometer, which is to say, how long it takes to complete each kilometer (lower is better):
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | 40.55 | 35.03 | 42.28 | 34.07 | 38.55 |
| LAP | 40.82 | 35.16 | 42.90 | 34.42 | 39.00 |
| OST | 41.12 | 35.22 | 42.90 | 34.37 | 38.68 |
| SUN | 41.13 | 34.81 | 43.17 | 34.33 | 39.23 |
| SOL | 41.50 | 35.59 | 43.05 | 34.63 | 38.91 |
| CAM | 41.60 | 35.66 | 43.29 | 35.04 | 39.50 |
| BUL | 42.47 | 35.59 | 43.50 | 34.65 | 39.32 |
| PRO | 43.09 | 36.75 | 44.13 | 36.13 | 40.82 |
| KRI | 42.98 | 38.16 | 45.81 | 36.92 | 42.09 |
13.1.5 Ultimate Stage Comparisons
Split time comparisons relative to various ultimage stage time calculations.
These views provide various ways of comparing the performance of each driver to various ghost drivers:
- best recorded split time at each split (ultimate actuals): gives an estimate of how well the driver’s split times compare with each first ranked split time (time into stage at each split);
- fastest time going from one split to the next (ultimate sections): gives an estimate of how quickly each driver completed each split section relative to the quickest time recorded completing that split section (time taken to go from one split point to the next);
- accumulated ultimate sections times: gives and estimate of how quickly the driver is going relative to the fastest possible completion of the stage based on accumulated ultimate split section times.
<IP_ADDRESS> Ultimate Actuals
Driver times compared to the first ranked recorded split time at each split:
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| LAP | 2.1 | 2.5 | 4.6 | 6.6 | 7.6 |
| OST | 4.5 | 5.1 | 7.2 | 8.9 | 9.2 |
| SUN | 4.6 | 3.9 | 6.9 | 8.4 | 9.9 |
| SOL | 7.5 | 9.3 | 11.9 | 15.1 | 15.9 |
| CAM | 8.3 | 10.3 | 13.7 | 19.2 | 21.3 |
| BUL | 15.2 | 17.0 | 21.1 | 24.4 | 26.1 |
| PRO | 20.2 | 25.7 | 31.9 | 43.6 | 48.6 |
| KRI | 19.3 | 29.3 | 41.1 | 57.3 | 65.1 |
| ultimate | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
<IP_ADDRESS> Ultimate Sections
Split durations rebased relative to the fastest transit of each split section:
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | 0.0 | 0.7 | 0.0 | 0.0 | 0.0 |
| LAP | 2.1 | 1.1 | 2.1 | 2.0 | 1.0 |
| OST | 4.5 | 1.3 | 2.1 | 1.7 | 0.3 |
| SUN | 4.6 | 0.0 | 3.0 | 1.5 | 1.5 |
| SOL | 7.5 | 2.5 | 2.6 | 3.2 | 0.8 |
| CAM | 8.3 | 2.7 | 3.4 | 5.5 | 2.1 |
| BUL | 15.2 | 2.5 | 4.1 | 3.3 | 1.7 |
| PRO | 20.2 | 6.2 | 6.2 | 11.7 | 5.0 |
| KRI | 19.3 | 10.7 | 11.8 | 16.2 | 7.8 |
| ultimate | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
<IP_ADDRESS> Ultimate Accumulated Sections
Actual split times relative to the accumulated ultimate split section times:
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | 0.0 | 0.7 | 0.7 | 0.7 | 0.7 |
| LAP | 2.1 | 3.2 | 5.3 | 7.3 | 8.3 |
| OST | 4.5 | 5.8 | 7.9 | 9.6 | 9.9 |
| SUN | 4.6 | 4.6 | 7.6 | 9.1 | 10.6 |
| SOL | 7.5 | 10.0 | 12.6 | 15.8 | 16.6 |
| CAM | 8.3 | 11.0 | 14.4 | 19.9 | 22.0 |
| BUL | 15.2 | 17.7 | 21.8 | 25.1 | 26.8 |
| PRO | 20.2 | 26.4 | 32.6 | 44.3 | 49.3 |
| KRI | 19.3 | 30.0 | 41.8 | 58.0 | 65.8 |
| ultimate | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
13.1.6 Split Section Pace Distribution
Distribution of pace values for each split section:
13.2 Driver Report, SS13 - MIK
No stage report for MIK.
13.3 Driver Report, SS13 - BUL
Stage report for BUL.
| Pos | Car | Code | Time (s) | Gap | Diff |
|---|---|---|---|---|---|
| 8 | 25 | GRY | -26.1 | -26.1 | 15.2 |
| 9 | 22 | LAP | -18.5 | -18.5 | 7.6 |
| 10 | 23 | OST | -16.9 | -16.9 | 1.6 |
| 11 | 24 | SUN | -16.2 | -16.2 | 0.7 |
| 13 | 30 | SOL | -10.2 | -10.2 | 4.5 |
| 14 | 26 | CAM | -4.8 | -4.8 | 5.4 |
| 15 | 21 | BUL | 0.0 | 0.0 | 4.8 |
| 23 | 28 | PRO | 22.5 | 22.5 | 3.0 |
| 28 | 31 | KRI | 39.0 | 39.0 | 1.9 |
13.3.1 Rebased Split Times
BUL’s delta at each split compared to other drivers.
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -15.2 | -17.0 | -21.1 | -24.4 | -26.1 |
| LAP | -13.1 | -14.5 | -16.5 | -17.8 | -18.5 |
| OST | -10.7 | -11.9 | -13.9 | -15.5 | -16.9 |
| SUN | -10.6 | -13.1 | -14.2 | -16.0 | -16.2 |
| SOL | -7.7 | -7.7 | -9.2 | -9.3 | -10.2 |
| CAM | -6.9 | -6.7 | -7.4 | -5.2 | -4.8 |
| BUL | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| PRO | 5.0 | 8.7 | 10.8 | 19.2 | 22.5 |
| KRI | 4.1 | 12.3 | 20.0 | 32.9 | 39.0 |
Accumulated stage time deltas at each split:
13.3.2 Within-Split Duration Deltas
BUL’s delta in time to complete each split section compared to other drivers:
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -15.2 | -1.8 | -4.1 | -3.3 | -1.7 |
| LAP | -13.1 | -1.4 | -2.0 | -1.3 | -0.7 |
| OST | -10.7 | -1.2 | -2.0 | -1.6 | -1.4 |
| SUN | -10.6 | -2.5 | -1.1 | -1.8 | -0.2 |
| SOL | -7.7 | 0.0 | -1.5 | -0.1 | -0.9 |
| CAM | -6.9 | 0.2 | -0.7 | 2.2 | 0.4 |
| BUL | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| PRO | 5.0 | 3.7 | 2.1 | 8.4 | 3.3 |
| KRI | 4.1 | 8.2 | 7.7 | 12.9 | 6.1 |
13.3.3 Within-Split Pace Deltas
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -1.91 | -0.56 | -1.23 | -0.58 | -0.77 |
| LAP | -1.65 | -0.44 | -0.60 | -0.23 | -0.32 |
| OST | -1.35 | -0.37 | -0.60 | -0.28 | -0.64 |
| SUN | -1.33 | -0.78 | -0.33 | -0.32 | -0.09 |
| SOL | -0.97 | 0.00 | -0.45 | -0.02 | -0.41 |
| CAM | -0.87 | 0.06 | -0.21 | 0.39 | 0.18 |
| BUL | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| PRO | 0.63 | 1.16 | 0.63 | 1.48 | 1.50 |
| KRI | 0.52 | 2.56 | 2.31 | 2.27 | 2.77 |
13.4 Driver Report, SS13 - LAP
Stage report for LAP.
| Pos | Car | Code | Time (s) | Gap | Diff |
|---|---|---|---|---|---|
| 8 | 25 | GRY | -7.6 | -7.6 | 15.2 |
| 9 | 22 | LAP | 0.0 | 0.0 | 7.6 |
| 10 | 23 | OST | 1.6 | 1.6 | 1.6 |
| 11 | 24 | SUN | 2.3 | 2.3 | 0.7 |
| 13 | 30 | SOL | 8.3 | 8.3 | 4.5 |
| 14 | 26 | CAM | 13.7 | 13.7 | 5.4 |
| 15 | 21 | BUL | 18.5 | 18.5 | 4.8 |
| 23 | 28 | PRO | 41.0 | 41.0 | 3.0 |
| 28 | 31 | KRI | 57.5 | 57.5 | 1.9 |
13.4.1 Rebased Split Times
LAP’s delta at each split compared to other drivers.
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -2.1 | -2.5 | -4.6 | -6.6 | -7.6 |
| LAP | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| OST | 2.4 | 2.6 | 2.6 | 2.3 | 1.6 |
| SUN | 2.5 | 1.4 | 2.3 | 1.8 | 2.3 |
| SOL | 5.4 | 6.8 | 7.3 | 8.5 | 8.3 |
| CAM | 6.2 | 7.8 | 9.1 | 12.6 | 13.7 |
| BUL | 13.1 | 14.5 | 16.5 | 17.8 | 18.5 |
| PRO | 18.1 | 23.2 | 27.3 | 37.0 | 41.0 |
| KRI | 17.2 | 26.8 | 36.5 | 50.7 | 57.5 |
Accumulated stage time deltas at each split:
13.4.2 Within-Split Duration Deltas
LAP’s delta in time to complete each split section compared to other drivers:
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -2.1 | -0.4 | -2.1 | -2.0 | -1.0 |
| LAP | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| OST | 2.4 | 0.2 | 0.0 | -0.3 | -0.7 |
| SUN | 2.5 | -1.1 | 0.9 | -0.5 | 0.5 |
| SOL | 5.4 | 1.4 | 0.5 | 1.2 | -0.2 |
| CAM | 6.2 | 1.6 | 1.3 | 3.5 | 1.1 |
| BUL | 13.1 | 1.4 | 2.0 | 1.3 | 0.7 |
| PRO | 18.1 | 5.1 | 4.1 | 9.7 | 4.0 |
| KRI | 17.2 | 9.6 | 9.7 | 14.2 | 6.8 |
13.4.3 Within-Split Pace Deltas
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -0.26 | -0.12 | -0.63 | -0.35 | -0.45 |
| LAP | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| OST | 0.30 | 0.06 | 0.00 | -0.05 | -0.32 |
| SUN | 0.31 | -0.34 | 0.27 | -0.09 | 0.23 |
| SOL | 0.68 | 0.44 | 0.15 | 0.21 | -0.09 |
| CAM | 0.78 | 0.50 | 0.39 | 0.62 | 0.50 |
| BUL | 1.65 | 0.44 | 0.60 | 0.23 | 0.32 |
| PRO | 2.28 | 1.59 | 1.23 | 1.71 | 1.82 |
| KRI | 2.16 | 3.00 | 2.90 | 2.50 | 3.09 |
13.5 Driver Report, SS13 - OST
Stage report for OST.
| Pos | Car | Code | Time (s) | Gap | Diff |
|---|---|---|---|---|---|
| 8 | 25 | GRY | -9.2 | -9.2 | 15.2 |
| 9 | 22 | LAP | -1.6 | -1.6 | 7.6 |
| 10 | 23 | OST | 0.0 | 0.0 | 1.6 |
| 11 | 24 | SUN | 0.7 | 0.7 | 0.7 |
| 13 | 30 | SOL | 6.7 | 6.7 | 4.5 |
| 14 | 26 | CAM | 12.1 | 12.1 | 5.4 |
| 15 | 21 | BUL | 16.9 | 16.9 | 4.8 |
| 23 | 28 | PRO | 39.4 | 39.4 | 3.0 |
| 28 | 31 | KRI | 55.9 | 55.9 | 1.9 |
13.5.1 Rebased Split Times
OST’s delta at each split compared to other drivers.
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -4.5 | -5.1 | -7.2 | -8.9 | -9.2 |
| LAP | -2.4 | -2.6 | -2.6 | -2.3 | -1.6 |
| OST | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| SUN | 0.1 | -1.2 | -0.3 | -0.5 | 0.7 |
| SOL | 3.0 | 4.2 | 4.7 | 6.2 | 6.7 |
| CAM | 3.8 | 5.2 | 6.5 | 10.3 | 12.1 |
| BUL | 10.7 | 11.9 | 13.9 | 15.5 | 16.9 |
| PRO | 15.7 | 20.6 | 24.7 | 34.7 | 39.4 |
| KRI | 14.8 | 24.2 | 33.9 | 48.4 | 55.9 |
Accumulated stage time deltas at each split:
13.5.2 Within-Split Duration Deltas
OST’s delta in time to complete each split section compared to other drivers:
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -4.5 | -0.6 | -2.1 | -1.7 | -0.3 |
| LAP | -2.4 | -0.2 | 0.0 | 0.3 | 0.7 |
| OST | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| SUN | 0.1 | -1.3 | 0.9 | -0.2 | 1.2 |
| SOL | 3.0 | 1.2 | 0.5 | 1.5 | 0.5 |
| CAM | 3.8 | 1.4 | 1.3 | 3.8 | 1.8 |
| BUL | 10.7 | 1.2 | 2.0 | 1.6 | 1.4 |
| PRO | 15.7 | 4.9 | 4.1 | 10.0 | 4.7 |
| KRI | 14.8 | 9.4 | 9.7 | 14.5 | 7.5 |
13.5.3 Within-Split Pace Deltas
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -0.57 | -0.19 | -0.63 | -0.30 | -0.14 |
| LAP | -0.30 | -0.06 | 0.00 | 0.05 | 0.32 |
| OST | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| SUN | 0.01 | -0.41 | 0.27 | -0.04 | 0.55 |
| SOL | 0.38 | 0.37 | 0.15 | 0.26 | 0.23 |
| CAM | 0.48 | 0.44 | 0.39 | 0.67 | 0.82 |
| BUL | 1.35 | 0.37 | 0.60 | 0.28 | 0.64 |
| PRO | 1.97 | 1.53 | 1.23 | 1.76 | 2.14 |
| KRI | 1.86 | 2.94 | 2.90 | 2.55 | 3.41 |
13.6 Driver Report, SS13 - SUN
Stage report for SUN.
| Pos | Car | Code | Time (s) | Gap | Diff |
|---|---|---|---|---|---|
| 8 | 25 | GRY | -9.9 | -9.9 | 15.2 |
| 9 | 22 | LAP | -2.3 | -2.3 | 7.6 |
| 10 | 23 | OST | -0.7 | -0.7 | 1.6 |
| 11 | 24 | SUN | 0.0 | 0.0 | 0.7 |
| 13 | 30 | SOL | 6.0 | 6.0 | 4.5 |
| 14 | 26 | CAM | 11.4 | 11.4 | 5.4 |
| 15 | 21 | BUL | 16.2 | 16.2 | 4.8 |
| 23 | 28 | PRO | 38.7 | 38.7 | 3.0 |
| 28 | 31 | KRI | 55.2 | 55.2 | 1.9 |
13.6.1 Rebased Split Times
SUN’s delta at each split compared to other drivers.
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -4.6 | -3.9 | -6.9 | -8.4 | -9.9 |
| LAP | -2.5 | -1.4 | -2.3 | -1.8 | -2.3 |
| OST | -0.1 | 1.2 | 0.3 | 0.5 | -0.7 |
| SUN | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| SOL | 2.9 | 5.4 | 5.0 | 6.7 | 6.0 |
| CAM | 3.7 | 6.4 | 6.8 | 10.8 | 11.4 |
| BUL | 10.6 | 13.1 | 14.2 | 16.0 | 16.2 |
| PRO | 15.6 | 21.8 | 25.0 | 35.2 | 38.7 |
| KRI | 14.7 | 25.4 | 34.2 | 48.9 | 55.2 |
Accumulated stage time deltas at each split:
13.6.2 Within-Split Duration Deltas
SUN’s delta in time to complete each split section compared to other drivers:
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -4.6 | 0.7 | -3.0 | -1.5 | -1.5 |
| LAP | -2.5 | 1.1 | -0.9 | 0.5 | -0.5 |
| OST | -0.1 | 1.3 | -0.9 | 0.2 | -1.2 |
| SUN | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| SOL | 2.9 | 2.5 | -0.4 | 1.7 | -0.7 |
| CAM | 3.7 | 2.7 | 0.4 | 4.0 | 0.6 |
| BUL | 10.6 | 2.5 | 1.1 | 1.8 | 0.2 |
| PRO | 15.6 | 6.2 | 3.2 | 10.2 | 3.5 |
| KRI | 14.7 | 10.7 | 8.8 | 14.7 | 6.3 |
13.6.3 Within-Split Pace Deltas
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -0.58 | 0.22 | -0.90 | -0.26 | -0.68 |
| LAP | -0.31 | 0.34 | -0.27 | 0.09 | -0.23 |
| OST | -0.01 | 0.41 | -0.27 | 0.04 | -0.55 |
| SUN | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| SOL | 0.36 | 0.78 | -0.12 | 0.30 | -0.32 |
| CAM | 0.47 | 0.84 | 0.12 | 0.70 | 0.27 |
| BUL | 1.33 | 0.78 | 0.33 | 0.32 | 0.09 |
| PRO | 1.96 | 1.94 | 0.96 | 1.80 | 1.59 |
| KRI | 1.85 | 3.34 | 2.63 | 2.59 | 2.86 |
13.7 Driver Report, SS13 - GRY
Stage report for GRY.
| Pos | Car | Code | Time (s) | Gap | Diff |
|---|---|---|---|---|---|
| 8 | 25 | GRY | 0.0 | 0.0 | 15.2 |
| 9 | 22 | LAP | 7.6 | 7.6 | 7.6 |
| 10 | 23 | OST | 9.2 | 9.2 | 1.6 |
| 11 | 24 | SUN | 9.9 | 9.9 | 0.7 |
| 13 | 30 | SOL | 15.9 | 15.9 | 4.5 |
| 14 | 26 | CAM | 21.3 | 21.3 | 5.4 |
| 15 | 21 | BUL | 26.1 | 26.1 | 4.8 |
| 23 | 28 | PRO | 48.6 | 48.6 | 3.0 |
| 28 | 31 | KRI | 65.1 | 65.1 | 1.9 |
13.7.1 Rebased Split Times
GRY’s delta at each split compared to other drivers.
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| LAP | 2.1 | 2.5 | 4.6 | 6.6 | 7.6 |
| OST | 4.5 | 5.1 | 7.2 | 8.9 | 9.2 |
| SUN | 4.6 | 3.9 | 6.9 | 8.4 | 9.9 |
| SOL | 7.5 | 9.3 | 11.9 | 15.1 | 15.9 |
| CAM | 8.3 | 10.3 | 13.7 | 19.2 | 21.3 |
| BUL | 15.2 | 17.0 | 21.1 | 24.4 | 26.1 |
| PRO | 20.2 | 25.7 | 31.9 | 43.6 | 48.6 |
| KRI | 19.3 | 29.3 | 41.1 | 57.3 | 65.1 |
Accumulated stage time deltas at each split:
13.7.2 Within-Split Duration Deltas
GRY’s delta in time to complete each split section compared to other drivers:
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| LAP | 2.1 | 0.4 | 2.1 | 2.0 | 1.0 |
| OST | 4.5 | 0.6 | 2.1 | 1.7 | 0.3 |
| SUN | 4.6 | -0.7 | 3.0 | 1.5 | 1.5 |
| SOL | 7.5 | 1.8 | 2.6 | 3.2 | 0.8 |
| CAM | 8.3 | 2.0 | 3.4 | 5.5 | 2.1 |
| BUL | 15.2 | 1.8 | 4.1 | 3.3 | 1.7 |
| PRO | 20.2 | 5.5 | 6.2 | 11.7 | 5.0 |
| KRI | 19.3 | 10.0 | 11.8 | 16.2 | 7.8 |
13.7.3 Within-Split Pace Deltas
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| LAP | 0.26 | 0.12 | 0.63 | 0.35 | 0.45 |
| OST | 0.57 | 0.19 | 0.63 | 0.30 | 0.14 |
| SUN | 0.58 | -0.22 | 0.90 | 0.26 | 0.68 |
| SOL | 0.94 | 0.56 | 0.78 | 0.56 | 0.36 |
| CAM | 1.04 | 0.62 | 1.02 | 0.97 | 0.95 |
| BUL | 1.91 | 0.56 | 1.23 | 0.58 | 0.77 |
| PRO | 2.54 | 1.72 | 1.86 | 2.06 | 2.27 |
| KRI | 2.43 | 3.12 | 3.53 | 2.85 | 3.55 |
13.8 Driver Report, SS13 - CAM
Stage report for CAM.
| Pos | Car | Code | Time (s) | Gap | Diff |
|---|---|---|---|---|---|
| 8 | 25 | GRY | -21.3 | -21.3 | 15.2 |
| 9 | 22 | LAP | -13.7 | -13.7 | 7.6 |
| 10 | 23 | OST | -12.1 | -12.1 | 1.6 |
| 11 | 24 | SUN | -11.4 | -11.4 | 0.7 |
| 13 | 30 | SOL | -5.4 | -5.4 | 4.5 |
| 14 | 26 | CAM | 0.0 | 0.0 | 5.4 |
| 15 | 21 | BUL | 4.8 | 4.8 | 4.8 |
| 23 | 28 | PRO | 27.3 | 27.3 | 3.0 |
| 28 | 31 | KRI | 43.8 | 43.8 | 1.9 |
13.8.1 Rebased Split Times
CAM’s delta at each split compared to other drivers.
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -8.3 | -10.3 | -13.7 | -19.2 | -21.3 |
| LAP | -6.2 | -7.8 | -9.1 | -12.6 | -13.7 |
| OST | -3.8 | -5.2 | -6.5 | -10.3 | -12.1 |
| SUN | -3.7 | -6.4 | -6.8 | -10.8 | -11.4 |
| SOL | -0.8 | -1.0 | -1.8 | -4.1 | -5.4 |
| CAM | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| BUL | 6.9 | 6.7 | 7.4 | 5.2 | 4.8 |
| PRO | 11.9 | 15.4 | 18.2 | 24.4 | 27.3 |
| KRI | 11.0 | 19.0 | 27.4 | 38.1 | 43.8 |
Accumulated stage time deltas at each split:
13.8.2 Within-Split Duration Deltas
CAM’s delta in time to complete each split section compared to other drivers:
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -8.3 | -2.0 | -3.4 | -5.5 | -2.1 |
| LAP | -6.2 | -1.6 | -1.3 | -3.5 | -1.1 |
| OST | -3.8 | -1.4 | -1.3 | -3.8 | -1.8 |
| SUN | -3.7 | -2.7 | -0.4 | -4.0 | -0.6 |
| SOL | -0.8 | -0.2 | -0.8 | -2.3 | -1.3 |
| CAM | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| BUL | 6.9 | -0.2 | 0.7 | -2.2 | -0.4 |
| PRO | 11.9 | 3.5 | 2.8 | 6.2 | 2.9 |
| KRI | 11.0 | 8.0 | 8.4 | 10.7 | 5.7 |
13.8.3 Within-Split Pace Deltas
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -1.04 | -0.62 | -1.02 | -0.97 | -0.95 |
| LAP | -0.78 | -0.50 | -0.39 | -0.62 | -0.50 |
| OST | -0.48 | -0.44 | -0.39 | -0.67 | -0.82 |
| SUN | -0.47 | -0.84 | -0.12 | -0.70 | -0.27 |
| SOL | -0.10 | -0.06 | -0.24 | -0.40 | -0.59 |
| CAM | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| BUL | 0.87 | -0.06 | 0.21 | -0.39 | -0.18 |
| PRO | 1.50 | 1.09 | 0.84 | 1.09 | 1.32 |
| KRI | 1.38 | 2.50 | 2.51 | 1.88 | 2.59 |
13.9 Driver Report, SS13 - VEI
No stage report for VEI.
13.10 Driver Report, SS13 - PRO
Stage report for PRO.
| Pos | Car | Code | Time (s) | Gap | Diff |
|---|---|---|---|---|---|
| 8 | 25 | GRY | -48.6 | -48.6 | 15.2 |
| 9 | 22 | LAP | -41.0 | -41.0 | 7.6 |
| 10 | 23 | OST | -39.4 | -39.4 | 1.6 |
| 11 | 24 | SUN | -38.7 | -38.7 | 0.7 |
| 13 | 30 | SOL | -32.7 | -32.7 | 4.5 |
| 14 | 26 | CAM | -27.3 | -27.3 | 5.4 |
| 15 | 21 | BUL | -22.5 | -22.5 | 4.8 |
| 23 | 28 | PRO | 0.0 | 0.0 | 3.0 |
| 28 | 31 | KRI | 16.5 | 16.5 | 1.9 |
13.10.1 Rebased Split Times
PRO’s delta at each split compared to other drivers.
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -20.2 | -25.7 | -31.9 | -43.6 | -48.6 |
| LAP | -18.1 | -23.2 | -27.3 | -37.0 | -41.0 |
| OST | -15.7 | -20.6 | -24.7 | -34.7 | -39.4 |
| SUN | -15.6 | -21.8 | -25.0 | -35.2 | -38.7 |
| SOL | -12.7 | -16.4 | -20.0 | -28.5 | -32.7 |
| CAM | -11.9 | -15.4 | -18.2 | -24.4 | -27.3 |
| BUL | -5.0 | -8.7 | -10.8 | -19.2 | -22.5 |
| PRO | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| KRI | -0.9 | 3.6 | 9.2 | 13.7 | 16.5 |
Accumulated stage time deltas at each split:
13.10.2 Within-Split Duration Deltas
PRO’s delta in time to complete each split section compared to other drivers:
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -20.2 | -5.5 | -6.2 | -11.7 | -5.0 |
| LAP | -18.1 | -5.1 | -4.1 | -9.7 | -4.0 |
| OST | -15.7 | -4.9 | -4.1 | -10.0 | -4.7 |
| SUN | -15.6 | -6.2 | -3.2 | -10.2 | -3.5 |
| SOL | -12.7 | -3.7 | -3.6 | -8.5 | -4.2 |
| CAM | -11.9 | -3.5 | -2.8 | -6.2 | -2.9 |
| BUL | -5.0 | -3.7 | -2.1 | -8.4 | -3.3 |
| PRO | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| KRI | -0.9 | 4.5 | 5.6 | 4.5 | 2.8 |
13.10.3 Within-Split Pace Deltas
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -2.54 | -1.72 | -1.86 | -2.06 | -2.27 |
| LAP | -2.28 | -1.59 | -1.23 | -1.71 | -1.82 |
| OST | -1.97 | -1.53 | -1.23 | -1.76 | -2.14 |
| SUN | -1.96 | -1.94 | -0.96 | -1.80 | -1.59 |
| SOL | -1.60 | -1.16 | -1.08 | -1.50 | -1.91 |
| CAM | -1.50 | -1.09 | -0.84 | -1.09 | -1.32 |
| BUL | -0.63 | -1.16 | -0.63 | -1.48 | -1.50 |
| PRO | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| KRI | -0.11 | 1.41 | 1.68 | 0.79 | 1.27 |
13.11 Driver Report, SS13 - LIN
No stage report for LIN.
13.12 Driver Report, SS13 - SOL
Stage report for SOL.
| Pos | Car | Code | Time (s) | Gap | Diff |
|---|---|---|---|---|---|
| 8 | 25 | GRY | -15.9 | -15.9 | 15.2 |
| 9 | 22 | LAP | -8.3 | -8.3 | 7.6 |
| 10 | 23 | OST | -6.7 | -6.7 | 1.6 |
| 11 | 24 | SUN | -6.0 | -6.0 | 0.7 |
| 13 | 30 | SOL | 0.0 | 0.0 | 4.5 |
| 14 | 26 | CAM | 5.4 | 5.4 | 5.4 |
| 15 | 21 | BUL | 10.2 | 10.2 | 4.8 |
| 23 | 28 | PRO | 32.7 | 32.7 | 3.0 |
| 28 | 31 | KRI | 49.2 | 49.2 | 1.9 |
13.12.1 Rebased Split Times
SOL’s delta at each split compared to other drivers.
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -7.5 | -9.3 | -11.9 | -15.1 | -15.9 |
| LAP | -5.4 | -6.8 | -7.3 | -8.5 | -8.3 |
| OST | -3.0 | -4.2 | -4.7 | -6.2 | -6.7 |
| SUN | -2.9 | -5.4 | -5.0 | -6.7 | -6.0 |
| SOL | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| CAM | 0.8 | 1.0 | 1.8 | 4.1 | 5.4 |
| BUL | 7.7 | 7.7 | 9.2 | 9.3 | 10.2 |
| PRO | 12.7 | 16.4 | 20.0 | 28.5 | 32.7 |
| KRI | 11.8 | 20.0 | 29.2 | 42.2 | 49.2 |
Accumulated stage time deltas at each split:
13.12.2 Within-Split Duration Deltas
SOL’s delta in time to complete each split section compared to other drivers:
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -7.5 | -1.8 | -2.6 | -3.2 | -0.8 |
| LAP | -5.4 | -1.4 | -0.5 | -1.2 | 0.2 |
| OST | -3.0 | -1.2 | -0.5 | -1.5 | -0.5 |
| SUN | -2.9 | -2.5 | 0.4 | -1.7 | 0.7 |
| SOL | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
| CAM | 0.8 | 0.2 | 0.8 | 2.3 | 1.3 |
| BUL | 7.7 | 0.0 | 1.5 | 0.1 | 0.9 |
| PRO | 12.7 | 3.7 | 3.6 | 8.5 | 4.2 |
| KRI | 11.8 | 8.2 | 9.2 | 13.0 | 7.0 |
13.12.3 Within-Split Pace Deltas
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -0.94 | -0.56 | -0.78 | -0.56 | -0.36 |
| LAP | -0.68 | -0.44 | -0.15 | -0.21 | 0.09 |
| OST | -0.38 | -0.37 | -0.15 | -0.26 | -0.23 |
| SUN | -0.36 | -0.78 | 0.12 | -0.30 | 0.32 |
| SOL | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |
| CAM | 0.10 | 0.06 | 0.24 | 0.40 | 0.59 |
| BUL | 0.97 | 0.00 | 0.45 | 0.02 | 0.41 |
| PRO | 1.60 | 1.16 | 1.08 | 1.50 | 1.91 |
| KRI | 1.48 | 2.56 | 2.75 | 2.29 | 3.18 |
13.13 Driver Report, SS13 - KRI
Stage report for KRI.
| Pos | Car | Code | Time (s) | Gap | Diff |
|---|---|---|---|---|---|
| 8 | 25 | GRY | -65.1 | -65.1 | 15.2 |
| 9 | 22 | LAP | -57.5 | -57.5 | 7.6 |
| 10 | 23 | OST | -55.9 | -55.9 | 1.6 |
| 11 | 24 | SUN | -55.2 | -55.2 | 0.7 |
| 13 | 30 | SOL | -49.2 | -49.2 | 4.5 |
| 14 | 26 | CAM | -43.8 | -43.8 | 5.4 |
| 15 | 21 | BUL | -39.0 | -39.0 | 4.8 |
| 23 | 28 | PRO | -16.5 | -16.5 | 3.0 |
| 28 | 31 | KRI | 0.0 | 0.0 | 1.9 |
13.13.1 Rebased Split Times
KRI’s delta at each split compared to other drivers.
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -19.3 | -29.3 | -41.1 | -57.3 | -65.1 |
| LAP | -17.2 | -26.8 | -36.5 | -50.7 | -57.5 |
| OST | -14.8 | -24.2 | -33.9 | -48.4 | -55.9 |
| SUN | -14.7 | -25.4 | -34.2 | -48.9 | -55.2 |
| SOL | -11.8 | -20.0 | -29.2 | -42.2 | -49.2 |
| CAM | -11.0 | -19.0 | -27.4 | -38.1 | -43.8 |
| BUL | -4.1 | -12.3 | -20.0 | -32.9 | -39.0 |
| PRO | 0.9 | -3.6 | -9.2 | -13.7 | -16.5 |
| KRI | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
Accumulated stage time deltas at each split:
13.13.2 Within-Split Duration Deltas
KRI’s delta in time to complete each split section compared to other drivers:
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -19.3 | -10.0 | -11.8 | -16.2 | -7.8 |
| LAP | -17.2 | -9.6 | -9.7 | -14.2 | -6.8 |
| OST | -14.8 | -9.4 | -9.7 | -14.5 | -7.5 |
| SUN | -14.7 | -10.7 | -8.8 | -14.7 | -6.3 |
| SOL | -11.8 | -8.2 | -9.2 | -13.0 | -7.0 |
| CAM | -11.0 | -8.0 | -8.4 | -10.7 | -5.7 |
| BUL | -4.1 | -8.2 | -7.7 | -12.9 | -6.1 |
| PRO | 0.9 | -4.5 | -5.6 | -4.5 | -2.8 |
| KRI | 0.0 | 0.0 | 0.0 | 0.0 | 0.0 |
13.13.3 Within-Split Pace Deltas
| code | split_1 | split_2 | split_3 | split_4 | split_N |
|---|---|---|---|---|---|
| GRY | -2.43 | -3.12 | -3.53 | -2.85 | -3.55 |
| LAP | -2.16 | -3.00 | -2.90 | -2.50 | -3.09 |
| OST | -1.86 | -2.94 | -2.90 | -2.55 | -3.41 |
| SUN | -1.85 | -3.34 | -2.63 | -2.59 | -2.86 |
| SOL | -1.48 | -2.56 | -2.75 | -2.29 | -3.18 |
| CAM | -1.38 | -2.50 | -2.51 | -1.88 | -2.59 |
| BUL | -0.52 | -2.56 | -2.31 | -2.27 | -2.77 |
| PRO | 0.11 | -1.41 | -1.68 | -0.79 | -1.27 |
| KRI | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 |


"Christmas 1996...." Across: 1. Sounds like you will ruin diet at Christmas! (8) 5,24dn. Pickwick's acquaintance rings to warn of approach of 9 (6 5) 9. Santa's team reported precipitation in East End (8) 10. He takes Common Market info East (6) 12. Stirred teas from the Orient (4) 13. Rigid Tom Brown could be in charge after exercises (10) 15. Political forums to discuss trifles? (5 8) 19. see 25 23. How snowman was rejected by Ancient Order Of Snowmen? (10) 25,19. Carol's look-out man saw Nick's one old egg shattered! (4 4 9) 28. Spanish shout about river bird (6) 29. Ms Houston livens up dinner! (8) 30. Very red Senate officials initially led by First Lady (4 2) 31. Old records of use to caterers (8) Down: 1. Son for Queen in difficult delivery (6) 2. Newcomer uncovers hiding places (5) 3. Considerable portion of tart I'd yearn to eat (4) 4. Visitor is in journal about food and drink (7) 6. Get used to being at home by river (5) 7. Seasons these for Christmas cheer! (9) 8. Use last bit of silver in tax (8) 11. Let them eat this after Christmas (4) 14. Second line may be furrowed (4) 15. Piper's son embraced by wandering pieman at New Year entertainment (9) 16. Raincoat reversed keeps water in! (3) 17. Lean bird flies round lion's head (4) 18. Runners cut east to Snow Hill (3 5) 20. 49 go through Tyneside to river (4) 21. Never-ending relevant shake-up throws out five (7) 22. Notices mother within spooky family (6) 24. see 5 26. Girl in swirls of voile (5) 27. Others make a break (4)


Test that in all browsers and in IE7+ mode, width is equal to the clientWidth (the inner width).
In IE 6 and older width is equal to the offsetWidth (the outer width).


Create an account to gain access to my FITT Programs, a variety of Meal Plans and additional features to help you meet your fitness goals.
Already have an account? Click here.


Every call to MPI_RECV includes a status argument, wherein the system can return details about the message received. There are also a number of other MPI calls, particularly in MPI-2, where status is returned. An object of type MPI_STATUS is not an MPI opaque object; its structure is declared in mpi.h and mpif.h, and it exists in the user's program. In many cases, application programs are constructed so that it is unnecessary for them to examine the status fields. In these cases, it is a waste for the user to allocate a status object, and it is particularly wasteful for the MPI implementation to fill in fields in this object.
To cope with this problem, there are two predefined constants, MPI_STATUS_IGNORE and MPI_STATUSES_IGNORE, which when passed to a receive, wait, or test function, inform the implementation that the status fields are not to be filled in. Note that MPI_STATUS_IGNORE is not a special type of MPI_STATUS object; rather, it is a special value for the argument. In C one would expect it to be NULL, not the address of a special MPI_STATUS.
MPI_STATUS_IGNORE, and the array version MPI_STATUSES_IGNORE, can be used everywhere a status argument is passed to a receive, wait, or test function. MPI_STATUS_IGNORE cannot be used when status is an IN argument. Note that in Fortran MPI_STATUS_IGNORE and MPI_STATUSES_IGNORE are objects like MPI_BOTTOM (not usable for initialization or assignment). See Section Named Constants .
In general, this optimization can apply to all functions for which status or an array of statuses is an OUT argument. Note that this converts status into an INOUT argument. The functions that can be passed MPI_STATUS_IGNORE are all the various forms of MPI_RECV, MPI_TEST, and MPI_WAIT, as well as MPI_REQUEST_GET_STATUS. When an array is passed, as in the ANY and ALL functions, a separate constant, MPI_STATUSES_IGNORE, is passed for the array argument. It is possible for an MPI function to return MPI_ERR_IN_STATUS even when MPI_STATUS_IGNORE or MPI_STATUSES_IGNORE has been passed to that function.
MPI_STATUS_IGNORE and MPI_STATUSES_IGNORE are not required to have the same values in C and Fortran.
It is not allowed to have some of the statuses in an array of statuses for _ANY and _ALL functions set to MPI_STATUS_IGNORE; one either specifies ignoring all of the statuses in such a call with MPI_STATUSES_IGNORE, or none of them by passing normal statuses in all positions in the array of statuses.
There are no C++ bindings for MPI_STATUS_IGNORE or MPI_STATUSES_IGNORE. To allow an OUT or INOUT MPI::Status argument to be ignored, all MPI C++ bindings that have OUT or INOUT MPI::Status parameters are overloaded with a second version that omits the OUT or INOUT MPI::Status parameter.
ExampleThe C++ bindings for MPI_PROBE are:
void MPI::Comm::Probe(int source, int tag, MPI::Status& status) const
void MPI::Comm::Probe(int source, int tag) const


I am a biologist who likes nature, reading, science and programming.
Becoming a scientist was my dream since childhood, as I wanted to make discoveries and help save the rainforests. I never actually knew how to get there, but I started studying Biology and after several years I managed to be a scientist indeed.
My path in science took me into quite different research fields, namely from botany, systematics and ecology to clinical trials, mental health and epigenetics. My passion for science and computers made me who I am now.
So, here is my website. Here you may find relevant information about my work, but also other stuff too. On the next pages, take a look at my projects and collaborations. Further, I have a list of different information sources and software for data analyses. If you are interested in my work or if you need support on your research/study, please contact me by e-mail.
You can see my CV here


Installation Go to demo spin.webkom.co/react
- Make sure you have NodeJS >= 6.0.0 installed on your machine.
- Go to folder with app /SPIN-React
- Run npm install to install nescessary NPM dependecies
Usage
- npm start - start development mode with Hot Reloading enabled
- npm run deploy:prod - compile source to the dist directory
Plugins Used Libraries
General
- React ^15.0.0 - Cornerstone rendering engine for the application
- React Bootstrap ^0.30.7 - Port of Bootstrap 3 for React
- Font Awesome ^4.6.3 - Large set of various icons
- React Router ^2.2.0 - Provides routing within the application
- Redux ^3.0.0 - Used for application state management
- Velocity Animate ^1.2.3 - Provides a solid animation system for some components
- React Image Holder ^2.0.1 - Adds placeholder support for the Image component
- IsMobile ^0.4.0 - Detects the device on which the application is running, so some components can adjust to the environment
- Moment ^2.13.0 - Used for time modification and parsing
- Numeral ^1.5.3 - Provides formatting for number types
- PerfectScrollbar ^0.6.13 - Wrapped in a component, which adds styled scrollbars when nescessary
- Pace 1.0.2 - Page loading indicator used mainly when a Webpack Code Split needs to be loaded
- TinyColor ^1.4.1 - Fast color mixing library used in some components
- Underscore ^1.8.3 - Flexible functional data manegement library
Charts
- React Highcharts ^8.3.3 - Provides Highcharts support.
- React Sparklines ^1.5.2 - Adds small charts called Sparklines. It is extended by a custom component for additional features.
- React Chartist ^0.10.2 - Adds Chartist support.
Build
- Koa ^2.0.0-alpha.3 - Web Server used for serving the application.
- Webpack ^1.12.14 - Advanced system used for modules management. It is backed by a multitude of smaller loaders which add nescessary functionalities.
- Sass Loader ^3.0.0 - Webpack loader which allows the usage of SCSS modules.
- Babel ^6.3.19 - Provides support for ES2015+ and JSX
Demo
These libraries are used to generate random data state trees to use in Containers for demonstration purposes.
- Faker ^3.1.0 - Generate fake demo data
- deep-assign ^2.0.0 - Recursive
Object.assign()
- helps building complex data trees
Reusable Components 1.0
Layout
It is the main parent of the application. Provides interaction between child elements, and handles visual styling for them.
- navbarEnabled<bool> - Is the Navbar visible (Default: true)
- navbarFixed<bool> - Should the Navbar stick to the top edge of the screen (Default: false)
- sidebarEnabled<bool> - Is the Sidebar visible (Default: true)
- sidebarStyle<string> - (Available options: default, slim, bigicons). Style of the Sidebar (Default: default)
- sidebarFixed<bool> - Should the Sidebar stick to the top edge of the screen (Default: false)
- sidebarAside<bool> - Should the Sidebar be in “Aside mode” - full height of the viewport (Default: false)
- contentView<string> - (Available oprions: static, fluid, boxed) How the content should be displayed (Default: fluid)
- footerEnabled<bool> - Is the Footer visible (Default: true)
- footerFixed<bool> - Should the Footer stick to the bottom edge of the screen (Default: false)
- rightSidebarEnabled<bool> - Is the Right Sidebar visible (Default: true)
- headerEnabled<bool> - Is the Content Header visible (Default: true)
- headerStyle<string> - (Available options: simple, breadcrumbs) simple - shows only the current page title; breadcrumbs - additionally shows nested breadcrumbs (Default: ‘breadcrumbs’)
- skinColor<string> - (Available options: primary, success, info, warning, danger) - The theme color which is used in the Sidebar and Navbar
- sidebarSkin<string> - (Available options: dark, light, color) - Determines the skin of the Sidebar (Default: dark)
- navbarSkin<string> - (Available options: dark, light, color) - Determines the skin of the Navbar (Default: dark)
Layout.Navigation
Parent of the main navigation items - Navbar and Sidebar
Layout.Content
The content of the page should be rendered here
AffixWrap
Watches the scroll position and applies affix classes to the provided child
Props:
- offset<number> - Offset from top when the Affix should be activated
- affixAdditionalClass<string> - Class next to affix which will be added to the child if Affixed
- affixTopAdditionalClass<string> - Class next to affix-top which will be added tot he child if not Affixed
Avatars
General Props:
- size<string> - (Available options: large, default, small) Size of the Avatar
- type<string> - (Available options: circle, rounded) Shape of the Avatar
- showStatus<bool> - Should the status icon be shown
- statusColor<string> - Color of the status icon
- statusBorderColor<string> - Border color of the status icon (Default: gray-darker)
- statusPlacement<string> - (Available options: top, bottom) Placement of the status icon
- info<node> - The info element, should be a Badge or a Label
Child Components (use these)
AvatarImage - Embedds an Avatar with an Image provided in src property. If the src param won’t be valid or there while loading the file - a configurable placeholder will be rendered.
Props:
- src<string> - Source Image URL
- placeholder<node> - Placeholder item which will be displayed if the Image fails to load. (Default: )
- phColor<string> - Color of the Placeholder (Default: Colors.grayLight)
- phBackgroundColor<string> - Background COlor of the Placeholder (Default: Colors.grayDark)
AvatarText - Embedds an Avatar with a Text or Icon inside.
Props:
- backgroundColor<string> - Background Color (Default: Colors.brandPrimary)
- color<string> - Font Color (Default: white)
- children<node> - Text to display inside the Avatar
AvatarIcon - Embedds an Avatar with an Icon inside
Props:
- backgroundColor<string> - Background Color (Default: Colors.brandPrimary)
- color<string> - Icon Color (Default: white)
- children<node> - Icon to display inside the Avatar
Tabs
Extended Tabs from ReactBootstrap.
Additional Props:
- bsStyle<string> - (Available options: default, highlight) defines the style of the Tabs
Alerts
Extended Alert from ReactBootstrap.
Additional Props:
- noBackground<bool> - Setting to true will make the Alert box without background, with a border accent on the Left side. Accent color will be set accordingly to the bsStyle prop.
Badges
Extended Badge from ReactBootstrap.
Additional Props:
- outline<bool> - Creates an outline version of the Badge
- withIcon<bool> - Adjusts the Badge position so that it can be placed next to an FontAwesome icon
- bsStyle<string> - (Available options: primary, success, info, warning, danger) Adds color to the badge
Breadcrumbs
Extended Breadcrumb from ReactBootstrap.
Additional Props:
- noBackground<bool> - Background is disabled
Buttons
Extended Button from ReactBootstrap.
Additional Props:
- outline<bool> - the button can be in an outline only style with transparent background (Default: false)
- bsStyle<string> - now can accepts custom, which will apply the custom color
- customColor<string> - color to apply when bsStyle is set to custom
Dividers
Creates a section separator with a Header inside. _Note: Might have issues when used on a non-standard background. _
Props:
- textPosition<string> - (Available options: left<d>, center, right) Determines where the header should be placed horizonatly within the line.
- componentClass<string> - Determines which HTML element should be used for the header. Default: h6
Favorite Star
Renders a two-state(on/off) Favorite Star, with hint Tooltip attached, and “Favorited” event handler.
Additional Props:
- favorited<bool> - Determines if the Star is On
- onFavorited<func> - Basically a click event handler
- tooltipTextActive<string> - Text which will be visible in the tooltip if the component is in On state (Default: Remove from favorites)
- tooltipTextInActive<string> - Text which will be visible in the tooltip if the component is in Off state (Default: Add to favorites)
- tooltipPlacement<string> - (Available options: top, bottom, left, right) On which side of the Star the Tooltip should be rendered (Default: top)
Footer
Bottom part of the main layout.
Props:
- fluid<bool> - Should there be a fluid container inside
Images
Advanced Image component with support for Placeholders. If src prop is blank, invalid or the Image has failed to load, a desired Placeholder will be rendered. Supports Icons or HolderJs
Props:
- src<string> - URL of the image to be rendered
- phIcon<node> - A placeholder icon element (i.e. FontAwesome). Will be rendered if image has failed to load, if none provided, HolderJs will be attached
- phForegroundColor<string> - Foreground color of the Placeholder (Default: Colors.grayLight)
- phBackgroundColor<string> - Background color of the Placeholder (Default: #fff)
- alt<string> - The alt description which will be attached to the image
- shape<string> - (Available options: default<d>, rounded, circle) Rounds the corner of the image or transforms it into a circle
- width<string/number> - Width of the image, can be a CSS value string (i.e. 75px, 100%) or a number in pixels
- height<string/number> - Height of the image, can be a CSS value string (i.e. 75px, 100%) or a number in pixels (Default: 100px)
- block<bool> - Should the image be rendered as a block element (Default: false)
Labels
Extended Label from ReactBootstrap.
Additional Props:
- outline<bool> - Creates an outline version of the Label
- withIcon<bool> - Adjusts the Label position so that it can be placed next to an FontAwesome icon
- pill<bool> - Makes the Label Pill shaped
- customColor<string> - Accepts a color definition. Available only if bsStyle is set to custom
Modals
Extended Modal from ReactBootstrap.
Additional Props:
- bsStyle<string> - (Available options: primary, success, info, warning, danger) Adds a colored border to the modal, indicating the modal purpose.
Navbars
Standard Navbar from ReactBootstrap, extended by couple of SubComponents.
Navbar.Menu
Full-width navigation Menu. Has to have Navbar.MenuSection components inside which correspond to /routes/routesStructure.js using the slug property. Has to be placed in a Nav.
Props:
- title<string> - Title of the Nav Button (Default: Menu)
- currentPath<string> - current URL, should be connected with React Router
Navbar.MenuSection
Renders a section in the menu, with a title and links inside.
Props:
- slug<string> - Slug of the section from /routes/routesStructure.js
Navbar.DropdownList
A special Nav Dropdown which is build of a header, list and a footer.
Props:
- header<node> - Element which will be placed at the beginning of the Dropdown, flex spece-between will be applied automatically to separate the title from potential options
- footer<node/string> - Text or element rendered at the end of the list
- footerUrl<string> - Optional URL wrapping the Footer
- listHeight<number/string> - Maximum height of the list (Default: 250 (px))
- width<number/string> - Width of the list on devices greater than XS (Default: 350 (px))
OutsideClick
Fires the provided EventHandler when User clicks outside of the provided child element.
Props:
- onClickOutside<func> - EventHandler called when clicked outside
- excludedElements<array> - Array of elements which will be ommited from the click-test. Mostly usable for trigger buttons
- active<bool> - Is the detection mechanism active (Default: true)
Panels
Extended Panel from ReactBootstrap.
Additional Props:
-
flexHeader<bool> - Header children will be moved to the edges of the Panel (Applies flex space-between no-wrap)
-
maxHeight<number> - When provided, the Body’s max-height will be set to this value, additionally a custom scroll will be initialized inside the Panel Body
-
flexHeader<bool>- Body and Footer will fill the whole Panel space, omitting the parent’s padding
-
fullBody<bool> - Removes the internal padding
-
background<string> - (Available options: null, light, gray) Sets the panel background, set to null if no background should be applied. (Default: null)
-
borderStyle - (Available options: thin, normal, thick). Sets the border width to 1px, 2px and 3px sequentially. (Default: 'normal`)
-
bsStyle<string> - Provides context color to the panel
-
type<string> - Applies one of 6 panel visual types (Default: null)
Available options:
- color-border-full - whole panel border in context color
- color-border-left - left panel border in context color
- color-border-top - top panel border in context color
- color-border-heading - bottom header border in context color
- color-title - header background in context color
- color-title-border - header background and whole panel border in context color
CollapsablePanel
A Panel (see above) which can be collapsed (Body and Footer collapsing with animation) or disabled via additional options in the Panel Header.
Props:
- collapsed<bool> - Determines if the Body and Footer are collapsed (Default: false)
- title<string> - Panel Title placed in the header
- footer<node> - Element placed in the Panel’s footer
- fill<bool> - Makes the Panel Body render without padding
- onCollapse<func> - Callback fired when the Panel starts collapsing
- onClose<func> - Callback fired when the Disable Option is clicked
RightSidebar
Right Sidebar for some less important content available at any time.
Props:
- active<bool> - Should the sidebar be visible (Default: false)
- affixOffset<number> - Offset on which the sidebar should be affixed (sticky) (Default: 0)
- children<node> - Content of the Right Sidebar
RightSidebar.OverlayContent
Additional container which can be overlayed over the RightSidebar. Use RightSidebar.OverlayContentParent for appropriate position adjustment.
Props:
- active<bool> - Should the overlay be visible (Default: false)
- children<node> The actual content
RightSidebar.OverlayContentParent
The parent of the content. RightSidebar.OverlayContent will be relative to this Component.
Props:
- children<node> - Mixed HTML with RightSidebar.OverlayContent
Sidebars
Sidebar element which can contain Sidebar.Menu for navigation and Sidebar.Addons which are extra content elements adjustable for different sidebar styles: default, slim, big-icons.
Props:
- affixOffset<number> - Offset on which the sidebar should be affixed (sticky) (Default: 0)
- header<node> - Header elements shown on Overlayed version on mobile
- overlay<bool> - Should the sidebar be an overlay, Typically this would be set when Screen Size is XS (Default: false)
- overlayVisible<bool> - When Overlay Mode is on, should the Sidebar be shown (Default: false)
- `overlayAnimationDuration<number> - How long the show/hide animation should be (Default: 300)
- overlayAnimationEasingOpen<string> - (Available: CSS3 easings) Easing type used for the opening animation
- overlayAnimationEasingClose<string> - (Available: CSS3 easings) Easing type used for the closing animation
- onOverlayClosed<func> - Callback triggered when the Overlay will finish closing
- onHeightChange<func> - Callback triggered when the Menus inside will open or close. Additional height (more than default Sidebar Height) is passed in the first argument
Sidebar.Menu
Navigation in the sidebar. Gets all the available routes from /routes/routesStructure.
Props:
- currentUrl<string> - Current page URL, should be attached to ReactRouter
- animationDuration<number> - Open/close node animation duration
- animationEasing<string> - (Available: CSS3 easings) Open/close node animation easing
Sidebar.AddOn
Additional content element which can be placed within the Sidebar. It should be composed of Sidebar.AddOnContents which are being enabled/disabled accordingly to the current sidebar style.
Props:
- children - List of AddOnContents
Sidebar.AddOnContent
The content of the AddOn which will be displayed when current Sidebar Style matches the supportedStyle prop.
Props:
- supportedStyle<array/string> - (Available: default, slim, big-icons) On which SidebarStyle this container should be visible
Star Rating
Rating component which can be used for showing rating with Star Icons, aswell as returning Rating from user click.
Props:
- max<number> - Determines how many Stars are there total (Default: 5)
- at<number> - Determines what is the current rating, which renders highlighted stars (Default: 0)
- starColor<string> - Color of the active stars (Default: Colors.brandWarning)
- onSelect<func> - When provided, it will be called when a user click on any of the star. Attached argument indicates which star in order was clicked (1 - max)
Progress Bars
Alternative version of React Bootstrap ProgressBar with 3 different heights available.
Props:
- size<string> - (Available options: small<d>, medium, large) Size of the Bar - respectively: 3px, 6px and 9px
Scroll Bar Container
Adds a container with PerfectScrollbar attached. Initializes only when not on OSX nor mobile device.
Props:
- notRelative<bool> - Prevents adding position: relative to the container which is needed by PerfectScrollbar. Use when the container has to be position:absolute (Default: false)
- componentClass<string> - What kind of HTML element should be used for the container (Default: ‘div’)
- noXScrollBar<bool> - Disables the horizontal Scroll Bar (Default: false)
- noYScrollBar<bool> - Disables the vertical Scroll Bar (Default: false)
- dynamicChildren<bool> - Adds a mutation observer for children changes. If a change is detected, the Scroll Bars will be updated. Set this option if there are components inside which frequently modify their size, in other situations keep it disabled for avoiding unnescessary overhead (Default: false)
Timeline
Renders a Timeline sequence using provided child components. Use Timeline.Item and ‘Timeline.Date’ as direct children of this component for adding entries.
Props:
- itemAlignment<string> - (Available options: vertical, horizontal<d>) Describes in which fashion should the Timeline.Items render
Timeline.Item
Represents a single entry in the Timeline. Should be composed of a Timeline.ItemHeader and Timeline.ItemBody.
Props:
- date<string/number/object> - Entry date information which will be parsed by momentjs and displayed within the Timeline.Item
- dateFormat<string> - Date format string which will be used for displaying the date (Default: DD MMM YYYY[\n]h:mm a)
- icon<node> - Small icon which serves as a bullet for each entry (Default: )
- color<string> - Color of the above icon (Default: Colors.brandPrimary)
Timeline.ItemBody
Contains the content of the Timeline entry.
Timeline.ItemHeader
Header of the Timline.Item. Renders an Icon/Avatar in a combination with primary/secondary text.
Props:
- avatar<node> - Graphic representation of the entry. May be AvatarImage, AvatarIcon or AvatarText
- primaryText<node/string> - Main text element of the header
- secondaryText<node/string> - Additional text element of the header
Timeline.Date
Used as a separator of Timeline.Items. May group entries by date i.e. today, yesterday etc. The text should be placed as a child of this component.
Tooltips
Extended Tooltip from ReactBootstrap.
Additional Props:
- bsStyle<string> - (Available options: primary, success, info, warning, danger) Adds appropriate background color to the Tooltip
- customColor<string> - Accepts a color definition. Available only if bsStyle is set to custom
Tree Navigator
Tree Navigation component which consists of TreeNavigation.Branches populated with React Routers Link components.
Props:
- currentPath<string> - Current site URL, typically this will be connected to React Router’s current path.
- activeEventKey<string> - Key of the branch which will be opened by default
TreeNavigator.Branch
Component grouping Links. Place the links inside of the Branch. There can be only one branch opened at a time.
Props:
- title<string> - Title of the branch
- eventKey<string> - Key of the branch, very optional use only in combination of activeEventKey from the parent (Default: [random key])
Charts
A set of Charts Components which can be used in various ways discribed below:
Chartist
A Proxy of ReactChartist. Check the Project’s site for available props.
Highcharts & Highstock HighchartBase, HighchartBasicLine, HighchartBasicLine, HighchartBasicColumn, HighStock
Wrap of Highcharts charts. Use the HighchartBase for making a Highchart chart from scratch providing the configuration in the config prop. HighchartBasicLine, HighchartBasicLine, HighchartBasicColumn have initial configurations for achieving the basic feel of each chart. All of these components have a theme connected which matches the dashboard style.
Props:
- config<object> - Highcharts configuration object. Will be deeply merged with the theme and/or initial chart configuration.
- dynamicUpdate<bool> - If set to true it will watch for changes in series data and inject only the freshly added points. Use for efficient rendering of streams of data. (Default: false)
AsyncChart
Asynchronous Highcharts loader. Can be used when a chart needs to load a large amount of data. Place a Highchart chart as direct child of this component. While the data loads there will be a loader rendered.
Props:
- children<element> - Highchart Component which will be injected with data
- getConfig<func> - Callback function which will be called when data will be available. Should return a config object merged with data from the first argument
- getJson<func> - Callback which should make an async request or async Webpack require. Should call the callback from the first argumnet when the request is complete
Sparklines
Sparklines are typically small charts which fit well as inline/table charts. There are four types that you can use:
SparklineLine
Typical Line Chart look.
Props:
- data<array<number>> - Array of values to display the chart
- color<string> - Color string which represents the chart line (Default: Colors.brandPrimary)
- width<number> - Chart width in px
- height<number> - Chart height in px
- limit<number> - Total points which will be rendered in the Chart
- block<bool> - If set to true will make the Chart a display: block element, inline-block othwerwise (Default: false)
- chartStyle<object> - Additional style object for some custom SVG modifications
- fullWidth<bool> - Adjusts the Chart Container to fill the Parent space
SparklineBar
Bar Chart representation
Props:
- data<array<number>> - Array of values to display the chart
- color<string> - Color string which represents the chart line (Default: Colors.brandPrimary)
- width<number> - Chart width in px (Default: 32)
- height<number> - Chart height in px (Default: 16)
- chartStyle<object> - Additional style object for some custom SVG modifications
SparklineBar
Bar Chart representation
Props:
- data<array<number>> - Array of values to display the chart
- color<string> - Color string which represents the chart line (Default: Colors.brandPrimary)
- width<number> - Chart width in px (Default: 32)
- height<number> - Chart height in px (Default: 16)
- chartStyle<object> - Additional style object for some custom SVG modifications
SparklineDonut
Donut / Gauge Chart representation
Props:
- data<array<number>> - Values of each slice sequentially
- value<number> - Single value for Gauge, when provided data wil be omited
- radius<number> - Radius of the donut in px (Default: 30px)
- innerRadius<number/string> - Size of the inner ring can be in px or % (Default: %)
- colors<array<string>> - Array of sequential colors which will be used for data (Default: [Colors.brandPrimary, Colors.brandInfo, Colors.brandWarning, Colors.brandDanger, Colors.brandSuccess])
- color<string> - Color used for single Value (Default: Colors.brandPrimary)
- animated<bool> - Should the donut be animated on initial render (Default: false)
- animationDuration<number> - Duration of the initial render animation
SparklinePie
Pie/Gauge Chart representation.
Props:
- data<array<number>> - Values of each slice sequentially
- value<number> - Single value for Gauge, when provided data wil be omited
- radius<number> - Radius of the donut in px (Default: 30px)
- innerRadius<number/string> - Size of the inner ring can be in px or % (Default: %)
- colors<array<string>> - Array of sequential colors which will be used for data (Default: [Colors.brandPrimary, Colors.brandInfo, Colors.brandWarning, Colors.brandDanger, Colors.brandSuccess])
- color<string> - Color used for single Value (Default: Colors.brandPrimary)
- animated<bool> - Should the donut be animated on initial render (Default: false)
- animationDuration<number> - Duration of the initial render animation


revisionator.lua
--- The revisionator provides a standardized way of migrating configurations between revisions -- for instance, it will track what the currently applied revision number is, and when you tell -- tell it to migrate, it will apply every individual migration between the currently applied -- revision and the latest/current revision. This should allow for more seamlessly moving from -- an older version of a package to a new one. -- @classmod revisionator -- @author Damian Monogue<EMAIL_ADDRESS>-- @copyright 2023 -- @license MIT, see https://raw.githubusercontent.com/demonnic/MDK/main/src/scripts/LICENSE.lua local revisionator = { name = "Revisionator", patches = {}, } revisionator.__index = revisionator local dataDir = getMudletHomeDir() .. "/revisionator" revisionator.dataDir = dataDir if not io.exists(dataDir) then local ok,err = lfs.mkdir(dataDir) if not ok then printDebug(f"Error creating the directory for storing applied revisions: {err}", true) end end --- Creates a new revisionator -- @tparam table options the options to create the revisionator with. --
 --
 --
 -- option name	 -- description	 -- default	 --
 --
 --
 --
 -- name	 -- The name of the revisionator. This is absolutely required, as the name is used for tracking the currently applied patch level	 -- raises an error if not provided	 --
 --
 -- patches	 -- A table of patch functions. It is traversed using ipairs, so must be in the form of {function1, function2, function3} etc. If you do not provide it, you can add the patches by calling :addPatch for each patch in order.	 -- {}	 --
 --
 --
 function revisionator:new(options) options = options or {} local optionsType = type(options) if optionsType ~= "table" then printError(f"revisionator:new bad argument #1 type, options as table expected, got {optionsType}", true, true) end if not options.name then printError("revisionator:new(options) options must include a 'name' key as this is used as part of tracking the applied patch level.", true, true) end local me = table.deepcopy(options) setmetatable(me, self) return me end --- Get the currently applied revision from file --- @treturn[1] number the revision number currently applied, or 0 if it can't read a current version --- @treturn[2] nil nil --- @treturn[2] string error message function revisionator:getAppliedPatch() local fileName = f"{self.dataDir}/{self.name}.txt" debugc(fileName) local revision = 0 if io.exists(fileName) then local file = io.open(fileName, "r") local fileContents = file:read("*a") file:close() local revNumber = tonumber(fileContents) if revNumber then revision = revNumber else return nil, f"Error while attempting to read current patch version from file: {fileName}\nThe contents of the file are {fileContents} and it was unable to be converted to a revision number" end end return revision end --- go through all the patches in order and apply any which are still necessary --- @treturn boolean true if it successfully applied patches, false if it was already at the latest patch level --- @error error message function revisionator:migrate() local applied,err = self:getAppliedPatch() if not applied then printError(err, true, true) end local patches = self.patches if applied >= #patches then return false end for revision, patch in ipairs(patches) do if applied < revision then local ok, err = pcall(patch) if not ok then self:setAppliedPatch(revision - 1) return nil, f"Error while running patch #{revision}: {err}" end end end self:setAppliedPatch(#patches) return true end --- add a patch to the table of patches --- @tparam function func the function to run as the patch --- @number[opt] position which patch to insert it as? If not supplied, inserts it as the last patch. Which is usually what you want. function revisionator:addPatch(func, position) if position then table.insert(self.patches, position, func) else table.insert(self.patches, func) end end --- Remove a patch from the table of patches --- this is primarily used for testing --- @local --- @number[opt] patchNumber the patch number to remove. Will remove the last item if not provided. function revisionator:removePatch(patchNumber) table.remove(self.patches, patchNumber) end --- set the currently applied patch number -- only directly called for testing --- @local --- @number patchNumber the patch number to set as the currently applied patch function revisionator:setAppliedPatch(patchNumber) local fileName = f"{self.dataDir}/{self.name}.txt" local revFile, err = io.open(fileName, "w+") if not revFile then printError(err, true, true) end revFile:write(patchNumber) revFile:close() end return revisionator


Mesosystem
Honda
Doctor's Appointment
Fiancee
Mom
Veteran Status
UW
Veteran Status
Doctor's Appointment
Summer(Cat)
Sleeping Aids
Self
Honda
Doctor's Appointment
Fiancee
Mom
Veteran Status
UW
Veteran Status
Doctor's Appointment
Summer(Cat)
Sleeping Aids
Self


The XOR-Problem is a classification problem, where you only have four data points with two features. The training set and the test set are exactly the same in this problem. So the interesting question is only if the model is able to find a decision boundary which classifies all four points correctly.
Neural Network basics
I think of neural networks as a construction kit for functions. The basic building block - called a "neuron" - is usually visualized like this:
It gets a variable number of inputx \(x_0, x_1, \dots, x_n\), they get multiplied with weights \(w_0, w_1, \dots, w_n\), summed and a function \(\varphi\) is applied to it. The weights is what you want to "fine tune" to make it actually work. When you have more of those neurons, you visualize it like this:
In this example, it is only one output and 5 inputs, but it could be any number. The number of inputs and outputs is usually defined by your problem, the intermediate is to allow it to fit more exact to what you need (which comes with some other implications).
Now you have some structure of the function set, you need to find weights which work. This is where backpropagation3 comes into play. The idea is the following: You took functions (\(\varphi\)) which were differentiable and combined them in a way which makes sure the complete function is differentiable. Then you apply an error function (e.g. the euclidean distance of the output to the desired output, Cross-Entropy) which is also differentiable. Meaning you have a completely differentiable function. Now you see the weights as variables and the data as given parameters of a HUGE function. You can differentiate (calculate the gradient) and go from your random weights "a step" in the direction where the error gets lower. This adjusts your weights. Then you repeat this steepest descent step and hopefully end up some time with a good function.
For two weights, this awesome image by Alec Radford visualizes how different algorithms based on gradient descent find a minimum (Source with even more of those):
So think of back propagation as a shortsighted hiker trying to find the lowest point on the error surface: He only sees what is directly in front of him. As he makes progress, he adjusts the direction in which he goes.
Targets and Error function
First of all, you should think about how your targets look like. For classification problems, one usually takes as many output neurons as one has classes. Then the softmax function is applied.1 The softmax function makes sure that the output of every single neuron is in \([0, 1]\) and the sum of all outputs is exactly \(1\). This means the output can be interpreted as a probability distribution over all classes.
Now you have to adjust your targets. It is likely that you only have a list of labels, where the \(i\)-th element in the list is the label for the \(i\)-th element in your feature list \(X\) (or the \(i\)-th row in your feature matrix \(X\)). But the tools need a target value which fits to the error function. The usual error function for classification problems is cross entropy (CE). When you have a list of \(n\) features \(x\), the target \(t\) and a classifier \(clf\), then you calculate the cross entropy loss for this single sample by:
Now we need a target value for each single neuron for every sample \(x\). We get those by so called one hot encoding: The \(k\) classes all have their own neuron. If a sample \(x\) is of class \(i\), then the \(i\)-th neuron should give \(1\) and all others should give \(0\).2
sklearn
provides a very useful OneHotEncoder
class. You first have to fit
it on your labels (e.g. just give it all of them). In the next step you can
transform a list of labels to an array of one-hot encoded targets:
#!/usr/bin/env python
"""Mini-demo how the one hot encoder works."""
from sklearn.preprocessing import OneHotEncoder
import numpy as np
# The most intuitive way to label a dataset "X"
# (list of features, where X[i] are the features for a datapoint i)
# is to have a flat list "labels" where labels[i] is the label for datapoint i.
labels = [0, 1, 1, 1, 0, 0, 1]
# The OneHotEncoder transforms those labels to something our models can
# work with
enc = OneHotEncoder()
def trans_for_ohe(labels):
"""Transform a flat list of labels to what one hot encoder needs."""
return np.array(labels).reshape(len(labels), -1)
labels_r = trans_for_ohe(labels)
# The encoder has to know how many classes there are and what their names are.
enc.fit(labels_r)
# Now you can transform
print(enc.transform(trans_for_ohe([0, 1])).toarray().tolist())
Install Tensorflow
The documentation about the installation makes a VERY good impression. Better than anything I can write in a few minutes, so ... RTFM 😜
For Linux systems with CUDA and without root privileges, you can install it with:
$ pip install https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.5.0-cp27-none-linux_x86_64.whl --user
But remember you have to set the environment variable LD_LIBRARY_PATH
and
CUDA_HOME
. For many configurations, adding the following lines to your
.bashrc
will work:
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"
export CUDA_HOME=/usr/local/cuda
I currently (19.07.2016) to use Tensorflow rc0.7 (installation instructions) with CUDA 7.5 (installation instructions). I had a couple of problems with other versions (e.g. #3342, #2810, #2034, but that might only have been bad luck. Who knows.).
Tensorflow basics
Tensorflow helps you to define the neural network in a symbolic way. This means you do not explicitly tell the computer what to compute to inference with the neural network, but you tell it how the data flow works. This symbolic representation of the computation can then be used to automatically caluclate the derivates. This is awesome!  But keep it in mind that it is only symbolic as this makes a few things more complicated and different from what you might be used to.
Tensorflow has placeholders and variables. Placeholders are the things in which you later put your input. This is your features and your targets, but might be also include more. Variables are the things the optimizer calculates.
Now you should be able to understand the following code which solves the XOR problem. It defines a neural network with two input neurons, 2 neurons in a first hidden layer and 2 output neurons. All neurons have biases.
#!/usr/bin/env python
"""
Solve the XOR problem with Tensorflow.
The XOR problem is a two-class classification problem. You only have four
datapoints, all of which are given during training time. Each datapoint has
two features:
x o
o x
As you can see, the classifier has to learn a non-linear transformation of
the features to find a propper decision boundary.
"""
__author__ = "Martin Thoma"
__email__ =<EMAIL_ADDRESS>import tensorflow as tf
import matplotlib.pyplot as plt
import numpy as np
from sklearn.preprocessing import OneHotEncoder
def trans_for_ohe(labels):
"""Transform a flat list of labels to what one hot encoder needs."""
return np.array(labels).reshape(len(labels), -1)
def analyze_classifier(sess, i, w1, b1, w2, b2, XOR_X, XOR_T):
"""Visualize the classification."""
print("\nEpoch %i" % i)
print(
"Hypothesis %s" % sess.run(hypothesis, feed_dict={input_: XOR_X, target: XOR_T})
)
print("w1=%s" % sess.run(w1))
print("b1=%s" % sess.run(b1))
print("w2=%s" % sess.run(w2))
print("b2=%s" % sess.run(b2))
print(
"cost (ce)=%s"
% sess.run(cross_entropy, feed_dict={input_: XOR_X, target: XOR_T})
)
# Visualize classification boundary
xs = np.linspace(-5, 5)
ys = np.linspace(-5, 5)
pred_classes = []
for x in xs:
for y in ys:
pred_class = sess.run(hypothesis, feed_dict={input_: [[x, y]]})
pred_classes.append((x, y, pred_class.argmax()))
xs_p, ys_p = [], []
xs_n, ys_n = [], []
for x, y, c in pred_classes:
if c == 0:
xs_n.append(x)
ys_n.append(y)
else:
xs_p.append(x)
ys_p.append(y)
plt.plot(xs_p, ys_p, "ro", xs_n, ys_n, "bo")
plt.show()
# The training data
XOR_X = [[0, 0], [0, 1], [1, 0], [1, 1]] # Features
XOR_Y = [0, 1, 1, 0] # Class labels
assert len(XOR_X) == len(XOR_Y) # sanity check
# Transform labels to targets
enc = OneHotEncoder()
enc.fit(trans_for_ohe(XOR_Y))
XOR_T = enc.transform(trans_for_ohe(XOR_Y)).toarray()
# The network
nb_classes = 2
input_ = tf.placeholder(tf.float32, shape=[None, len(XOR_X[0])], name="input")
target = tf.placeholder(tf.float32, shape=[None, nb_classes], name="output")
nb_hidden_nodes = 2
# enc = tf.one_hot([0, 1], 2)
w1 = tf.Variable(
tf.random_uniform([2, nb_hidden_nodes], -1, 1, seed=0), name="Weights1"
)
w2 = tf.Variable(
tf.random_uniform([nb_hidden_nodes, nb_classes], -1, 1, seed=0), name="Weights2"
)
b1 = tf.Variable(tf.zeros([nb_hidden_nodes]), name="Biases1")
b2 = tf.Variable(tf.zeros([nb_classes]), name="Biases2")
activation2 = tf.sigmoid(tf.matmul(input_, w1) + b1)
hypothesis = tf.nn.softmax(tf.matmul(activation2, w2) + b2)
cross_entropy = -tf.reduce_sum(target * tf.log(hypothesis))
train_step = tf.train.GradientDescentOptimizer(0.1).minimize(cross_entropy)
# Start training
init = tf.initialize_all_variables()
with tf.Session() as sess:
sess.run(init)
for i in range(20001):
sess.run(train_step, feed_dict={input_: XOR_X, target: XOR_T})
if i % 10000 == 0:
analyze_classifier(sess, i, w1, b1, w2, b2, XOR_X, XOR_T)
The output is:
Epoch 0
Hypothesis [[ 0.48712057 0.51287943]
[ 0.3380821 0.66191792]
[ 0.65063184 0.34936813]
[ 0.50317246 0.4968276 ]]
w1=[[-0.79593647 0.93947881]
[ 0.68854761 -0.89423609]]
b1=[-0.00733338 0.00893857]
w2=[[-0.79084051 0.93289936]
[ 0.69278169 -0.8986907 ]]
b2=[ 0.00394399 -0.00394398]
cost (ce)=2.87031
Epoch 10000
Hypothesis [[ 0.99773693 0.00226305]
[ 0.00290442 0.99709558]
[ 0.00295531 0.99704474]
[ 0.99804318 0.00195681]]
w1=[[-6.62694693 7.5230279 ]
[ 6.91208076 -7.39292192]]
b1=[ 3.32245016 3.76204181]
w2=[[ 6.63465023 -6.49259233]
[ 6.40471792 -6.61061859]]
b2=[-9.65064621 9.65065193]
cost (ce)=0.0100926
Epoch 20000
Hypothesis [[ 9.98954773e-01 1.04520109e-03]
[ 1.35455502e-03 9.98645484e-01]
[ 1.37042452e-03 9.98629570e-01]
[ 9.99092221e-01 9.07782756e-04]]
w1=[[-7.04857063 7.84673214]
[ 7.33061123 -7.68837786]]
b1=[ 3.53246188 3.89587545]
w2=[[ 7.35948515 -7.21742725]
[ 7.14059925 -7.34649038]]
b2=[-10.74944687 10.74944115]
cost (ce)=0.00468077
The resulting decision boundary looks like this:
I recommend reading the Tensorflow Whitepaper if you want to understand Tensorflow better.
Footnotes
-
Softmax is similar to the sigmoid function, but with normalization. ↩
-
Actually, we don't want this. The probability of any class should never be exactly zero as this might cause problems later. It might get very very small, but should never be 0. ↩
-
Backpropagation is only a clever implementation of gradient descent. It belongs to the bigger class of iterative descent algorithms. ↩


Travel Arrangements
Arrive in Style
These are the options for your luxury travel:
Helicopter
Jet
Yacht
Home


TL;DR
We’ll focus on the extensibility points of the C# compiler to customize the behavior of async methods and task-like types. As result, we will be able to write linear, concise, and composable code with the possibility to have control over task scheduling. 🤓
C# 💜 patterns
Numerous C# features are based on duck-typing and patterns inferred by the compiler. Basically, it means that a developer doesn’t need to implement interfaces or inherit classes explicitly to achieve some pluggable behavior. Instead, we could follow some well-known conventions inferred by the compiler to plug or glue some functionality together. Duck-typing is great when strongly-typed approach impedes too many limitations or you want to keep your code clean and tidy. So if you’ve got a pattern right, than, the compiler will do its magic and generate some code for you. Let’s see examples of such patterns in C#.
| Pattern | How to use | |
|---|---|---|
| Foreach | Implement GetEnumerator method to make you custom type work with foreach . |
|
| LINQ Queries | Implement SelectMany , Select ,Where , GroupBy , OrderBy , ThenBy , Join . C# compiler creates a series of method calls. As long as these methods are found, you are good. |
|
| Deconstructors | Implement the Deconstruct method with a bunch out parameters. The result of deconstruction could be consumed as ValueTuple or as separately initialized variables. |
|
| Dynamic | The C# compiler invokes a whole reflection machinery which by default can invoke methods, properties, and fields. As soon as the object implements IDynamicMetaObjectProvider the object gets runtime control on what is invoked. |
|
| Async/Await | The only thing required is a GetAwaiter method which returns an object having an IsComplete and GetResult() method and implementing the INotifyCompletion interface. |
Examples
Before we delve into the main part, I would like to warm you up and provide some examples of how C# compiler infers patterns in various cases.
Foreach
Usually, we implement IEnumerable
to support collection-like behavior. As result, it is possible to use foreach
over user-defined types. But, in order for type to be consumed by foreach
you just need to implement GetEnumerator
method.  You can iterate over System.Range
by implementing extension method. This enables a bunch of new opportunities, e.g.:
public static IEnumerator<T> GetEnumerator<T>(this System.Range range) => enumerator;
// Usage
foreach (var i in 1..10) {}
LINQ Queries
Generate permutations for a list of words and write LINQ quires over it. See full version on Github: PermutationsSource.cs.
// Implementation
public class PermutationsSource
{
//...
public IEnumerable<T> SelectMany<T>(
Func<PermutationsSource, IEnumerable<string>> selector, Func<PermutationsSource, string, T> resultSelector) =>
selector(this).Select(i => resultSelector(this, i));
public PermutationsSource Select(Func<PermutationsSource, PermutationsSource> selection) => selection(this);
//...
}
// Usage
var q = from ps in new PermutationsSource("test", "test", "new")
from perm in ps.Permute()
where perm.Length < 4
select perm;
Debug.Assert(q.Count() == 6);
Deconstructors
Besides tuples, you can deconstruct custom types that have Deconstruct
method implement as class member or extension method.
public class Person
{
public string FirstName { get; }
public string LastName { get; }
public int Age { get; }
public Person(string fName, string lName, int age) =>
(FirstName, LastName, Age) = (fName, lName, age);
public void Deconstruct(out string fName, out string lName) =>
(fName, lName) = (FirstName, LastName);
public void Deconstruct(out string fName, out string lName, out int age) =>
(fName, lName, age) = (FirstName, LastName, Age);
}
// Usage
var p = new Person("John", "Doe", 42);
(string firstName, _) = p;
var (x,_, z) = p;
Async/Await
You can implement simplistic awaitable/awaiter pattern based on extension methods. Like this:
public static TaskAwaiter GetAwaiter(this IEnumerable<Task> tasks) =>
TaskEx.WhenAll(tasks).GetAwaiter();
// Usage
await from url in urls select DownloadAsync(url);
🚀 Let’s see how we can use this in something, that I call logical micro-threading.
Problem: Largest series product
Occasionally, I use coding platforms to practice my craft. I really like the idea of doing Katas to hone coding skills, because you truly know something when you’ve implemented it and get hands-on experience. Katas is part of the thing. 🐱👤
A code kata is an exercise in programming which helps programmers hone their skills through practice and repetition.
Let’s solve this one: exercism.io/tracks/csharp/exercises/largest-series-product.
Given a string of digits, calculate the largest product for a contiguous substring of digits of length n.
The problem itself is really straightforward and we could solve it by iterating over the input array and calculating the local maximum every time the window has a length of a given value (span).
Here is my first take on it: largest-series-product/solution.
var max = 0;
var curr = 1;
var array = ToDigits(digits);
var length = array.Count;
int start = 0, end = 0;
for (int i = 0; i < length; i++)
{
end = i;
if (array[i] == 0)
{
start = i + 1;
end = start;
curr = 1;
continue;
}
var full = end - start >= span;
if (full)
{
curr /= array[start];
curr *= array[i];
start++;
}
else
curr *= array[end];
max = curr > max && (end - start + 1 == span) ? curr : max;
}
return max;
I hate to read code like this 🤮. It takes you quite some time and effort to really figure out what is going on. With great confidence, we can describe this code as write-only.
Write-only code code is source code so arcane, complex, or ill-structured that it cannot be reliably modified or even comprehended by anyone with the possible exception of the author.
Let’s formulate how we could tackle the complexity of a relatively simple problems in utterly hyperbolical manner.
My goal is to share with you the technique. I deliberately chose a simple problem so we could try to understand the micro-threading approach without delving into details.
Micro-threading
C# 5 language made a huge step forward by introducing async/await. Async/await helps to compose tasks and gives the user an ability to use well-known constructs like try/catch, using etc. A regular method has just one entry point and one exit point. But async methods and iterators are different. In the case of async method, a method caller get the (e.g. Task-like type or Task
) result immediately and then “await” the actual result of the method via the resulting task-like type.
Async machinery
Methods marked by async are undergoing subtle transformations performed by the compiler. To make everything work together, the compiler makes use of:
- Generated state machine that acts like a stack frame for an asynchronous method and contains all the logic from the original async method
- AsyncTaskMethodBuilder<T> that keeps the completed task (very similar to TaskCompletionSource<T> type) and manages the state transition of the state machine.
- TaskAwaiter<T> that wraps a task and schedules continuations of it if needed.
- MoveNextRunner that calls IAsyncStateMachine.MoveNextmethod in the correct execution context.
The fascinating part is you use extensibility points the C# compiler provides for customizing the behavior of async methods:
- Provide your own default async method builder in the
System.Runtime.CompilerServices namespace
. - Use custom task awaiters.
- Define your own task-like types. Starting from C# 7.2.
Later, we will see how the last two options could be used in more detail.
Let’s get back to kata problem, shall we?
If we take a look from the different angle we can spot different states in which the sliding window can be: “reduced”, “expanded”, and “shifted”.
So, the idea is to move the window from left to right and calculate local product every time the window is “expanded” or “shifted”.
Solution of the largest series product with awaitable/awaiter patten
My goal is to come up with the solution write highly composable and linear code and at the same time have control of how building blocks are executed and scheduled.
The solution consists of next building blocks:
$ tree -L 2 lib
lib
├── Core
│ ├── AsyncTicker.cs
│ ├── IStrategy.cs
│ ├── StrategyAwaiter.cs
│ ├── StrategyBuilder.cs
│ ├── Strategy.cs
│ ├── StrategyExtensions.cs
│ ├── StrategyResult.cs
│ ├── StrategyStatus.cs
│ └── StrategyTask.cs
├── LargestSeriesProductV2.cs
├── lib.csproj
└── StrategyImplementations
├── ChaosWindowStrategy.cs
├── ExpandStrategy.cs
├── MultipleSlidingWindowsStrategy.cs
├── ShiftStrategy.cs
├── SkipStrategy.cs
├── SlideStrategy.cs
├── SlidingWindowStrategy.cs
└── Solver.cs
2 directories, 19 files
Full source code: /exercism-playground/csharp/largest-series-product
Core
In order to use async/await for task-like types we need to introduce a bunch of extensibility points.
A strategy represents a discrete and composable algorithm:
public interface IStrategy
{
StrategyStatus Status { get; }
IStrategy[] Tick();
}
public class StrategyResult
{
public StrategyStatus Status { get; set; }
public IStrategy[] Strategies { get; set; }
}
public enum StrategyStatus { InProgress, Done, Failed }
We want to make it awaitable and you do it like this await myAwesomeStrategy
StrategyExtensions.cs:
public static class AwaitableExtensions
{
public static StrategyAwaiter GetAwaiter(this IStrategy strategy) =>
new StrategyAwaiter(new[] { strategy });
}
As mentioned before, C# compiler could do its magic if we implement awaitable/awaiter patter.
public class StrategyAwaiter : INotifyCompletion
{
public StrategyAwaiter(IStrategy[] strategies)
{
Strategies = strategies;
}
public IStrategy[] Strategies { get; }
public bool IsCompleted { get; private set; }
public bool GetResult() =>
Strategies == null || Strategies.All(x => x.Status == StrategyStatus.Done);
public void OnCompleted(Action continuation)
{
IsCompleted = true;
continuation();
}
}
public class StrategyTask
{
private readonly IStrategy[] strategies;
public StrategyAwaiter GetAwaiter() =>
return new StrategyAwaiter(strategies);
}
[AsyncMethodBuilder(typeof(StrategyTaskBuilder<>))]
public class StrategyTask<T>
{
public IStrategy[] Strategies { get; set; }
public T Result { get; set; }
public bool IsComplete { get; set; }
public Action Continue { get; set; }
}
public class StrategyTaskBuilder<T>
{
// skipped for brevity
}
That’s a lot, I know. But, bare with me, I will show how it works:
- Driver do the
.Tick()
AsyncTicker
runs a fresh strategy/task. (run()
)- Code executes normally until first
await
GetAwaiter
unwraps task-like typeAsyncMethodBuilder
initializes state machineAsyncTicker
runs continuation (continue()
)stateMachine.MoveNext()
is invoked- If
StrategyTask
is completed, the result is returned and control flow is resumed
I suggest you to spin up the debugger and investigate on your own 😉.
Let’s say we want to define a top-level strategy that is based on sliding windows giving us a valid span for every type we await a sub-strategy to slide:
// SlidingWindowStrategy.cs
protected override async StrategyTask<long> Run()
{
bool success;
long max = long.MinValue;
Range scan = ..;
var mem = Digits;
do
{
var slide = new SlideStrategy(mem, scan, span);
success = await slide && slide.Scanned.End.Value != 0;
if (success)
{
var mul = MultiplyDigits(mem[slide.Scanned]);
max = Math.Max(max, mul);
}
scan = slide.Scanned;
mem = mem[scan.Start.Value..];
} while (success);
Result = max;
return max;
}
A valid slide could look something like this:
// SlideStrategy.cs
protected override async StrategyTask<bool> Run()
{
var skipped = false;
var newSource = Scanned;
if (source.Span[0] == 0)
{
var skip = new SkipStrategy(source);
skipped = await skip;
Scanned = skip.Scanned;
if (skipped && newSource.End.Value == 0 && !newSource.End.IsFromEnd)
return false;
}
if (Scanned.End.Value - Scanned.Start.Value != span)
{
var expand = new ExpandStrategy(source[newSource.Start.Value..], span);
var expanded = await expand;
Scanned = expand.Scanned;
return expanded;
}
else
{
var shift = new ShiftStrategy(source, span);
var shifted = await shift;
Scanned = shift.Scanned;
return shifted;
}
}
And the building blocks:
// ExpandStrategy.cs
protected override async StrategyTask<bool> Run()
{
var end = 0;
var start = 0;
while (end < source.Length && (end - start) < span)
{
if (source.Span[end] == 0)
{
var skip = new SkipStrategy(source);
var skipped = await skip;
start = skip.Scanned.Start.Value;
if (!skipped)
return false;
}
Scanned = start..(end + 1);
end++;
}
return true;
}
// ShiftStrategy.cs
protected override async StrategyTask<bool> Run()
{
if (span >= source.Length)
{
Scanned = default;
return false;
}
if (source.Span[span] == 0)
{
var expand = new ExpandStrategy(source[(span + 1)..], span);
var expanded = await expand;
var shiftedRange = (expand.Scanned.Start.Value + span)..(expand.Scanned.End.Value + span);
Scanned = shiftedRange;
return expanded;
}
Scanned = 1..(span + 1);
return true;
}
// SkipStrategy.cs
protected override async StrategyTask<bool> Run()
{
var cnt = 0;
var wasSkipped = false;
while (source.Span[cnt] == 0)
{
wasSkipped = true;
Scanned = ++cnt..;
}
return wasSkipped;
}
And now, when we have the solution assembled, we can write a “Driver” code to trigger task machinery. Control flow is returned to the driver every time we await
something. This means, that we can change the way strategies are scheduled without modification of the actual algorithm. We may say that scheduling is moved out to a separate layer and adheres Open-Closed Principle (OCP) in this regard.
Having this layer we can enhance the solution with:
- Interception logic
- Fine-grained control over strategy scheduling
- Cancellation logic without the necessity to throw an
Exception
public class Solver
{
private void SequentialScheduling<T, K>(T strategy) where T : Strategy<K>
{
RecursiveTick(strategy: strategy, indentation: 0);
}
// The simplest approach is to make use of thread pool to introduce concurrency, but if we wanted to
// we would implement a scheduler that has complete supervision over control flow
private void ThreadpoolScheduling<T, K>(params T[] strategies) where T : Strategy<K>
{
var tasks = strategies.Select(t => Task.Run(() => RecursiveTick(t, 0)));
Task.WaitAll(tasks.ToArray());
}
public bool RunDriver<T, K>(params T[] strategies) where T : Strategy<K>
{
SequentialScheduling<T, K>(strategies[0]);
return new StrategyTask(strategies).GetAwaiter().GetResult();
}
}
If we run we can see the output based on simple interceptor logic:
//entry point
var input = "290010345";
Solution.GetLargestProduct<SlideStrategy>(input, span: 2, Console.Out);
// GetLargestProduct
var strategy = new SlidingWindowStrategy(input, span);
solver.RunDriver<SlidingWindowStrategy, long>(strategy);
return strategy.Result;
Let’s parallelize our solution by adding new strategy that will make use of existing building blocks:
//entry point
var input = "290010345";
Solution.GetLargestProduct<MultipleSlidingWindowsStrategy>(input, span: 2, Console.Out);
// GetLargestProduct
var strategy = new MultipleSlidingWindowsStrategy(input, span);
solver.RunDriver<MultipleSlidingWindowsStrategy, long>(strategy);
return strategy.Result;
// MultipleSlidingWindowsStrategy.cs
protected override async StrategyTask<long> Run()
{
var mid = Digits.Length / 2;
var strat1 = new SlidingWindowStrategy(Digits[..(mid + span)], 2);
var start2 = new SlidingWindowStrategy(Digits[(mid - span)..], 2);
await WhenAll(strat1, start2);
var res = Math.Max(strat1.Result, start2.Result);
Result = res;
return res;
}
protected StrategyTask WhenAll(params IStrategy[] strategies)
{
return new StrategyTask(strategies);
}
We could take another route and parallelize based on “Driver”
//entry point
var input = "290010345";
Solution.GetLargestProduct<ChaosWindowStrategy>(input, span: 2, Console.Out);
// GetLargestProduct
var mid = source.Length / 2;
var strategies = new SlidingWindowStrategy[]{
new SlidingWindowStrategy(source[..(mid + span)], span),
new SlidingWindowStrategy(source[(mid - span)..], span),
};
solver.RunDriver<ChaosWindowStrategy, long>(strategies);
return strategies.Select(s => s.Result).Max();
The beautiful thing is that we don’t need to change the actual implementation of the algorithm to have control over execution and scheduling. Which you may or may not find useful, but I find the approach interesting.
Conclusion
This is a tremendous over-engineering for such a simple problem. But I hope you’ve got this idea and how it could used to build custom async machinery.


Students Portal
Roll Number
Registration Number
First Name
Last Name
Branch
AUTOMOBILE ENGINEERING
COMPUTER SCIENCE AND ENGINEERING
CIVIL ENGINEERING
ELECTRONICS AND COMMUNICATION ENGINEERING
ELECTRICAL AND ELECTRONICS ENGINEERING
INFORMATION TECHNOLOGY
MECHANICAL ENGINEERING
MASTER OF COMPUTER APPLICATION
Gender
Male
Female
Father Name
Mother Name
Address
Pincode
Date Of Birth
CGPA
Year of Passing Degree
Diplamo Percentage
Year of Passing Diplamo
HSC Percentage
Year of Passing HSC
SSLC Percentage
Year of Passing SSLC
Standing Arrear Count
History of Arrear
Contact Number
E-Mail ID
Placement Status
INTERESTED
PLACED
HIGHER STUDIES
NOT WILLING
Comapany


| Number of apprentices | 1 | update |
| Maximum total cost | £3,000 |
| Government will pay | £2,700 |
| Cost to you | £300 | |
If your pay bill is more than £3 million a year, the cost of training will be different
| Total cost to you | £600 |
If your pay bill is more than £3 million a year, the cost of training will be different
You don't have any apprenticeship training shortlisted.
Find apprenticeship training


Kobe Women's Half Marathon
Kobe JPN
Race Winners (31 runnings)
25
Nov
2007
19
Nov
2006
27 Nov
2005
07
Nov
2004
09
Nov
2003
16
Feb
2003
16
Dec
2001
17
Dec
2000
14
Nov
1999
13
Dec
1998
16
Nov
1997
10
Nov
1996
12
Nov
1995
13
Nov
1994
14
Nov
1993
08
Nov
1992
10
Nov
1991
04
Nov
1990
05
Nov
1989
30
Oct
1988
01
Nov
1987
02
Nov
1986
03
Nov
1985
03
Nov
1984
30
Oct
1983
13
Ocr
1982
18
Oct
1981
11
Jan
1981
Notes: 1981 was the inaugural year. The race distance for 1978-1997 was 20 km.
The 2000 course was very probably short.
21 Nov
2010
1:11:35
Mari Ozaki (JPN)
22 Nov
2009
1:13:09
Misato Horie (JPN)
24 Nov
2008
1:09:45
Julia Mombi-2
1:09:45
Julia Mombi (KEN)
1:08:41
Everline Kimwei (KEN)
1:12:27
Minori Hayakari (JPN)
1:12:10
Catherine Ndereba (KEN)
1:09:52
Mizuki Noguchi (JPN)
1:11:59
Risa Hagiwara (JPN)
1:08:54
Miwako Yamanaka (JPN)
1:04:01
Esther Wanjiru (KEN)
1:06:31
Kazue Ogoshi (JPN)
1:07:16
Anne Wamuchi (KEN)
1:08:52
Kaori Kanda (JPN)
1:08:07
Tami Yada (JPN)
1:07:54
Junko Kataoka (JPN)
1:08:24
Mitsuyo Yoshida (JPN)
1:09:26
Yoshiko Yamamoto (JPN)
1:07:46
Christine McNamara (OR/USA)
1:07:03
Junko Asari-2
1:09:33
Miyoko Takahashi (JPN)
1:09:13
Junko Asari (JPN)
1:09:46
Hiromi Satoyama (JPN)
1:09:40
Kumi Araki-2
1:12:02
Chie Matsuda (JPN)
1:10:18
Kumi Araki (JPN)
1:11:02
Mika Kawai JPN)
1:11:26
Kazuko Shimizu-2
1:14:03
Rumiko Kaneko-2
1:16:01
Rumiko Kaneko (JPN)
1:18:40
Kazuko Shimizu (JPN)
Most Wins (1978-date)
Women 2
Rumiko Kaneko
(JPN)
1981b-82
Kazuko Shimizu
(JPN)
1981a,1983
Kumi Araki (JPN)
1985,1987
Junko Asari (JPN)
1989,1991
Julia Mombi (KEN)
2007-08
Prize Money
Prize money cannot be awarded in Japanese road races due to legal restrictions.
Race Time Bias
(sec/km)
Year Women 2007 +3.2 .... 2008 +1.2 2007 +0.5 .... 2004 +0.7 2003 -0.9 .... 2001 -2.9 2000 -8.5 1999 -1.5 1999 -3.6 Avgs -0.4
Note: 2000 is not included in the average.
Competitive Level (1990-date)
Year Women 2010 479 2009 325 2008 570 2007 544 .... 2005 345 2004 574 2003 591 .... 2001 718 .... 1999 655 1998 688
Quality Performances
Women- Half Marathon <1:09 3 <1:10 10 <1:11 13 <1:12 22 <1:13 39 <1:14 60 <1:15 76 <1:16 85 <1:17 97 Women- 20 km <1:07 1 <1:08 17 <1:09 24 <1:10 36 <1:11 41 <1:12 46 <1:13 47
Last Updated on 21
Nov 2010
Contributors: Brett Larner (36), Ken Nakamura (3)


(). CDV canine distemper virus {border-style px;} #ffffff;} MeV al.. human usage viruses dogs humans codon host infection measles origin American South adaptation evolutionary possible px; transmission {font-family RNA font-size morbillivirus populations potential viral double; molecular vaccine virus. zoonotic Canine Vet. Virol., border-color border-width disease immunity receptor solid; species use vaccination {font-style {font-weight (CDV) (Uhl ./JVI.- Europe Med. bias bold colonization courier; cross-species current different em; humans, indigenous interspecies nectin- new pathogens protein pt;} reported sequences


Iranian Navy Moves Headquarters From Tehran to Southern Province - Commander
MOSCOW (Sputnik) - The announcement comes two days after the US navy said in a press release that the USS Lincoln Carrier completed its scheduled transit through the Strait of Hormuz.
Rear Adm. Hossein Khanzadi on Thursday announced that Iran's naval headquarters would be moved from Tehran to Bandar Abbas, the capital of southern Hormozgan province.
"A significant part of Navy HQ elements will be transferred [to Bandar Abbas] and the naval forces will be led with an increased focus ... [The transfer] will increase the speed of operations and will allow the Navy to have more focus on waters", Khanzadi said, as quoted by Iran’s Mehr news agency.
He added that this decision would benefit the whole Hormozgan province by increasing its social, economic and cultural influence.
Khanzadi further emphasised that the move was approved some years ago by Supreme Leader Ali Khamenei, and that the main reason behind it was to have closer proximity to operational zones.
Tensions between Iran and the United States have escalated over the last several months mostly due to a standoff over the 2015 nuclear deal — Washington unilaterally withdrew from the pact in May 2018, and Tehran began rolling back its nuclear commitments one year later.


BlendDataLibraries(bpy_struct)¶
base class — bpy_struct
-
class
bpy.types.
BlendDataLibraries
(bpy_struct)¶ Collection of libraries
-
tag
(value)¶ tag
Parameters: value (boolean) – Value
-
classmethod
bl_rna_get_subclass
(id, default=None)¶ Parameters: id (string) – The RNA type identifier. Returns: The RNA type or default when not found. Return type: bpy.types.Struct
subclass
-
classmethod
bl_rna_get_subclass_py
(id, default=None)¶ Parameters: id (string) – The RNA type identifier. Returns: The class or default when not found. Return type: type
-
load
(filepath, link=False, relative=False)¶ Returns a context manager which exposes 2 library objects on entering. Each object has attributes matching bpy.data which are lists of strings to be linked.
Parameters: - filepath (string) – The path to a blend file.
- link (bool) – When False reference to the original file is lost.
- relative (bool) – When True the path is stored relative to the open blend file.
import bpy filepath = "//link_library.blend" # load a single scene we know the name of. with bpy.data.libraries.load(filepath) as (data_from, data_to): data_to.scenes = ["Scene"] # load all meshes with bpy.data.libraries.load(filepath) as (data_from, data_to): data_to.meshes = data_from.meshes # link all objects starting with 'A' with bpy.data.libraries.load(filepath, link=True) as (data_from, data_to): data_to.objects = [name for name in data_from.objects if name.startswith("A")] # append everything with bpy.data.libraries.load(filepath) as (data_from, data_to): for attr in dir(data_to): setattr(data_to, attr, getattr(data_from, attr)) # the loaded objects can be accessed from 'data_to' outside of the context # since loading the data replaces the strings for the datablocks or None # if the datablock could not be loaded. with bpy.data.libraries.load(filepath) as (data_from, data_to): data_to.meshes = data_from.meshes # now operate directly on the loaded data for mesh in data_to.meshes: if mesh is not None: print(mesh.name)
-
write
(filepath, datablocks, relative_remap=False, fake_user=False, compress=False)¶ Write data-blocks into a blend file.
Note
Indirectly referenced data-blocks will be expanded and written too.
Parameters: - filepath (string) – The path to write the blend-file.
- datablocks (set) – set of data-blocks (
bpy.types.ID
instances). - relative_remap (bool) – When True, make paths relative to the current blend-file.
- fake_user (bool) – When True, data-blocks will be written with fake-user flag enabled.
- compress (bool) – When True, write a compressed blend file.
import bpy filepath = "//new_library.blend" # write selected objects and their data to a blend file data_blocks = set(bpy.context.selected_objects) bpy.data.libraries.write(filepath, data_blocks) # write all meshes starting with a capital letter and # set them with fake-user enabled so they aren't lost on re-saving data_blocks = {mesh for mesh in bpy.data.meshes if mesh.name[:1].isupper()} bpy.data.libraries.write(filepath, data_blocks, fake_user=True) # write all materials, textures and node groups to a library data_blocks = {*bpy.data.materials, *bpy.data.textures, *bpy.data.node_groups} bpy.data.libraries.write(filepath, data_blocks)
-
Inherited Properties
Inherited Functions
References


One variant of N.G. de Bruijn's silver dollar game can be described as follows:
On a strip of squares a number of coins are placed, at most one coin per square. Only one coin, called the silver dollar, has any value. Two players take turns making moves. At each turn a player must make either a regular or a special move.
A regular move consists of selecting one coin and moving it one or more squares to the left. The coin cannot move out of the strip or jump on or over another coin.
Alternatively, the player can choose to make the special move of pocketing the leftmost coin rather than making a regular move. If no regular moves are possible, the player is forced to pocket the leftmost coin.
The winner is the player who pockets the silver dollar.
A winning configuration is an arrangement of coins on the strip where the first player can force a win no matter what the second player does.
Let W(n,c) be the number of winning configurations for a strip of n squares, c worthless coins and one silver dollar.
You are given that W(10,2) = 324 and W(100,10) =<PHONE_NUMBER>113500.
Find W(1 000 000, 100) modulo the semiprime 1000 036 000 099 (= 1 000 003 · 1 000 033).


You can have your cake and eat it too: enjoy convention and configuration with Core52!
Core52 uses the familiar Model-View-Controller architecture, with a twist…
Core52 is fast, really fast.
Core52 leverages the object-oriented greatness that is PHP 5.2*.
Core52 is pre-integrated with more than a dozen common third-party libraries, including API clients for Twitter and Facebook.
We took a cue from EllisLabs and made the documentation for Core52 second to none.
Hand-coding form validation routines gets old quick–really quick. Core52′s Form library handles validation, rendering, filtering, and sanitizing so you don’t have to.
Core52 has been tested–and hardened–over more than a year of use, and has been designed to prevent many common security flaws, including XSS, SQL injection, and more.
Backtraces and query logs are standard in Core52, making bug-squashing a breeze! In production, your application can automatically “phone home” every error report via email–along with GET, POST, and Session dumps.
For those intense behind-the-scenes tasks, you can leverage the full power of Core52 inside commandline scripts with a single include. Multiprocessing? Shared Memory? Daemons? We’ve got you covered there too.
* PHP 5.3 is not yet supported.


Check out your personal emotional summary in the left sidebar.
Understand with which emotion you post and write about most.
Your feels have also been categorized as either positive (happy, excited, proud, and romantic) and
negative (sad, stressed, and angry).
Read all your feels in the grid view.
Filter by emotion in the grid's lower left corner.
Or analyze your feels through the graph view. See
how you've been posting in the past day, week, and month.
Filter by emotion by clicking in the line graphs' legends.
ihtfp
{{#if account}}
{{> about-account}}
{{else}}
{{> about-feed}}
{{/if}}