[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] nextup.3: minor improvements
From: |
G. Branden Robinson |
Subject: |
Re: [PATCH] nextup.3: minor improvements |
Date: |
Thu, 8 Aug 2024 07:16:03 -0500 |
[looping in groff@gnu]
At 2024-08-08T10:07:35+0200, Alejandro Colomar wrote:
> On Thu, Aug 08, 2024 at 04:56:36AM GMT, Vincent Lefevre wrote:
> > On 2024-08-07 23:19:56 +0200, Alejandro Colomar wrote:
> > > Hi Vincent,
> > >
> > > On Wed, Aug 07, 2024 at 12:56:17PM GMT, Vincent Lefevre wrote:
> > > > The current "If x is 0" is a bit misleading because "is" is not
> > > > the equality test, while this condition should apply to both -0
> > > > and 0. Replace this condition by "If x is equal to 0".
> > >
> > > How does 'is' differ semantically from 'is equal to' in this case?
> >
> > "is" designates the value (it is a short for "has the value").
> > For instance, in the same man page (with the typo fixed):
> > "If x is NaN" (saying "is equal to" would be incorrect, because
> > the equality comparison with NaN is always false).
> >
> > That's why the sqrt(3) man page has
> >
> > If x is +0 (-0), +0 (-0) is returned.
> >
> > and the cbrt(3) man page has
> >
> > If x is +0, -0, positive infinity, [...]
> >
> > "is equal to" corresponds to the usual equality, as written in
> > a source code. (IEEE 754-2019 actually uses "equals".)
> >
> > For zero, one can also say "If x is ±0" as in the IEEE 754 standard.
> > The IEEE 754 standard also uses "zero" in the sense "±0" (but it
> > never uses "0" in this sense when there may be an ambiguity, knowing
> > that in practice, "0" has the same meaning as "+0"). In a condition,
> > when it says something like "x = 0", this means that x is either +0
> > or -0 because these values compare equal to each other.
>
> Hmmm, I see. Thanks! I think "If x is ±0" is the clearest way to say
> it. I'm not sure if that glyph is available everywhere, though. How
> about "If x is 0 or -0"?
I think it's reasonable to assume that it's available.[1] groff's
terminal output devices will either output it as-is or substitute a
fallback.
$ printf '±\n' | groff -K utf8 -T ascii | cat -s
+-
An argument could be made that this fallback should render "+/-"
instead.
With low-capability devices, there's often no single best answer to how
one should limp along.
In groff, of course, you can ask an output device whether it supports a
given glyph and define a string appropriately--but the first part of
that is not portable to formatters that don't implement groff
extensions, and doing so could rouse the ire of Ingo Schwarze's
mandoc(1).
Regards,
Branden
[1] The ± symbol was in the Seventh Edition Unix troff glyph repertoire
and is also in ISO 8859-1. I conclude that it's as portable as
anything not in US-ASCII gets.
signature.asc
Description: PGP signature
- Re: [PATCH] nextup.3: minor improvements,
G. Branden Robinson <=
- Re: [PATCH] nextup.3: minor improvements, Vincent Lefevre, 2024/08/08
- Re: [PATCH] nextup.3: minor improvements, Dave Kemper, 2024/08/08
- Re: [PATCH] nextup.3: minor improvements, John Gardner, 2024/08/09
- Re: [PATCH] nextup.3: minor improvements, G. Branden Robinson, 2024/08/09
- Re: [PATCH] nextup.3: minor improvements, John Gardner, 2024/08/09
- Re: [PATCH] nextup.3: minor improvements, G. Branden Robinson, 2024/08/09
- Re: [PATCH] nextup.3: minor improvements, John Gardner, 2024/08/09
- Re: [PATCH] nextup.3: minor improvements, G. Branden Robinson, 2024/08/09
- Re: [PATCH] nextup.3: minor improvements, Damian McGuckin, 2024/08/09
- Re: [PATCH] nextup.3: minor improvements, Vincent Lefevre, 2024/08/09