RFC: doc: extensions: Explain how printf/seq handle precision #7641
Conversation
|
GNU testsuite comparison: |
|
@tertsdiepraam @RenjiSann @jfinkels @sylvestre FYI (trying to figure out who touched floating point code and might be interested ,-)) |
There was a problem hiding this comment.
I think it's a great idea to document these differences!
I think my position would be that these differences are acceptable, since they are correct and also any script that parses these numbers would need to support the formats that we print.
Additionally, I think that our behaviour is more portable, which is a nice bonus.
However, the arbitrary precision might be a performance problem? Have you checked that? If that is negligible, I feel this is acceptable.
docs/src/extensions.md
Outdated
| @@ -97,3 +176,5 @@ Similar to the proc-ps implementation and unlike GNU/Coreutils, `uptime` provide | |||
| ## `base32/base64/basenc` | |||
|
|
|||
| Just like on macOS, `base32/base64/basenc` provides `-D` to decode data. | |||
|
|
|||
| [^1] https://en.cppreference.com/w/c/io/fprintf | |||
There was a problem hiding this comment.
I don't think this is the best source for that. Generally, we should refer to GNU docs or the POSIX specification.
You might find the info on one of these pages:
There was a problem hiding this comment.
Thanks! I think this has what we need: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap05.html#tag_05
(GNU docs reword the same thing, and I think C99 is also very similar in wording)
docs/src/extensions.md
Outdated
| format specified, etc.), so its output will be more correct than GNU coreutils for | ||
| some inputs (e.g. small fractional increments where GNU coreutils uses `long double`). | ||
|
|
||
| The only limitation is that the position of the decimal point is stored in a i64, |
There was a problem hiding this comment.
| The only limitation is that the position of the decimal point is stored in a i64, | |
| The only limitation is that the position of the decimal point is stored in a `i64`, |
There are some difference in behaviour vs GNU coreutils, explain what those are.
Thanks! Yeah, I also suppose that anybody who uses It's perhaps a bit more arguable with
Right. And in a way, it's almost acceptable that a coreutils->uutils update would cause subtle changes somewhat similar to a x86->arm update?
It's fine. For For And now that I'm looking into #7475, it's interesting to see similar precision questions (GNU |
|
GNU testsuite comparison: |
|
I agree, it seems sensible to me to maintain the arbitrary precision and document the differences. You've documented them clearly here! |
There are some difference in behaviour vs GNU coreutils, explain what those are.
RFC, I'd like to get opinions on this. This is basically how uutils will behave after #7631. I think it's better to just say we support arbitrary precision, rather than trying to downgrade accuracy to emulate 64/80/128-bit float behavior.
In particular, for
seq, the GNU coreutils intentionally does not give guarantees in terms of precision (https://www.gnu.org/software/coreutils/manual/coreutils.html#seq-invocation), so I feel it's ok to do better.There is nothing mentioned in
printfabout precision, so I think providing arbitrary precision is also fair. Hexadecimal floating point is a bit complicated, so worth mentioning what architecture-specific behavior we picked.(there are quite a few issues related to this, #7186, #5759, #6244 at least)