* seq: add the unit test even if they are failing for now
* improve test
Co-authored-by: Daniel Hofstetter <daniel.hofstetter@42dh.com>
---------
Co-authored-by: Daniel Hofstetter <daniel.hofstetter@42dh.com>
* seq: adjust some error messages. GNU's are better
tested by tests/seq/seq.pl
* uucore: remove todo
---------
Co-authored-by: Daniel Hofstetter <daniel.hofstetter@42dh.com>
`seq --format %.2g 10 10` would display `1` because the precision would
not allow room for the decimal point, and the `0` in `10` would be
trimmed as an insignificant trailing `0`.
This has been fixed by only trimming trailing `0` in the presence of a
decimal point.
Change a word in the error message displayed when an increment value
of 0 is provided to `seq`. This commit changes the message from "Zero
increment argument" to "Zero increment value" to match the GNU `seq`
error message.
Add support for the `-f FORMAT` option to `seq`. This option instructs
the program to render each value in the generated sequence using a
given `printf`-style floating point format. For example,
$ seq -f %.2f 0.0 0.1 0.5
0.00
0.10
0.20
0.30
0.40
0.50
Fixes issue #2616.
Fix a bug in which a negative decimal input would not be displayed with
the correct width in the output. Before this commit, the output was
incorrectly
$ seq -w -.1 .1 .11
-0.1
0.0
0.1
After this commit, the output is correctly
$ seq -w -.1 .1 .11
-0.1
00.0
00.1
The code was failing to take into account that the input decimal "-.1"
needs to be displayed with a leading zero, like "-0.1".
Pad infinity and negative infinity values with spaces when using the
`-w` option to `seq`. This corrects the behavior of `seq` to match that
of the GNU version:
$ seq -w 1.000 inf inf | head -n 4
1.000
inf
inf
inf
Previously, it incorrectly padded with 0s instead of spaces.
* seq: use BigDecimal to represent floats
Use `BigDecimal` to represent arbitrary precision floats in order to
prevent numerical precision issues when iterating over a sequence of
numbers. This commit makes several changes at once to accomplish this
goal.
First, it creates a new struct, `PreciseNumber`, that is responsible for
storing not only the number itself but also the number of digits (both
integer and decimal) needed to display it. This information is collected
at the time of parsing the number, which lives in the new
`numberparse.rs` module.
Second, it uses the `BigDecimal` struct to store arbitrary precision
floating point numbers instead of the previous `f64` primitive
type. This protects against issues of numerical precision when
repeatedly accumulating a very small increment.
Third, since neither the `BigDecimal` nor `BigInt` types have a
representation of infinity, minus infinity, minus zero, or NaN, we add
the `ExtendedBigDecimal` and `ExtendedBigInt` enumerations which extend
the basic types with these concepts.
* fixup! seq: use BigDecimal to represent floats
* fixup! seq: use BigDecimal to represent floats
* fixup! seq: use BigDecimal to represent floats
* fixup! seq: use BigDecimal to represent floats
* fixup! seq: use BigDecimal to represent floats
Replace two loops that print leading and trailing 0s when printing a
number in fixed-width mode with a single call to `write!()` with the
appropriate formatting parameters.
Ensure that the `print_seq_integers()` function is called when the first
number and the increment are integers, regardless of the type of the
last value specified.
Change the way `seq` computes the number of digits needed to print a
number so that it works for inputs given in scientific notation.
Specifically, this commit parses the input string to determine whether
it is an integer, a float in decimal notation, or a float in scientific
notation, and then computes the number of integral digits and the number
of fractional digits based on that. This also supports floating point
negative zero, expressed in both decimal and scientific notation.
Fix a bug in `seq` where the number of characters needed to print the
number was computed incorrectly in some cases. This commit changes the
computation of the width to be after parsing the number instead of
before, in order to accommodate inputs like `1e3`, which requires four
digits when printing the number, not three.
GNU seq does not support -t, but always outputs a newline at the end.
Therefore, our default for -t should be \n.
Also removes support for escape sequences (interpreting a literal "\n"
as a newline). This is not what GNU seq is doing, and unexpected.
If we notice that we can represent all arguments as BigInts, take a
different code path. Just like GNU seq this means we can print an
infinite amount of numbers in this case.
