uutils
seq: numerical precision issue causing difference from GNU output
This was found by the fuzzer in this job https://github.com/uutils/coreutils/actions/runs/12875524963/job/35897027858?pr=7181#step:7:4790. The logs for this test case started with
Running test ["seq", "18.499885215552325", "-0.0918587338370287", "-5068"]
Test Type: seq
Input: ["18.499885215552325", "-0.0918587338370287", "-5068"]
Rust stdout: 18.4998852155523250
# very long output...
You can narrow the test case down a bit to just
$ seq 18.499885215552325 -0.0918587338370287 -1006.7 |tail
Here is the diff between the output of GNU seq and that of uutils seq:
--- gnu 2025-01-20 16:20:55.686430468 -0500
+++ uutils 2025-01-20 16:20:58.638351255 -0500
@@ -2,9 +2,9 @@
-1005.9087145349917374
-1006.0005732688287661
-1006.0924320026657948
--1006.1842907365028236
--1006.2761494703398523
--1006.3680082041768810
--1006.4598669380139097
+-1006.1842907365028235
+-1006.2761494703398522
+-1006.3680082041768809
+-1006.4598669380139096
-1006.5517256718509383
-1006.6435844056879670
There is a very small difference between some of the numbers due to some numerical precision issue. (The difference is in the last digit.)
Yeah, looks the same. And again, output of uutils is the same as coreutils on arm64...
The GNU implemention clearly gives an incorrect output (as it often does). I hope you are not seeking bug-for-bug compatibility.
nope, here, we will fix the issues, report a bug upstream and document our improvements in https://github.com/uutils/coreutils/blob/main/docs/src/extensions.md
… extensions are not bugs …
hashsum on the surface sounds quite similar to anysum which I'm working on; the idea behind it is to be able to hash in multiple algorithms in parallel (reducing disk I/O allowing simple on the fly hashing in a pipeline while downloading) both when generating a hash and when validating, however it's primary feature is to allow matching at least one of multiple hashes even of the same algorithm.