edfcore 0.5.39 → 0.5.41
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 +45 -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.41";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,51 @@ 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.41
|
|
10
|
+
|
|
11
|
+
- **Added** a metamorphic test: reordering the signals in a header changes where the bytes are and
|
|
12
|
+
nothing else. EDF interleaves — every data record holds each signal's samples end to end in header
|
|
13
|
+
order, and a signal's block begins at the sum of the widths declared before it — so a channel's
|
|
14
|
+
position decides the offset every read of it is computed from, and decides nothing about what that
|
|
15
|
+
channel contains.
|
|
16
|
+
- That makes signal order a transformation with unusual reach: it changes every offset in the
|
|
17
|
+
de-interleaving arithmetic and must change no value anywhere. A fixture with one signal, or with
|
|
18
|
+
several of equal width, cannot tell the difference. The arithmetic only has room to be wrong when
|
|
19
|
+
the widths differ — which is exactly the file the format exists for, EEG at 256 Hz beside a
|
|
20
|
+
temperature channel at 1 Hz.
|
|
21
|
+
- The suite tested reading against expected values, per fixture; nothing tested it against itself
|
|
22
|
+
under a transformation. A `recordByteOffset` computed from the wrong running total, an off-by-one
|
|
23
|
+
in the signal loop, or a decode that assumed uniform width would survive every fixture in the
|
|
24
|
+
suite and fail here.
|
|
25
|
+
- Both directions are asserted, because half of it would be worthless. The offsets really do move —
|
|
26
|
+
three orders give three different offset sets, and `EEG Fpz-Cz` moves from byte 0 to byte 18 while
|
|
27
|
+
`Temp rectal` moves from 80 to 0 — and every per-label result stays identical: samples, physical
|
|
28
|
+
values, envelope buckets, sample counts, the range the sweep observes, and what `getSignal` and
|
|
29
|
+
`findSignals` return.
|
|
30
|
+
- The last block is the property over arbitrary widths and arbitrary rotations, with a constant seed.
|
|
31
|
+
|
|
32
|
+
## 0.5.40
|
|
33
|
+
|
|
34
|
+
- **Added** the resolution of every index and byte offset edfcore publishes. The API is full of
|
|
35
|
+
numbers that are addresses rather than measurements: `signalIndex` names a row of
|
|
36
|
+
`header.signals`, `recordIndex` a record, `firstSampleIndex` a position on a signal's own grid,
|
|
37
|
+
and `byteOffset`/`byteLength` a range a reader is expected to take to a hex editor. A measurement
|
|
38
|
+
that is wrong is wrong; an address that is wrong sends someone to look at the wrong bytes.
|
|
39
|
+
- They were checked one at a time where they are produced and nowhere as a class. Every object every
|
|
40
|
+
entry point returns is now walked over the eight `AWKWARD` shapes and a file with a gap — 1,500
|
|
41
|
+
numbers across 51 field names — and each is resolved against the file it came from. A
|
|
42
|
+
`signalIndex` must name a signal whose own `index` is that number; a `recordIndex` a record the
|
|
43
|
+
file has; `firstSampleIndex + sampleCount` must land inside the signal's `sampleCount`.
|
|
44
|
+
- The strongest check re-decodes. A chunk's `byteOffset` and `byteLength` are used to slice the
|
|
45
|
+
fixture and decode it again, and the samples that come back must be the samples the chunk carries.
|
|
46
|
+
A range check would pass on an offset that is inside the file and points at the wrong record.
|
|
47
|
+
- **Found while writing it:** that re-decode was vacuous on every shared fixture. `writer.ts`
|
|
48
|
+
defaults its sample generator to `(_record, index) => index % 100` — the same ramp in every record
|
|
49
|
+
— which is right for a fixture about a header and makes a byte-offset check unable to fail: a
|
|
50
|
+
chunk reporting the offset of the wrong record decodes to identical samples. The resolution now
|
|
51
|
+
runs against a file whose every record is distinguishable, asserts that it is before relying on
|
|
52
|
+
it, and shows that shifting the offset by one record changes what comes back.
|
|
53
|
+
|
|
9
54
|
## 0.5.39
|
|
10
55
|
|
|
11
56
|
- **Added** the rule that every array edfcore hands back is frozen. `src/` calls `Object.freeze`
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED