edfcore 0.4.314 → 0.4.316

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.
@@ -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.4.314";
112
+ export declare const VERSION = "0.4.316";
113
113
  //# sourceMappingURL=constants.d.ts.map
package/dist/constants.js CHANGED
@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
79
79
  reserved: 224,
80
80
  };
81
81
  /** Published package version. Kept in sync with package.json by a test. */
82
- export const VERSION = '0.4.314';
82
+ export const VERSION = '0.4.316';
83
83
  //# sourceMappingURL=constants.js.map
package/docs/CHANGELOG.md CHANGED
@@ -6,6 +6,29 @@ 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.4.316
10
+
11
+ - **Added** an execution of the negative-gain section of `physical-values.md`: the scale it prints,
12
+ the three samples it converts, the envelope `physicalRangeOf` reports in size order rather than
13
+ field order, and the whole `INVERTED_PHYSICAL_RANGE` message it quotes for a one-signal file,
14
+ compared word for word against the one the package emits.
15
+ - Only the page's hard wraps are undone for that comparison. A run of spaces inside a line is not
16
+ wrapping — it is the eight-byte physical minimum field quoted as the file holds it, padding
17
+ included — so collapsing every space would have compared against a message edfcore does not
18
+ emit. The byte offset in the quote is resolved through `signalFieldOffset`, which is the same
19
+ `256 + ns*104 + i*8` the address table on `edf-format.md` gives.
20
+
21
+ ## 0.4.315
22
+
23
+ - **Added** a measurement of the float32 cost `physical-values.md` cites as the reason `toPhysical`
24
+ has no `Float32` option. Every one of the 2^24 BDF samples on a -500..500 uV channel is converted
25
+ through the scale edfcore publishes and rounded to float32, and the worst error is compared with
26
+ the 0.26 of a quantisation step the page prints.
27
+ - The sentence the number supports is checked too: float32 carries 24 significand bits and a BDF
28
+ sample is a 24-bit integer, so the digital values themselves survive the round trip exactly and
29
+ there is nothing left for the scaling. Run as a scalar loop — 2^24 float64 samples is 134 MB, and
30
+ the point is the worst case, not the array.
31
+
9
32
  ## 0.4.314
10
33
 
11
34
  - **Added** the census underneath the table 0.4.313 pinned: the two conversion forms are run over
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "edfcore",
3
- "version": "0.4.314",
3
+ "version": "0.4.316",
4
4
  "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
5
5
  "keywords": [
6
6
  "edf",
package/src/constants.ts CHANGED
@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
93
93
  } as const;
94
94
 
95
95
  /** Published package version. Kept in sync with package.json by a test. */
96
- export const VERSION = '0.4.314';
96
+ export const VERSION = '0.4.316';