edf2csv 0.5.22 → 0.5.24

package/CHANGELOG.md

@@ -3,6 +3,52 @@
 Notable changes to edf2csv. Versions follow [semantic versioning](https://semver.org); while the
 major version is 0, a minor bump may contain breaking changes.
 
+## 0.5.24
+
+### Fixed: the correctness page described a method it says two hundred lines later was abandoned
+
+"The comparison runs at `--decimals 20`, the most `--decimals` accepts, so what is being
+compared is two computations of a value rather than one of them against its printed form."
+
+It does not. Since 0.4.32 both sides dump their doubles and the 64 bits are compared; nothing
+goes through a CSV, and `compare.py` mentions `--decimals` once, in the past tense, to say it
+used to. The same page explains that change further down. Reading a printed cell back cannot
+be exact at any precision — a cell is a rounded rendering, so parsing it gives the nearest
+double to those digits rather than the double that was computed, which is exactly why the
+method was replaced.
+
+Two more on the same page:
+
+- It gave the derived precision cap as 20. It has been 100 since 0.4.74, and the sentence was
+  making an argument about a magnetometer needing more places than a volt channel — the
+  argument the ceiling was raised for.
+- It said `--decimals 20` prints `0.195360195360195` "from both forms". It prints
+  `0.19536019536019536003`, and the specification's literal ordering prints
+  `0.19536019536019466614` — they first differ at the fifteenth decimal. Which is the
+  difference that section exists to describe, so the sentence was undercutting its own point
+  with a number neither form produces.
+
+## 0.5.23
+
+### Fixed: the `time_s` precision rule was documented as it worked before 0.4.55
+
+Two pages still described the old bound.
+
+output-files.md said the search for a terminating expansion stops at nine places, and its
+table listed 1024 Hz as getting seven decimals and being rounded. The bound has been fifteen
+since 0.4.55; 1024 Hz gets ten and is exact, since 1/1024 terminates at ten. Two of the three
+columns wrong on one row, in a table whose whole subject is that these numbers are derived
+rather than chosen. The closing paragraph then explained a cap that no longer exists.
+
+warnings-and-errors.md said times are "written to at most nine decimal places, which
+separates everything up to a gigahertz", and illustrated `TIME_RESOLUTION` with a warning at
+10 GHz — a rate that terminates at ten places and is written exactly, and does not warn. The
+replacement shows the rate that does: 3e15 Hz, whose reciprocal never terminates.
+
+A test now recomputes every row of that table from `timeDecimals`, including the exact-or-
+rounded column, which it derives rather than reads. Every power of two through 32768 Hz
+terminates inside fifteen places, so the table gains 4096 Hz as well.
+
 ## 0.5.22
 
 ### Fixed: 0.5.12 called a finished conversion unfinished

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "edf2csv",
-  "version": "0.5.22",
+  "version": "0.5.24",
   "description": "Convert EDF, EDF+ and BDF biosignal recordings (European Data Format) to CSV from the command line. Local, streaming, and never resamples or alters units.",
   "keywords": [
     "edf",