edfcore 0.5.55 → 0.5.57
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/constants.d.ts +1 -1
- package/dist/constants.js +1 -1
- package/docs/CHANGELOG.md +41 -0
- package/package.json +1 -1
- package/src/constants.ts +1 -1
package/dist/constants.d.ts
CHANGED
|
@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
|
|
|
109
109
|
readonly reserved: 224;
|
|
110
110
|
};
|
|
111
111
|
/** Published package version. Kept in sync with package.json by a test. */
|
|
112
|
-
export declare const VERSION = "0.5.
|
|
112
|
+
export declare const VERSION = "0.5.57";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,47 @@ alone does not tell you whether you were affected.
|
|
|
6
6
|
edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
|
|
7
7
|
defect; those are called out below.
|
|
8
8
|
|
|
9
|
+
## 0.5.57
|
|
10
|
+
|
|
11
|
+
- **Added** the property that makes an envelope exhaustive: the buckets are a partition. `readEnvelope`
|
|
12
|
+
reduces a window to a min and a max per bucket, and the whole value of it is that nothing is lost —
|
|
13
|
+
a spike between two sampled points is what subsampling misses and an envelope does not.
|
|
14
|
+
`envelope.test.ts` states that as "equals an exhaustive reduction of the same samples", on one
|
|
15
|
+
fixture at one bucket count. The general form — the buckets cover every sample exactly once, in
|
|
16
|
+
order — was never written down.
|
|
17
|
+
- It is checked against `counts`, the field that says how many samples each bucket reduced. Walking
|
|
18
|
+
the window's samples and taking `counts[b]` at a time, every bucket's `min` and `max` must be the
|
|
19
|
+
exact minimum and maximum of the slice it took: at six bucket counts from one to one-per-sample,
|
|
20
|
+
and over arbitrary windows and counts with a constant seed.
|
|
21
|
+
- The last block is the case `readEnvelopeAtResolution` has and `readEnvelope` does not. Asked for a
|
|
22
|
+
bucket width finer than the sample interval it returns the grid its width implies and leaves the
|
|
23
|
+
columns with nothing in them empty rather than dropping them — 200 buckets over 32 samples, 168 of
|
|
24
|
+
them empty, and the ones that did take samples still bounding them exactly.
|
|
25
|
+
- In the digital domain an empty bucket reads `min: 0, max: 0`, which is a perfectly ordinary
|
|
26
|
+
reading. So `counts` is the only field that tells it from a channel that really was flat at zero,
|
|
27
|
+
and that is asserted by building the flat channel and comparing the two.
|
|
28
|
+
|
|
29
|
+
## 0.5.56
|
|
30
|
+
|
|
31
|
+
- **Added** the rule `precededByGap` carries, checked however the chunk was asked for. It is stated
|
|
32
|
+
in three places and was tested in one. `chunks.ts`: the field is `undefined` "in two different
|
|
33
|
+
situations: no gap, and nobody looked". `stream.ts`: a streamed chunk carries "the same
|
|
34
|
+
`precededByGap` a `readWindow` chunk would". `biosemi.ts` states the sharpest form — the gap
|
|
35
|
+
"precedes the RUN, not whichever sample the window happened to admit first, which could be a whole
|
|
36
|
+
record later", a rule narrowed in 0.3.67 after 0.3.92 wrote down a wider one.
|
|
37
|
+
- Four entry points produce chunks, and the field is computed from the index rather than from the
|
|
38
|
+
read — so what it says must be the same whichever asked, for the same records.
|
|
39
|
+
- One file with a twenty-second hole after record 4, and every way of naming the records around it:
|
|
40
|
+
`readRecords` by number, `readWindow` by time, `streamRecords` in pieces smaller than the run, and
|
|
41
|
+
`readEnvelope`. The gap appears on exactly one chunk in each — the one whose first record is
|
|
42
|
+
record 5 — and on none of the others, including the chunk starting at record 6, which is inside
|
|
43
|
+
the run and after it, and the chunk starting at record 4, which spans the hole by record number
|
|
44
|
+
and is not preceded by it. At four different `chunkRecords`, exactly one streamed chunk carries it
|
|
45
|
+
every time.
|
|
46
|
+
- The other of the two situations is checked beside it: on a probed index the same read gives
|
|
47
|
+
`undefined`, which is "nobody looked" rather than "no gap" — and the samples are identical either
|
|
48
|
+
way, so only the field about structure differs.
|
|
49
|
+
|
|
9
50
|
## 0.5.55
|
|
10
51
|
|
|
11
52
|
- **Added** the window that begins before the recording does. "A window that starts before record 0
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED