edfcore 0.5.41 → 0.5.42
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 +24 -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.42";
|
|
113
113
|
//# sourceMappingURL=constants.d.ts.map
|
package/dist/constants.js
CHANGED
package/docs/CHANGELOG.md
CHANGED
|
@@ -6,6 +6,30 @@ 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.42
|
|
10
|
+
|
|
11
|
+
- **Added** the transformation that changes what the samples MEAN without changing the samples.
|
|
12
|
+
Rewriting `physicalMinimum`/`physicalMaximum` in the header leaves every stored integer identical
|
|
13
|
+
— `decodeDigital` never looks at the range and `toPhysical` never looks at the bytes — and moves
|
|
14
|
+
everything derived from it onto the new scale. Nothing tested the two against each other:
|
|
15
|
+
`physical-values.md` is checked against printed numbers and `out-of-range.test.ts` against the
|
|
16
|
+
digital path, and the relationship between them was prose.
|
|
17
|
+
- The interesting half is the part that does **not** hold. Multiplying the declared range by ten
|
|
18
|
+
multiplies `bitValue` by exactly ten and leaves `offset` untouched — both exact in float64 — and
|
|
19
|
+
yet a quarter of the converted values are not exactly ten times their counterpart.
|
|
20
|
+
`bitValue * (offset + digital)` is a float64 multiply, and scaling an operand is not the same
|
|
21
|
+
operation as scaling the result.
|
|
22
|
+
- That is worth pinning because it is a mistake a caller makes on purpose. Given microvolts and
|
|
23
|
+
wanting millivolts, the obvious move is to divide the values, and the obvious check is that
|
|
24
|
+
dividing the declared range agrees. It does not, in the last place, for a quarter of the range —
|
|
25
|
+
and the last place is what `physical-values.md` spends a page refusing to be casual about.
|
|
26
|
+
- So four things are asserted together: the digital path is bit-identical under the transformation
|
|
27
|
+
and so are the structural numbers and the observed digital range; the scale moves by exactly the
|
|
28
|
+
factor the declaration moved by; every converted value is on its own declared scale exactly; and
|
|
29
|
+
the rescaling identity fails, by at most one unit in the last place and for neither none nor all
|
|
30
|
+
of the values. Distributing the multiply in `toPhysical` — an algebraically equivalent
|
|
31
|
+
rearrangement — fails three of them.
|
|
32
|
+
|
|
9
33
|
## 0.5.41
|
|
10
34
|
|
|
11
35
|
- **Added** a metamorphic test: reordering the signals in a header changes where the bytes are and
|
package/package.json
CHANGED
package/src/constants.ts
CHANGED