edfcore 0.5.20 → 0.5.22
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 +42 -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.22";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,48 @@ 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.22
|
|
10
|
+
|
|
11
|
+
- **Added** the scrolling table on `large-files.md`, measured. `large-files-cost.test.ts` runs the
|
|
12
|
+
two tables above it — what opening costs, and what one ten-second window costs. This is the third,
|
|
13
|
+
and the one that carries an argument rather than a figure: thirty consecutive ten-second windows
|
|
14
|
+
over an 8-channel EDF+C cost 30 reads and 1,246,800 bytes from a bare source, and 1 read of
|
|
15
|
+
1,048,576 bytes through `cachedSource`.
|
|
16
|
+
- The sentence under it is why the table is there. "Removing `cachedSource` changes the number of
|
|
17
|
+
reads and nothing else" is a debugging instruction — if a bug appears with the cache in place,
|
|
18
|
+
delete the wrapper; if it survives, the cache was not involved — and it is only as good as the
|
|
19
|
+
"nothing else". The two runs are now compared sample for sample, all 153,600 of them, with the
|
|
20
|
+
count of non-zero values asserted too: a fixture decoding to zeros throughout would make an exact
|
|
21
|
+
match mean nothing.
|
|
22
|
+
- The page also says which block the single read is — "the second 1 MiB block. The first was already
|
|
23
|
+
resident because the header read at open pulled it in, so the reads that come with opening a file
|
|
24
|
+
are not wasted." That is checked as an offset, because it is what a reader plans an HTTP range
|
|
25
|
+
budget around, and because a cache issuing one read of the right size at the wrong place would
|
|
26
|
+
satisfy every other assertion here.
|
|
27
|
+
- The neighbouring claim goes with it: thirty ten-second windows cost thirty reads, and one
|
|
28
|
+
300-second window over the same records costs one, for the same 1,246,800 bytes.
|
|
29
|
+
|
|
30
|
+
## 0.5.21
|
|
31
|
+
|
|
32
|
+
- **Added** the census `reading-signals.md` takes of the derived sample rate. `samplesPerRecord` is
|
|
33
|
+
authoritative and `sampleRateHz` is "provided for display"; the page argues that with one file —
|
|
34
|
+
256 samples in a 3-second record is 85.333… Hz, no float holds it, and the error grows with *t* —
|
|
35
|
+
and then counts how often the two ways of finding a sample disagree: "1,000 of the first 3,001"
|
|
36
|
+
integer second boundaries, "always by exactly one sample", with the float answer landing one
|
|
37
|
+
sample early.
|
|
38
|
+
- Nothing computed it. `sample-grid.test.ts` covers the grid functions and `trim-window.test.ts` the
|
|
39
|
+
window arithmetic, both against exact expectations; neither compares either against
|
|
40
|
+
`Math.round(t * sampleRateHz)`, which is the expression a reader would otherwise have written and
|
|
41
|
+
the one the whole section exists to talk them out of.
|
|
42
|
+
- The three printed values are checked first — `85.33333333333333`, `8534` from `trimToWindow`, and
|
|
43
|
+
`8533` from the float, whose sample really does start at 99.996 s — and then the census is run over
|
|
44
|
+
all 3,001 boundaries through `trimToWindow` rather than through a reimplementation of it. Each
|
|
45
|
+
clause of the Note is a separate assertion, because they fail separately: a count that is right
|
|
46
|
+
with the direction wrong would be a worse page than one with no number at all.
|
|
47
|
+
- The page shows `trimToWindow` twice, and the earlier example is on a 256 Hz file with its own
|
|
48
|
+
`exact.firstSampleIndex`. Every lookup is scoped to the fence that mentions the derived rate, so
|
|
49
|
+
the test cannot pass by reading the wrong example.
|
|
50
|
+
|
|
9
51
|
## 0.5.20
|
|
10
52
|
|
|
11
53
|
- **Added** the lifetime contract `api-sources.md` states in five words: of `close?()`, "edfcore
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED