Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #174243 > unrolled thread
| Started by | candycane@f172.n1.z21.fsxnet (candycane) |
|---|---|
| First post | 2023-09-06 19:53 +1300 |
| Last post | 2023-09-09 10:23 -0700 |
| Articles | 20 on this page of 129 — 12 participants |
Back to article view | Back to comp.lang.c
Re: bart again (UCX64) candycane@f172.n1.z21.fsxnet (candycane) - 2023-09-06 19:53 +1300
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-07 12:00 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:33 -0700
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-07 20:55 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 22:16 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-08 07:09 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 10:10 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 01:30 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 11:26 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 10:44 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 13:26 +0200
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:57 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 18:36 +0200
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 18:19 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 13:28 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-10 13:20 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 15:19 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-10 16:07 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 18:33 +0200
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-10 15:44 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 18:36 +0200
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:48 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 19:04 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 02:47 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 16:03 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 16:06 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-09 01:52 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 18:16 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-09 21:31 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 12:03 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-10 21:36 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 08:51 +0200
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-10 23:59 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 01:01 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 11:17 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 03:16 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 14:58 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 06:35 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-11 14:13 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 16:24 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-11 14:55 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 16:42 +0200
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-11 14:29 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-11 11:25 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 03:59 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-11 13:57 +0000
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 09:52 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 16:07 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-11 16:26 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-11 16:47 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-11 19:14 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-11 22:30 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-11 23:07 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-11 23:31 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-12 09:18 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-12 03:01 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 10:08 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-11 23:18 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-11 23:37 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 15:46 -0700
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-11 23:40 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-12 01:50 +0100
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-11 17:59 -0700
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-12 01:03 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-12 02:39 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-12 11:28 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-12 14:49 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-12 15:18 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-12 03:58 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-12 02:25 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-12 16:17 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-12 17:28 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-12 21:07 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-13 03:01 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 09:38 +0200
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 10:00 +0200
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-19 05:22 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-19 14:29 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-13 13:35 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-13 20:48 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-19 05:53 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-12 09:33 -0700
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-12 16:48 +0000
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-12 10:57 -0700
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-12 18:07 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-12 21:23 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 02:07 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 12:43 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 04:04 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 14:07 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 01:47 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 13:02 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 04:45 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 14:36 +0200
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-13 13:43 +0000
Re: bart again (UCX64) James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-13 11:10 -0400
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-13 17:12 +0000
[meta] spam in thread Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 11:22 -0700
Re: [meta] spam in thread Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-13 18:40 +0000
Re: [meta] spam in thread Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 11:48 -0700
Re: [meta] spam in thread David Brown <david.brown@hesbynett.no> - 2023-09-13 21:01 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-13 19:58 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-18 12:36 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-18 13:40 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-20 19:43 -0700
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-20 20:14 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-20 22:10 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-01 11:03 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 07:39 -0700
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-13 15:18 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 18:39 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-13 15:44 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-13 08:42 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-13 22:35 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-13 18:49 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-11 15:40 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-12 03:36 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-12 12:58 +0200
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-12 12:49 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-12 12:52 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-12 05:22 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-12 15:05 +0200
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 02:17 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 14:44 +0200
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-08 14:36 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:50 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-09 15:40 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 09:57 +0200
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-09 10:23 -0700
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-13 21:01 +0200 |
| Subject | Re: [meta] spam in thread |
| Message-ID | <udt0ui$28fot$1@dont-email.me> |
| In reply to | #175408 |
On 13/09/2023 20:22, Malcolm McLean wrote: > The newsgroup is suffering from a severe spam problem. > For the first time in the current blizzard, spam has been > injected into a legiitmate thread itself. Which will cause major > problems for me in filtering. > There have been a few spam messages sent as replies in valid threads - this is not the first one in recent times, though most have been as the start of new threads. Spam is a PITA. It all comes from google groups posters, which is why some people simply filter out everything from GG. Filter rules or killfiles in real newsreaders makes it a bit more manageable, but still highly annoying.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-13 19:58 +0100 |
| Message-ID | <871qf1oq86.fsf@bsb.me.uk> |
| In reply to | #175405 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: > On 2023-09-13, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> On 9/13/23 09:43, Scott Lurndal wrote: >> ... >>> Indeed, NaN is a term of art referring specifically to the IEEE >>> floating point standard. I've never seen "NaN" used in any >>> other context (albeit some use it to refer to their grandmother :-). >> >> Most general rules have at least one exception. >> >> The wikipedia article on NaNs points out that there is a private >> standard for something called posits, which are an alternative to IEEE >> 754. They have a similar concept NaR:="Not a Real", which differs from a >> NaN mainly in that NaRs compare equal to each other. > > Speaking of which, I would prefer that NaN values compare equal > to themselves; i.e. if two operands are NaNs of the same bit pattern, > they compare equal. You can always (as of course you know) fall back on memcmp. > It's a repugnancy that they do not. Though it used to be very handy since n != n could test for a NaN. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-18 12:36 -0700 |
| Message-ID | <861qevmfym.fsf@linuxsc.com> |
| In reply to | #175392 |
scott@slp53.sl.home (Scott Lurndal) writes:
> NaN is a term of art referring specifically to the IEEE
> floating point standard. I've never seen "NaN" used in any
> other context (albeit some use it to refer to their grandmother :-).
The C standard uses (and also defines) the word NaN as a generic
term applicable to floating-point representations in general. In
section 5.2.4.2.2 paragraph 3, the C standard says this
A /NaN/ is an encoding signifying Not-a-Number.
with the slant characters meaning italics, which indicates a
definition. The same paragraph gives generic definitions for
the more specialized terms "quiet NaN" and "signaling NaN".
There is a footnote that mentions the IEEE floating-point
standard, but makes clear that terms for the various kinds of NaN
can refer to values in other floating-point systems that have
similar behavior.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-18 13:40 -0700 |
| Message-ID | <87edivkyfu.fsf@nosuchdomain.example.com> |
| In reply to | #175938 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> NaN is a term of art referring specifically to the IEEE
>> floating point standard. I've never seen "NaN" used in any
>> other context (albeit some use it to refer to their grandmother :-).
>
> The C standard uses (and also defines) the word NaN as a generic
> term applicable to floating-point representations in general. In
> section 5.2.4.2.2 paragraph 3, the C standard says this
>
> A /NaN/ is an encoding signifying Not-a-Number.
>
> with the slant characters meaning italics, which indicates a
> definition. The same paragraph gives generic definitions for
> the more specialized terms "quiet NaN" and "signaling NaN".
>
> There is a footnote that mentions the IEEE floating-point
> standard, but makes clear that terms for the various kinds of NaN
> can refer to values in other floating-point systems that have
> similar behavior.
Agreed, the C standard is careful not to assume that floating-point
systems other than IEEE do or do not have NaNs.
In the real world, as far as I can tell, IEEE happens to be the
only floating-point system that has NaNs. IEEE introduced NaNs
in 1985, and the introduction of the IEEE standard inhibited the
creation of other floating-point formats. (That's not *quite*
true; apparently at least some implementations of "posits" provide
NaNs. But I don't think any C implementation uses posits as its
floating-point representation, and it might not be possible for a
conforming implementation to do so.)
"IEEE" is of course a common shorthand for "IEEE 754".
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-20 19:43 -0700 |
| Message-ID | <86zg1gjlf5.fsf@linuxsc.com> |
| In reply to | #175942 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> scott@slp53.sl.home (Scott Lurndal) writes: >> >>> NaN is a term of art referring specifically to the IEEE >>> floating point standard. I've never seen "NaN" used in any >>> other context (albeit some use it to refer to their grandmother :-). >> >> The C standard uses (and also defines) the word NaN as a generic >> term applicable to floating-point representations in general. In >> section 5.2.4.2.2 paragraph 3, the C standard says this >> >> A /NaN/ is an encoding signifying Not-a-Number. >> >> with the slant characters meaning italics, which indicates a >> definition. The same paragraph gives generic definitions for >> the more specialized terms "quiet NaN" and "signaling NaN". >> >> There is a footnote that mentions the IEEE floating-point >> standard, but makes clear that terms for the various kinds of NaN >> can refer to values in other floating-point systems that have >> similar behavior. > > Agreed, the C standard is careful not to assume that floating-point > systems other than IEEE do or do not have NaNs. > > In the real world, as far as I can tell, IEEE happens to be the > only floating-point system that has NaNs. That question is best left to a different newsgroup. In any case it makes no difference to my statement, which is only about how the term NaN is used. > IEEE introduced NaNs > in 1985, and the introduction of the IEEE standard inhibited the > creation of other floating-point formats. (That's not *quite* > true; apparently at least some implementations of "posits" provide > NaNs. But I don't think any C implementation uses posits as its > floating-point representation, and it might not be possible for a > conforming implementation to do so.) A surprising statement. What is it about posits that make them impossible for a conforming C implementation? TTBOMK the C standard allows nearly unlimited latitude for how floating-point numbers and operations work in C. For the record I know very little about posits. > "IEEE" is of course a common shorthand for "IEEE 754". The C standard uses the designation IEC 60559:1989 (in C11; I haven't checked other versions of the standard).
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-09-20 20:14 -0700 |
| Message-ID | <uegcfh$3b9rp$1@dont-email.me> |
| In reply to | #176122 |
On 9/20/2023 7:43 PM, Tim Rentsch wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> scott@slp53.sl.home (Scott Lurndal) writes: >>> >>>> NaN is a term of art referring specifically to the IEEE >>>> floating point standard. I've never seen "NaN" used in any >>>> other context (albeit some use it to refer to their grandmother :-). >>> >>> The C standard uses (and also defines) the word NaN as a generic >>> term applicable to floating-point representations in general. In >>> section 5.2.4.2.2 paragraph 3, the C standard says this >>> >>> A /NaN/ is an encoding signifying Not-a-Number. >>> >>> with the slant characters meaning italics, which indicates a >>> definition. The same paragraph gives generic definitions for >>> the more specialized terms "quiet NaN" and "signaling NaN". >>> >>> There is a footnote that mentions the IEEE floating-point >>> standard, but makes clear that terms for the various kinds of NaN >>> can refer to values in other floating-point systems that have >>> similar behavior. >> >> Agreed, the C standard is careful not to assume that floating-point >> systems other than IEEE do or do not have NaNs. >> >> In the real world, as far as I can tell, IEEE happens to be the >> only floating-point system that has NaNs. > > That question is best left to a different newsgroup. In any > case it makes no difference to my statement, which is only > about how the term NaN is used. > >> IEEE introduced NaNs >> in 1985, and the introduction of the IEEE standard inhibited the >> creation of other floating-point formats. (That's not *quite* >> true; apparently at least some implementations of "posits" provide >> NaNs. But I don't think any C implementation uses posits as its >> floating-point representation, and it might not be possible for a >> conforming implementation to do so.) > > A surprising statement. What is it about posits that make > them impossible for a conforming C implementation? TTBOMK > the C standard allows nearly unlimited latitude for how > floating-point numbers and operations work in C. For the > record I know very little about posits. > >> "IEEE" is of course a common shorthand for "IEEE 754". > > The C standard uses the designation IEC 60559:1989 (in C11; > I haven't checked other versions of the standard). I wanted to implement posits one time, but never seemed to find it. They are very interesting to me wrt perhaps using them in fractals. Use two posits wrt complex numbers... :^)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-20 22:10 -0700 |
| Message-ID | <87il84158n.fsf@nosuchdomain.example.com> |
| In reply to | #176122 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> NaN is a term of art referring specifically to the IEEE
>>>> floating point standard. I've never seen "NaN" used in any
>>>> other context (albeit some use it to refer to their grandmother :-).
>>>
>>> The C standard uses (and also defines) the word NaN as a generic
>>> term applicable to floating-point representations in general. In
>>> section 5.2.4.2.2 paragraph 3, the C standard says this
>>>
>>> A /NaN/ is an encoding signifying Not-a-Number.
>>>
>>> with the slant characters meaning italics, which indicates a
>>> definition. The same paragraph gives generic definitions for
>>> the more specialized terms "quiet NaN" and "signaling NaN".
>>>
>>> There is a footnote that mentions the IEEE floating-point
>>> standard, but makes clear that terms for the various kinds of NaN
>>> can refer to values in other floating-point systems that have
>>> similar behavior.
>>
>> Agreed, the C standard is careful not to assume that floating-point
>> systems other than IEEE do or do not have NaNs.
>>
>> In the real world, as far as I can tell, IEEE happens to be the
>> only floating-point system that has NaNs.
>
> That question is best left to a different newsgroup. In any
> case it makes no difference to my statement, which is only
> about how the term NaN is used.
You'll note that I started by saying I agreed with you.
I'd say that since the C standard has a lot to say about floating-point,
including NaNs and optional support for IEEE (IEC 60559) floating-point,
it's a relevant issue.
>> IEEE introduced NaNs
>> in 1985, and the introduction of the IEEE standard inhibited the
>> creation of other floating-point formats. (That's not *quite*
>> true; apparently at least some implementations of "posits" provide
>> NaNs. But I don't think any C implementation uses posits as its
>> floating-point representation, and it might not be possible for a
>> conforming implementation to do so.)
>
> A surprising statement. What is it about posits that make
> them impossible for a conforming C implementation? TTBOMK
> the C standard allows nearly unlimited latitude for how
> floating-point numbers and operations work in C. For the
> record I know very little about posits.
Posits, as I understand them, have a dynamically varying number of
exponent bits. That seems inconsistent with the floating point model
described in N1570 5.2.4.2.2 (<float.h>).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-10-01 11:03 -0700 |
| Message-ID | <86a5t2dxu2.fsf@linuxsc.com> |
| In reply to | #176130 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>>> scott@slp53.sl.home (Scott Lurndal) writes: >>>> >>>>> NaN is a term of art referring specifically to the IEEE >>>>> floating point standard. I've never seen "NaN" used in any >>>>> other context (albeit some use it to refer to their grandmother :-). >>>> >>>> The C standard uses (and also defines) the word NaN as a generic >>>> term applicable to floating-point representations in general. In >>>> section 5.2.4.2.2 paragraph 3, the C standard says this >>>> >>>> A /NaN/ is an encoding signifying Not-a-Number. >>>> >>>> with the slant characters meaning italics, which indicates a >>>> definition. The same paragraph gives generic definitions for >>>> the more specialized terms "quiet NaN" and "signaling NaN". >>>> >>>> There is a footnote that mentions the IEEE floating-point >>>> standard, but makes clear that terms for the various kinds of NaN >>>> can refer to values in other floating-point systems that have >>>> similar behavior. >>> >>> Agreed, the C standard is careful not to assume that floating-point >>> systems other than IEEE do or do not have NaNs. >>> >>> In the real world, as far as I can tell, IEEE happens to be the >>> only floating-point system that has NaNs. >> >> That question is best left to a different newsgroup. In any >> case it makes no difference to my statement, which is only >> about how the term NaN is used. > > You'll note that I started by saying I agreed with you. > > I'd say that since the C standard has a lot to say about floating-point, > including NaNs and optional support for IEEE (IEC 60559) floating-point, > it's a relevant issue. I don't know what it is you think your comments are relevant to. I don't see how they are relevant to what I said in my earlier posting. >>> IEEE introduced NaNs >>> in 1985, and the introduction of the IEEE standard inhibited the >>> creation of other floating-point formats. (That's not *quite* >>> true; apparently at least some implementations of "posits" provide >>> NaNs. But I don't think any C implementation uses posits as its >>> floating-point representation, and it might not be possible for a >>> conforming implementation to do so.) >> >> A surprising statement. What is it about posits that make >> them impossible for a conforming C implementation? TTBOMK >> the C standard allows nearly unlimited latitude for how >> floating-point numbers and operations work in C. For the >> record I know very little about posits. > > Posits, as I understand them, have a dynamically varying number of > exponent bits. That seems inconsistent with the floating point model > described in N1570 5.2.4.2.2 (<float.h>). The model you mention is used to define "the characteristics of floating types", where "characteristics" is understood to be the preprocessor-symbol numerical limits defined in that section. There is nothing in the C standard that requires the representation of floating types to match the description outlined in model, or to "be consistent" with it. There is a footnote in the first paragraph of 5.2.4.2.2; it says The floating-point model is intended to clarify the description of each floating-point characteristic and does not require the floating-point arithmetic of the implementation to be identical. So I still don't know why you think a conforming C implementation couldn't use posits, or some other similar scheme where the number of significand bits varies depending on the exponent, as its representation for floating types.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-13 07:39 -0700 |
| Message-ID | <3d75c8ee-f1b2-4ec3-bb5b-485d23a2c634n@googlegroups.com> |
| In reply to | #175386 |
On Wednesday, 13 September 2023 at 13:36:47 UTC+1, David Brown wrote:
> On 13/09/2023 13:45, Malcolm McLean wrote:
> > On Wednesday, 13 September 2023 at 12:02:44 UTC+1, David Brown wrote:
> >> On 13/09/2023 10:47, Malcolm McLean wrote:
> >>> On Tuesday, 12 September 2023 at 19:07:54 UTC+1, Scott Lurndal wrote:
> >>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>> On Tuesday, 12 September 2023 at 17:48:52 UTC+1, Scott Lurndal wrote:
> >>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>> On Tuesday, 12 September 2023 at 16:17:18 UTC+1, Ben Bacarisse wrote:
> >>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>>
> >>>>>>
> >>>>>> In both cases, they're simple integers well within the
> >>>>>> range of a 32-bit unsigned integer and there will never
> >>>>>> be a NaN.
> >>>>>>
> >>>>> So what happens if the sensor doesn't give a reading?
>>>>>>
> >>>> I would assume that the designer would anticipate such a
> >>>> condition and the function that obtains the sensor reading
> >>>> would indicate a failure condition that would be handled
> >>>> according to the design specification. There is no need
> >>>> to use a NaN for that, there are dozens of alternatives.
> >>>>
> >>> So an alternative would be
> >>>
> >>> /* return sensor reading in 16:16 fixed point format, INT_MAX for
> >>> sensor fail */
> >>>
> >>> So what have we done? We got an informally specified NaN. INT_MAX
> >>> is "not a number" in this context.
> >>
> > Scott said "we have no NaNs". But what he meant was that we have no
> > NaNs as formally specified by IEEE.
> I took Scott's "NaNs never occur in my code" comment to mean that NaN's
> - floating point NaNs, since that was the context - do not occur in the
> code he writes. He wrote what he meant (AFAIK), and it was perfectly clear.
>
Yes, it's perfectly clear wht he means. NaN is an IEEE representation which
means that a varaible doesn't hold a number. And he doesn't have any such
representations in his code. And you can do without them. But only by having
an alternative representation that mean s"this variable does not hold a number".
That's what wasn't taken on board and people are struggling with.
You achieve vety little by rejecting the accepted, formally specified, supported
representation of not a number, and substituting your own ad hoc representation.
> > If the sensor doesn't return a reading, you either have to represent that in
> > some way, which means that you need some sort of not a number representation,
> > or you have to make it impossible to read the sensor before checking that it
> > has a value. But the last is hard to achieve in C. (In C++ you can throw if the
> > sensor doesn't have a value, so code that operates on the missing value will
> > never be executed).
> Both are simple to do in C. Exceptions are nothing more than an
> alternative way to return particular types of values that are convenient
> and efficient for some kinds of coding.
>
No look. We have a C interface. In C, the only easy way to write the code to
read the sensors is something like this.
oxygen_flow_t oxygen;
oxygen = readsensors();
/* this code is always reached */
if (doesent_have_a_value(oxygen))
/* handle missing data here */
Of course you could return a bool to indicate the there is no data rather than have
something in oxygen_flow_t to mean the same thing, and there are various variations
on the same theme. But there's esentially only one way to do it. Control returns to the caller,
and "oxygen" is in scope. So if "oxygen" doesn't hold a number, we have to have a way
of representing that.
( I know that you can fiddle about with longjmp() or other ways of not returning to caller,
but they are difficult to implement and going against the language).
In C++ we can do this
oxygen_flow_t readsensors()
{
if (nodata())
throw myexception::sensorfailure;
return always_valid_value();
}
Now the code after the call is not executed unless the return value is valid. So we don't need
a way of representing that an oxygen_flow_t doesn't hold a number, because it always does.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-13 15:18 +0000 |
| Message-ID | <0pkMM.961$Yxl8.700@fx14.iad> |
| In reply to | #175393 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Wednesday, 13 September 2023 at 13:36:47 UTC+1, David Brown wrote: >> > Scott said "we have no NaNs". But what he meant was that we have no >> > NaNs as formally specified by IEEE. >> I took Scott's "NaNs never occur in my code" comment to mean that NaN's >> - floating point NaNs, since that was the context - do not occur in the >> code he writes. He wrote what he meant (AFAIK), and it was perfectly clear. >> >Yes, it's perfectly clear wht he means. NaN is an IEEE representation which >means that a varaible doesn't hold a number. And he doesn't have any such >representations in his code. And you can do without them. But only by having >an alternative representation that mean s"this variable does not hold a number". Indeed one can do without IEEE NaNs. Particularly in real-time, safety critical code. An "alternative representation" (your terminology) isn't a NaN. And the variable does hold a number, a perfectly valid number. As David noted, any value outside of the domain of the problem can be used to signal an error condition. Or it could be a completely separate flag variable. Or any number of possibilities. None of which are NaNs. > >That's what wasn't taken on board and people are struggling with. I think the only person struggling in this conversation is Malcolm. > >You achieve vety little by rejecting the accepted, formally specified, supported >representation of not a number, and substituting your own ad hoc representation. And if my microcontroller doesn't have floating point? >> Both are simple to do in C. Exceptions are nothing more than an >> alternative way to return particular types of values that are convenient >> and efficient for some kinds of coding. >> >No look. We have a C interface. In C, the only easy way to write the code to >read the sensors is something like this. Wow, that's a rather arrogant statement. > >oxygen_flow_t oxygen; > >oxygen = readsensors(); >/* this code is always reached */ >if (doesent_have_a_value(oxygen)) > /* handle missing data here */ bool readsensors(oxygen_flow_t *oxygenp); if (!readsensors(&oxygen)) handle_sensor_borked().
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-13 18:39 +0200 |
| Message-ID | <udsok7$274aa$1@dont-email.me> |
| In reply to | #175393 |
On 13/09/2023 16:39, Malcolm McLean wrote:
> On Wednesday, 13 September 2023 at 13:36:47 UTC+1, David Brown wrote:
>> On 13/09/2023 13:45, Malcolm McLean wrote:
>>> On Wednesday, 13 September 2023 at 12:02:44 UTC+1, David Brown wrote:
>>>> On 13/09/2023 10:47, Malcolm McLean wrote:
>>>>> On Tuesday, 12 September 2023 at 19:07:54 UTC+1, Scott Lurndal wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>> On Tuesday, 12 September 2023 at 17:48:52 UTC+1, Scott Lurndal wrote:
>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>> On Tuesday, 12 September 2023 at 16:17:18 UTC+1, Ben Bacarisse wrote:
>>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>>
>>>>>>>>
>>>>>>>> In both cases, they're simple integers well within the
>>>>>>>> range of a 32-bit unsigned integer and there will never
>>>>>>>> be a NaN.
>>>>>>>>
>>>>>>> So what happens if the sensor doesn't give a reading?
>>>>>>>
>>>>>> I would assume that the designer would anticipate such a
>>>>>> condition and the function that obtains the sensor reading
>>>>>> would indicate a failure condition that would be handled
>>>>>> according to the design specification. There is no need
>>>>>> to use a NaN for that, there are dozens of alternatives.
>>>>>>
>>>>> So an alternative would be
>>>>>
>>>>> /* return sensor reading in 16:16 fixed point format, INT_MAX for
>>>>> sensor fail */
>>>>>
>>>>> So what have we done? We got an informally specified NaN. INT_MAX
>>>>> is "not a number" in this context.
>>>>
>>> Scott said "we have no NaNs". But what he meant was that we have no
>>> NaNs as formally specified by IEEE.
>> I took Scott's "NaNs never occur in my code" comment to mean that NaN's
>> - floating point NaNs, since that was the context - do not occur in the
>> code he writes. He wrote what he meant (AFAIK), and it was perfectly clear.
>>
> Yes, it's perfectly clear wht he means. NaN is an IEEE representation which
> means that a varaible doesn't hold a number. And he doesn't have any such
> representations in his code. And you can do without them. But only by having
> an alternative representation that mean s"this variable does not hold a number".
No, you don't /need/ that.
You don't always need fault detection. If you have fault detection, you
don't always have to pass it back to the calling function. If you have
fault detection and pass it back, you don't always have to have a single
"not a number" state. You might have many. You might pass the validity
or status information in a different way. You might block the reading
until valid data is available.
There are countless alternatives here.
>
> That's what wasn't taken on board and people are struggling with.
>
People struggle to understand why you have such a black-and-white view
of the world, and are so convinced that your own made-up rules apply to
everything.
> You achieve vety little by rejecting the accepted, formally specified, supported
> representation of not a number, and substituting your own ad hoc representation.
Again, nonsense. I really cannot imagine where you get your ideas.
>
>>> If the sensor doesn't return a reading, you either have to represent that in
>>> some way, which means that you need some sort of not a number representation,
>>> or you have to make it impossible to read the sensor before checking that it
>>> has a value. But the last is hard to achieve in C. (In C++ you can throw if the
>>> sensor doesn't have a value, so code that operates on the missing value will
>>> never be executed).
>> Both are simple to do in C. Exceptions are nothing more than an
>> alternative way to return particular types of values that are convenient
>> and efficient for some kinds of coding.
>>
> No look. We have a C interface. In C, the only easy way to write the code to
Once I read "the only easy way", I knew you were wrong. I don't even
need to read further - you are wrong. Every time you think you have the
unique answer, and that every situation fits into one or two neat
categories, you are wrong.
> read the sensors is something like this.
>
> oxygen_flow_t oxygen;
>
> oxygen = readsensors();
> /* this code is always reached */
> if (doesent_have_a_value(oxygen))
> /* handle missing data here */
>
No. That is one way to write it.
It can be a convenient way, but it is not the only way. And the type
here could just wrap a number and have a special value (or range of
values) to indicate problems - or it could be a compound type containing
status information and a reading. Or it could contain multiple
readings, or some kind of confidence indicator (perhaps showing whether
multiple physical sensors agree or disagree).
Or the "readsensors" function might handle problems itself, so that it
only returns valid values. Or you might have a different interface. Or
you might have a system where invalid readings are too unrealistic to
need consideration. Or you might use a separate function to check
validity of the sensors, independent of the "readsensors" function. Or
you might take the value as-is, and use it for the regulator, but have a
higher level function that checks the validity information before
sending the regulator code output to the actual electronics.
Trying to call all this a "kind of NaN" is just silly and highly unhelpful.
> Of course you could return a bool to indicate the there is no data rather than have
> something in oxygen_flow_t to mean the same thing, and there are various variations
> on the same theme. But there's esentially only one way to do it. Control returns to the caller,
> and "oxygen" is in scope. So if "oxygen" doesn't hold a number, we have to have a way
> of representing that.
> ( I know that you can fiddle about with longjmp() or other ways of not returning to caller,
> but they are difficult to implement and going against the language).
>
> In C++ we can do this
>
> oxygen_flow_t readsensors()
> {
> if (nodata())
> throw myexception::sensorfailure;
> return always_valid_value();
> }
>
> Now the code after the call is not executed unless the return value is valid. So we don't need
> a way of representing that an oxygen_flow_t doesn't hold a number, because it always does.
>
That still returns information to the caller - either a valid reading,
or some information about failures. (It does not use a NaN of any sort.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-13 15:44 +0100 |
| Message-ID | <877counnej.fsf@bsb.me.uk> |
| In reply to | #175250 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Tuesday, 12 September 2023 at 16:17:18 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >> It is a mistake to link the error with the two behaviours. A single >> error can provoke either or neither behaviour, sometimes always or >> never. It's not uncommon for an error to go entirely unnoticed because >> the behaviour is always correct. Maybe the fix is to put in "return 0;" >> but that happens to be what is in this or that register on this C >> implementation on this hardware at the point where the call happens. >> >> This is not quibbling or sophistry. The errors are in the text and the >> behaviours are in the world. But We can only fix the text. That is the >> only way a programmer can alter the behaviour. >> > That is a fair point. You can have an error which in fact never provokes incorrect > behaviour. For example to use sign() again, if we write it to return -1 or +1 > and forget the zero, it might well aways return zero when it falls of the end > for the case 0. It would be an error in the program text, but it would behave > correctly. >> >> > I can't >> > think of another behaviour that is erroneous but doesn't fall under >> > one of those two categories (though someone might be able to suggest >> > one). >> I can (timeliness comes to mind) but that would be quibbling. The big >> issue is that I reject the notion that one error implies one of two >> behaviours. >> >> Why does this matter? Because it's just programming. There should be a >> specification where you have left a void for this mystery program. The >> life support system should be specified to provide timely and correct >> results to the oxygen valve or to stop in such a way to provoke other >> systems to trigger the alarms other wise. >> > It's specified to always control the flow of oxygen, based on various > readings it takes from sensors attached to the patient. That might be the first specification, but it will get revised at the first review before a line of code is written. > If it stops controlling the flow > of oxygen, that's very serious. The alarm goes off. The nurse should come. > But it's very much an emergency and undesired. It might be very much desired considering the alternatives. But the point is that something needs to stated so that we know what to implement. You might assume that any sane programmer will, in effect, be implementing my revised spec, but that's not how to do serious work. >> Putting an abort() call and the end of sign(x) (if that is indeed what >> you are suggesting) is called meeting the specification. Of course >> there can be bugs (the call was missing at first) but that is just >> programming. There are, of course, thousands of other fixes. >> > Not. it's not meeting the specification. Now there's a spec, and an impossible one at that! In my remark I had to guess what you want because it was, up to that point, unspecified. (Or did I miss it?) I think the impossible spec is not an accident. You want the discussion to be forced into the wrong result/no result divide, where I insist on failure modes being specified because I want to focus on the correct/incorrect divide. >> That the author >> of sign(x) did not consider NaNs is no different to an author no >> different considering a factor 10^6 error in the flow rate, except that >> it's easier to avoid NaNs than it is to avoid simple typos. >> > sign() has a core domain which includes all the real numbers. You > might know that none of the reals in the program can be lower than > unity. But you can't sensibly trap such numbers and still call the > function sign(). NaN isn't in the core domain. We can sensibly say > that sing(NaN) is NaN, or at a stretch, even 0. But we can also say > that calling sign with NaN is to be considered a programming error. I really, genuinely, have no idea what your point it. You appear to describing the basics of how one writes code, informally, with no clear objectives in mind. We could this, we could that: NaNs are in the domain but not in the core domain. We could return NaN or 0 or trap a programming error if one is passed. >> > You've been reading too much David Brown, and got infected. Anyone with >> > any experience in programming knows that often bugs are very simple and >> > obvious. Once you point them out. But highly qualified programmers still >> > make such mistakes. >> >> I don't believe DB thinks what you believe he does. I certainly don't >> think that. And I resent the notion that I have been "infected" by a >> bad thought, especially one I am sure you have made up out of thin air. >> Please acknowledge that I am perfectly aware that all programmers make >> mistakes. Without that, there is simply no point in continuing. >> > Fair enough. Unlike some other posters, you don't look for > opportuniites to snipe. If you think the NaN comparison error is too > simple, you can always think of a way to make it a bit more subtle > whilst still being bascially the same bug. I am happy to stick with rather artificial examples, but you are not getting to the point. What is the bug? Does the code somehow magic up NaNs and if so from where? Do you agree that one bug can produce many different behaviours and at different times? Do you accept that the specification should say what happens when the sensors fail, or the correct operation can no longer be guaranteed? This discussion feels like nailing a jelly to the fence. > Similar errors do make their way into critical systems where the costs are > extremely high, like spacecraft, and there have been reports. Yes. But what are you proposing to do about it that you think differs from my methods? My proposal is simple to state: minimise the chance of errors in the program; that is cases where the program might not behave as specified. This can include improving the specification as well as the code. Possibly the only disagreement (if you will accept the correct/incorrect classification rather than yours) is that sound reasoning plays a part in my proposal. I would happily include a rigorous code review to ensure that, say, NaNs and Infinities never occur. These are not magic quantities but specific values that arise in tightly controlled and well-specified situations. Such a review is no harder than one that tries to ensure that the value sent to value controller is within the correct technical bounds. >> The issue, which you don't seem to be addressing, is what we do about >> it. We don't just look at code and say, "that looks like a bug, let's >> put an abort() in there". The whole software development process has to >> be geared to minimising the ways in which a program text might fail to >> behave as required. For some programs, the specification is to generate >> correct results or to fail hard. For others it is to keep going at all >> costs. >> >> One technique that can help (in one small area) is to try to ensure that >> there are no NaNs. That can be simpler than putting in tests or other >> actions all over the place in case one has just popped up like a genie >> from a lamp. Note that I am not saying there can't be bugs, but I would >> bet any money that a code review for "don't ever generate a NaN" is >> easier and more effective than a code review for "check everywhere it >> might matter for NaNs and act accordingly". >> > But in this case, readsensors() returns a NaN if the sensors have no data > (not working, or maybe not enough time lag between calls). That's a reasonable > interface. So we can't say "exclude all NaNs for the code". But a NaN still > shouldn't be passed to sign(). That's the programming error. OK. There's a bit more detail. But I can't address it because you don't say what should happen. Anything I propose will be met by "no, that's not meeting the specification". >> > No we can't use Haskell. >> That's a shame. The Glasgow Haskell compiler reports that in >> >> sign :: Double -> Int >> sign x | x < 0 = -1 >> | x == 0 = 0 >> | x > 0 = 1 >> >> the guards are non-exhaustive. >> > That's very good. As it happens (thanks, David) it isn't. The warning can include false positives because the analysis is crude. Of course it still helps if you want look for possible problem areas because there are no false negatives, but it's not doing what I hoped. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-13 08:42 -0700 |
| Message-ID | <10516060-07d5-4914-a389-4d16f7de696an@googlegroups.com> |
| In reply to | #175394 |
On Wednesday, 13 September 2023 at 15:44:37 UTC+1, Ben Bacarisse wrote:
>
> > It's specified to always control the flow of oxygen, based on various
> > readings it takes from sensors attached to the patient.
> That might be the first specification, but it will get revised at the
> first review before a line of code is written.
> > If it stops controlling the flow
> > of oxygen, that's very serious. The alarm goes off. The nurse should come.
> > But it's very much an emergency and undesired.
> It might be very much desired considering the alternatives. But the
> point is that something needs to stated so that we know what to
> implement. You might assume that any sane programmer will, in effect,
> be implementing my revised spec, but that's not how to do serious work.
>
If the alarm goes off because of a programming error, rather than an
electrical fault, then the software hasn't met the specification. If the
device gives the wrong does of oxygen (but one still in the clinical range),
the software also hasn' met the specification. But the alarm going off
is a much less serious failure than the patent suffocating because he
hasn't been given enough oxygen.
>
> I think the impossible spec is not an accident. You want the discussion
> to be forced into the wrong result/no result divide, where I insist on
> failure modes being specified because I want to focus on the
> correct/incorrect divide.
>
Failure doesn't necessarily mean failure of the software. If the sensor
returns the wrong value for the oxygen (but one still within the normal
range) then no software can avoid supplying the wrong oxygen level.
However if the sensor reports an error and the software fails to respond
appropriately, that would be a software failure.
>
> > sign() has a core domain which includes all the real numbers. You
> > might know that none of the reals in the program can be lower than
> > unity. But you can't sensibly trap such numbers and still call the
> > function sign(). NaN isn't in the core domain. We can sensibly say
> > that sing(NaN) is NaN, or at a stretch, even 0. But we can also say
> > that calling sign with NaN is to be considered a programming error.
> I really, genuinely, have no idea what your point it. You appear to
> describing the basics of how one writes code, informally, with no clear
> objectives in mind. We could this, we could that: NaNs are in the
> domain but not in the core domain. We could return NaN or 0 or trap a
> programming error if one is passed.
>
The spec is int sign(double x) return -1 if x is negative, 1 if x is positive,
and 0 if x is zero.
Any function which obeys that specification can legitimately be called
"sign".
So int sign( return x/fabs(x);} would not be sign(), because 0 isn't being
handled correctly. return x ? x/fabs(x) : 0; would however be sign(). It won't
work for infinities, but they aren't in the core domain.
Similarly
int sign(double x)
{
if (isnan(x))
return 2;
....
}
is sign(). NaN isn't in the core doman of sign(). We can legitimately say that
"calling sign() with NaN is undefined". Nowever NaN is is the domain of sign(),
just as infinites are. The sign of not-a-number is surely not a number. But we
dont have to handle all the odd cases to implement what we can reasonably
term "the function sign()".
Now if we know that NaNs can only be passed to sign() as the result of a
programming error, we can exploit this to trap the errors. If isnan(x),
print out various diagnostic messages.
However lets say that, in our program, we know that not only must a NaN represent
a programing error. No real value can go out of the range -100 to 100. If it does,
that must also be a bug.
So can we write
int sign(double x)
{
if (x < -100 || x > 100)
abort();
}
Thje answer is, no we can't. -101 is in the core domain of sign(). If we don't return
-1 ofr it, we should no longer call the function sign().
> I am happy to stick with rather artificial examples, but you are not
> getting to the point. What is the bug? Does the code somehow magic up
> NaNs and if so from where? Do you agree that one bug can produce many
> different behaviours and at different times? Do you accept that the
> specification should say what happens when the sensors fail, or the
> correct operation can no longer be guaranteed? This discussion feels
> like nailing a jelly to the fence.
>
In this case, the sensor had no data. So readsensors() returned NaN,
as it was specified to do. And there is a function called handlesensorfailure()
which is designed to cope with this situation. So correct code is to branch
on the return result, and if it is NaN, call the function which copes with no
data. If it is not Nan, call sign() with the result to decide whether to increase
or decrease the oxygen flow. Simple, unexceptional, non-contrived requirements.
Unfortunately, in this case, the programmer was asleep, and instead of writing
if (isnan(sensor_value))
handlesensorfailure();
else
delta_oxygen_output = sign(sensor_value) * step;
he wrote
if (sensor_value == NaN)
handlesensorfailure();
else
delta_oxygen_value = sign(sensor_value) * step;
Now obviously the intellectually challenged will say "that bug could never occur
in a safety citical enviornment". And they may well be right. So make it the same
underlying mistake but more subtle. These things can and do occur.
The question is how to write sign(). It is called only once in the program. It can never
be passed a NaN. In the plan. In reality, it is passed a NaN.
>
> > Similar errors do make their way into critical systems where the costs are
> > extremely high, like spacecraft, and there have been reports.
> Yes. But what are you proposing to do about it that you think differs
> from my methods? My proposal is simple to state: minimise the chance of
> errors in the program; that is cases where the program might not behave
> as specified.
>
Your method is to wave a magic wand and make the error go away. And of course
it should be caught by testing. In fact the compiler should warn. But however rigorous
your testing, however carefully you adhere to your formal methods, reality is that
the ocasional error like this will slip throuhg the net. The actual example is maybe
a bit too crude, but it's easy enough to make it more subtle, without really adding
anything to the discussion.
So my method is to say "are we running a video game or a life support system?".
If the answer is a video game, then I would write sign(NaN) to return 0. Plough
on and hope that the error is masked. If the answer is a life support system, I
would say "set off the alarm at this point". If the answer is "we don't know, it's
a general purpose library" then I would say "the sign of NaN is NaN. Therefore the
function should be respecifed to return a double, and the error will then propagate
to caller.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-13 22:35 +0100 |
| Message-ID | <87pm2ln4d9.fsf@bsb.me.uk> |
| In reply to | #175398 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
I'm going to skip to the parts that I feel I can get some purchase on...
>> > sign() has a core domain which includes all the real numbers. You
>> > might know that none of the reals in the program can be lower than
>> > unity. But you can't sensibly trap such numbers and still call the
>> > function sign(). NaN isn't in the core domain. We can sensibly say
>> > that sing(NaN) is NaN, or at a stretch, even 0. But we can also say
>> > that calling sign with NaN is to be considered a programming error.
> On Wednesday, 13 September 2023 at 15:44:37 UTC+1, Ben Bacarisse wrote:
>> I really, genuinely, have no idea what your point it. You appear to
>> describing the basics of how one writes code, informally, with no clear
>> objectives in mind. We could this, we could that: NaNs are in the
>> domain but not in the core domain. We could return NaN or 0 or trap a
>> programming error if one is passed.
>>
> The spec is int sign(double x) return -1 if x is negative, 1 if x is positive,
> and 0 if x is zero.
> Any function which obeys that specification can legitimately be called
> "sign".
> So int sign( return x/fabs(x);} would not be sign(), because 0 isn't being
> handled correctly. return x ? x/fabs(x) : 0; would however be sign(). It won't
> work for infinities, but they aren't in the core domain.
> Similarly
> int sign(double x)
> {
> if (isnan(x))
> return 2;
> ....
> }
>
> is sign(). NaN isn't in the core doman of sign(). We can legitimately say that
> "calling sign() with NaN is undefined". Nowever NaN is is the domain of sign(),
> just as infinites are. The sign of not-a-number is surely not a number. But we
> dont have to handle all the odd cases to implement what we can reasonably
> term "the function sign()".
> Now if we know that NaNs can only be passed to sign() as the result of a
> programming error, we can exploit this to trap the errors. If isnan(x),
> print out various diagnostic messages.
>
> However lets say that, in our program, we know that not only must a NaN represent
> a programing error. No real value can go out of the range -100 to 100. If it does,
> that must also be a bug.
> So can we write
>
> int sign(double x)
> {
> if (x < -100 || x > 100)
> abort();
> }
>
> Thje answer is, no we can't. -101 is in the core domain of sign(). If we don't return
> -1 ofr it, we should no longer call the function sign().
I started to reply to some of this but I had to keep picking my jaw up
from the ground. What is this company? How do they hire programmers?
What processes do they have for ensuring code quality?
I suspect the trouble here is you are not playing this game properly.
It's a made-up scenario, but we (you and I) have to play as if it were.
That would mean I could reasonably step in above and say that, as
manager or reviewer, the "spec" for sign(x) would have been rejected out
of hand. For one thing, "negative" is clearly ambiguous and "is" should
generally be avoided in any function using floating point.
Now, for small functions, the code can be taken to be the spec, and
provided there was good internal documentation (just a few lines of
comment about it oddly not covering the argument domain) I would accept
the rather odd code you first posted but I'd insist on an assert at the
top for testing. But since we need this function to get accepted
without that, let's assume I was holiday and the reviewer did not insist
on the assert.
By the way, I try to use "we" only when I an referring to the
participants in a conversation. For the record, almost nothing you
wrote above that used "we" includes me.
>> I am happy to stick with rather artificial examples, but you are not
>> getting to the point. What is the bug? Does the code somehow magic up
>> NaNs and if so from where? Do you agree that one bug can produce many
>> different behaviours and at different times? Do you accept that the
>> specification should say what happens when the sensors fail, or the
>> correct operation can no longer be guaranteed? This discussion feels
>> like nailing a jelly to the fence.
>>
> In this case, the sensor had no data. So readsensors() returned NaN,
> as it was specified to do. And there is a function called
> handlesensorfailure() which is designed to cope with this
> situation. So correct code is to branch on the return result, and if
> it is NaN, call the function which copes with no data. If it is not
> Nan, call sign() with the result to decide whether to increase or
> decrease the oxygen flow. Simple, unexceptional, non-contrived
> requirements.
>
> Unfortunately, in this case, the programmer was asleep, and instead of
> writing
> if (isnan(sensor_value))
> handlesensorfailure();
> else
> delta_oxygen_output = sign(sensor_value) * step;
>
> he wrote
>
> if (sensor_value == NaN)
> handlesensorfailure();
> else
> delta_oxygen_value = sign(sensor_value) * step;
>
> Now obviously the intellectually challenged will say "that bug could
> never occur in a safety citical enviornment". And they may well be
> right. So make it the same underlying mistake but more subtle. These
> things can and do occur.
Did this code pass code review? Did the reviewer see the results of the
unit tests? Are they all interns? Does the team need to hold it's hand
up and admit that this product won't be ready as everyone from the
project manager down needs to go on a few basic training courses?
> The question is how to write sign().
Is it? Why is that the question? Sign has been specified for normal
numbers, subnormal numbers, signed zeros and infinities. It's fine
(though peculiar). You don't go fixing a bug in one place by changing
agreed and working code elsewhere.
Actually question is how can the team be trained in writing unit tests
before the company is sued into oblivion.
> It is called only once in the program. It can never
> be passed a NaN. In the plan. In reality, it is passed a NaN.
It is specified, documented and working. I would not advise changing
it.
But I don't know how we got to this point in the game. Has the bug been
found yet? If so, why is changing 'sign' even being considered? And if
it has not been found, why is changing 'sign' even being considered?
(You might want to delay answering this until later as I ask the same
question again in relation to processes.)
>> > Similar errors do make their way into critical systems where the costs are
>> > extremely high, like spacecraft, and there have been reports.
>> Yes. But what are you proposing to do about it that you think differs
>> from my methods? My proposal is simple to state: minimise the chance of
>> errors in the program; that is cases where the program might not behave
>> as specified.
>>
> Your method is to wave a magic wand and make the error go away.
Absolutely not. It's not magic. It's about well-written specs, good
internal documentation, thorough unit tests, careful code review, sound
integration tests and rigorous code management. But a problem has
slipped through because I was away and someone did not insist on a
function asserting its pre-conditions during testing.
> And of course it should be caught by testing.
It /will/ be found in testing. You can't wave your hand and say
"imagine there's a bug that did not get found in testing" because
although we know such things do occur, to discuss what can be done about
them we need a plausible example.
> In fact the compiler
> should warn. But however rigorous your testing, however carefully you
> adhere to your formal methods, reality is that the ocasional error
> like this will slip throuhg the net. The actual example is maybe a bit
> too crude, but it's easy enough to make it more subtle, without really
> adding anything to the discussion.
We need an example, because without it, I can't see why this team is
going to change sign. The mistake will be found at the very first unit
test and fixed before anyone else even notices (lucky programmer!).
You are trying to have it both ways. To ensure you can reasonably
change 'sign' you need it to be called in only one place, but that also
means there are trivial tests that will spot any error before the call.
> So my method is to say "are we running a video game or a life support
> system?". If the answer is a video game, then I would write sign(NaN)
> to return 0. Plough on and hope that the error is masked. If the
> answer is a life support system, I would say "set off the alarm at
> this point".
What process in the programming team causes this to occur?
Did the test coverage tool discover an untested path in the function?
If so, since it's called in only one place, all eyes can be on that call
to see if there's a problem. (And of course, the missing assert will
also be spotted at that point.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-13 18:49 +0200 |
| Message-ID | <udsp5t$274aa$2@dont-email.me> |
| In reply to | #175394 |
On 13/09/2023 16:44, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> On Tuesday, 12 September 2023 at 16:17:18 UTC+1, Ben Bacarisse wrote: >>> Why does this matter? Because it's just programming. There should be a >>> specification where you have left a void for this mystery program. The >>> life support system should be specified to provide timely and correct >>> results to the oxygen valve or to stop in such a way to provoke other >>> systems to trigger the alarms other wise. >>> >> It's specified to always control the flow of oxygen, based on various >> readings it takes from sensors attached to the patient. > > That might be the first specification, but it will get revised at the > first review before a line of code is written. > >> If it stops controlling the flow >> of oxygen, that's very serious. The alarm goes off. The nurse should come. >> But it's very much an emergency and undesired. > > It might be very much desired considering the alternatives. But the > point is that something needs to stated so that we know what to > implement. You might assume that any sane programmer will, in effect, > be implementing my revised spec, but that's not how to do serious work. > Just as a point of interest, real systems like this are often specified in a manner that would seem counter-intuitive to many. A real oxygen regulation system would likely be specified as having "do nothing" as its primary function. No output, no alarms, no oxygen pressure. That would ensure that the lack of oxygen regulation would be detected by higher up systems (since you don't have an "alarm on" output, you have an "alarm off" output), that it would not injure a patient by pumping high pressure oxygen, and it would not hinder medical personnel from manually helping the patient. Actually regulating the oxygen supply would be very much a secondary and lower priority task for the system.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-11 15:40 -0700 |
| Message-ID | <4817babd-c9ef-4495-9a4e-2c10b161b105n@googlegroups.com> |
| In reply to | #175100 |
On Monday, 11 September 2023 at 23:19:07 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.ar...@gmail.com> writes: > > > On Monday, 11 September 2023 at 16:26:30 UTC+1, Ben Bacarisse wrote: > >> > >> Someone brought up the analogy with a safety belt, but it's no a good > >> one. Covering cases that "can't happen" (it used to be called defensive > >> programming in another bad analogy with defensive driving) is nothing > >> like a safety belt. All it usually does is push the error somewhere > >> else, since if the input was "unexpected" the contrived result will be > >> too. > >> > > That analogy was because David Brown was making out that, because I > > consider the possibility that there might be errors in my code, I'm > > therefore a bad programmer. > That seems very unlikely. Do you have a citation? > > You're right that when a program is incorrect, it's hard to provide correct > > behaviour. But things which are liley to be helpful and things which are > > likely not to be. Bascially programs fall into two categories. > Oh, here we go... > > Life support > > systems, where the worst thing you can do is return wrong results. And > > video games, where the worst thing you can do is return no results. > I am sure you can shoe-horn any other possibility into what you imagine > these two categories contain. > > I will, however note that one is often designing code not programs. The > authors of the C library don't know where it will be linked. > > If the life support system returns the wrong value for the oxygen, then > > the patient suffocates to death. If it crashes out, the alarm goes off, the > > nurse comes running, and the patient is administered emergency manual > > oxygen whilst a new machine is brought. > Is it "crashing out" because a result was wrong or because there was no > result? I'm just curious where this case lies in your arbitrary divide. > Crashing out means no results. The oxygen pipe has some sort of regulator attached to it which receives instructions from our program on how much oxygen to administer to the patient. If the program has an error, then bascially it can malfunction in one of two ways. It can send a wrong result to the regulator instructing it to administer the wrong amount of oxygen to the patient. Or it can send no instructions to the regulator at all. Now obviously if the program is incorrect, there's no way of guaranteeing correct behaviour. But, at risk of flogging the example to death, let's say that the root of the problem is that a NaN is generated, fed to a sign() function, then used to determine whether to increase or decrease the flow. Now we've got several strategies. One is to say "if sign() is called with a NaN that must indicate a programming error. Therefore terminate the program." Another is to say "the sign of NaN is NaN, return NaN". Another is to say "if we return zero the calling function will likely do the right thing. Certainly more likely than if we return 1 or -1, and those are our three options." So with strategy one, we get no results. With strategy two we shunt the decision elsewhere. With strategy three we get what are likely to be wrong results. Now, as I said, if it's a life support system in an environment like a hospital, you definitely want strategy one. The program crashing is no different to the processor ceasing to work because its electrical supply has failed. Any hospital worth it's salt will have procedires in place to deal with that possibility. If the machine just quietly dispeneses a supply of oxygen which is too low, but within normal clinical bounds, the patient is much more likely to die before anyone realises that anything is wrong. And if sign() is a library function, then you need two versions of the library. The life support machine version, and the video games version.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-12 03:36 +0100 |
| Message-ID | <87r0n4p16r.fsf@bsb.me.uk> |
| In reply to | #175102 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Monday, 11 September 2023 at 23:19:07 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >> > On Monday, 11 September 2023 at 16:26:30 UTC+1, Ben Bacarisse wrote: >> >> >> >> Someone brought up the analogy with a safety belt, but it's no a good >> >> one. Covering cases that "can't happen" (it used to be called defensive >> >> programming in another bad analogy with defensive driving) is nothing >> >> like a safety belt. All it usually does is push the error somewhere >> >> else, since if the input was "unexpected" the contrived result will be >> >> too. >> >> >> > That analogy was because David Brown was making out that, because I >> > consider the possibility that there might be errors in my code, I'm >> > therefore a bad programmer. >> That seems very unlikely. Do you have a citation? >> > You're right that when a program is incorrect, it's hard to provide correct >> > behaviour. But things which are liley to be helpful and things which are >> > likely not to be. Bascially programs fall into two categories. >> Oh, here we go... >> > Life support >> > systems, where the worst thing you can do is return wrong results. And >> > video games, where the worst thing you can do is return no results. >> I am sure you can shoe-horn any other possibility into what you imagine >> these two categories contain. >> >> I will, however note that one is often designing code not programs. The >> authors of the C library don't know where it will be linked. >> > If the life support system returns the wrong value for the oxygen, then >> > the patient suffocates to death. If it crashes out, the alarm goes off, the >> > nurse comes running, and the patient is administered emergency manual >> > oxygen whilst a new machine is brought. >> Is it "crashing out" because a result was wrong or because there was no >> result? I'm just curious where this case lies in your arbitrary divide. >> > Crashing out means no results. Oh, OK. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-12 12:58 +0200 |
| Message-ID | <udpg8b$1h6kn$2@dont-email.me> |
| In reply to | #175102 |
On 12/09/2023 00:40, Malcolm McLean wrote: > On Monday, 11 September 2023 at 23:19:07 UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.ar...@gmail.com> writes: >> >>> On Monday, 11 September 2023 at 16:26:30 UTC+1, Ben Bacarisse wrote: >>>> >>>> Someone brought up the analogy with a safety belt, but it's no a good >>>> one. Covering cases that "can't happen" (it used to be called defensive >>>> programming in another bad analogy with defensive driving) is nothing >>>> like a safety belt. All it usually does is push the error somewhere >>>> else, since if the input was "unexpected" the contrived result will be >>>> too. >>>> >>> That analogy was because David Brown was making out that, because I >>> consider the possibility that there might be errors in my code, I'm >>> therefore a bad programmer. >> That seems very unlikely. Do you have a citation? >>> You're right that when a program is incorrect, it's hard to provide correct >>> behaviour. But things which are liley to be helpful and things which are >>> likely not to be. Bascially programs fall into two categories. >> Oh, here we go... >>> Life support >>> systems, where the worst thing you can do is return wrong results. And >>> video games, where the worst thing you can do is return no results. >> I am sure you can shoe-horn any other possibility into what you imagine >> these two categories contain. >> >> I will, however note that one is often designing code not programs. The >> authors of the C library don't know where it will be linked. >>> If the life support system returns the wrong value for the oxygen, then >>> the patient suffocates to death. If it crashes out, the alarm goes off, the >>> nurse comes running, and the patient is administered emergency manual >>> oxygen whilst a new machine is brought. >> Is it "crashing out" because a result was wrong or because there was no >> result? I'm just curious where this case lies in your arbitrary divide. >> > Crashing out means no results. The oxygen pipe has some sort of regulator > attached to it which receives instructions from our program on how > much oxygen to administer to the patient. If the program has an error, > then bascially it can malfunction in one of two ways. It can send a wrong > result to the regulator instructing it to administer the wrong amount > of oxygen to the patient. Or it can send no instructions to the regulator > at all. > > Now obviously if the program is incorrect, there's no way of guaranteeing > correct behaviour. But, at risk of flogging the example to death, let's say > that the root of the problem is that a NaN is generated, fed to a sign() > function, then used to determine whether to increase or decrease the flow. > > Now we've got several strategies. One is to say "if sign() is called with a > NaN that must indicate a programming error. Therefore terminate the program." > Another is to say "the sign of NaN is NaN, return NaN". Another is to say > "if we return zero the calling function will likely do the right thing. Certainly > more likely than if we return 1 or -1, and those are our three options." > > So with strategy one, we get no results. With strategy two we shunt the > decision elsewhere. With strategy three we get what are likely to be wrong > results. > > Now, as I said, if it's a life support system in an environment like a hospital, you > definitely want strategy one. The program crashing is no different to the processor > ceasing to work because its electrical supply has failed. Any hospital worth > it's salt will have procedires in place to deal with that possibility. If the machine > just quietly dispeneses a supply of oxygen which is too low, but within normal > clinical bounds, the patient is much more likely to die before anyone realises that > anything is wrong. > > And if sign() is a library function, then you need two versions of the library. > The life support machine version, and the video games version. > All I can say is that I am glad you write video games for a living, and not the software for life support systems. Perhaps this should be the end of this thread?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-12 12:49 +0200 |
| Message-ID | <udpfn2$1h6kn$1@dont-email.me> |
| In reply to | #175059 |
On 11/09/2023 19:08, Malcolm McLean wrote: > On Monday, 11 September 2023 at 16:26:30 UTC+1, Ben Bacarisse wrote: >> >> Someone brought up the analogy with a safety belt, but it's no a good >> one. Covering cases that "can't happen" (it used to be called defensive >> programming in another bad analogy with defensive driving) is nothing >> like a safety belt. All it usually does is push the error somewhere >> else, since if the input was "unexpected" the contrived result will be >> too. >> > That analogy was because David Brown was making out that, because I > consider the possibility that there might be errors in my code, I'm therefore > a bad programmer. I said nothing of the sort - not even remotely close. I /did/ say that if you don't know what's going on in your code, and what sort of data you have at any particular point in your code, your development processes are flawed. (Note that "I have this double variable that could be anything, including a NaN", is perfectly acceptable for knowing about your data.) I also made it clear that you should write your functions with clear specifications, and use them within those specifications. It is counter-productive to make requirements and then ignore them. Fix bugs in the code in the place where the bugs are - don't try to make all code work in the face of all possible bugs. That's madness. And yes, bad specifications, attempting to make "magic" functions that give the right answer on the wrong input - that /is/ bad programming. > You're right that when a program is incorrect, it's hard to provide correct > behaviour. Please re-read that sentence. Did you /really/ mean to write that? You are telling us that it is "hard" for something that is incorrect to be correct? > But things which are liley to be helpful and things which are > likely not to be. Bascially programs fall into two categories. Life support > systems, where the worst thing you can do is return wrong results. And > video games, where the worst thing you can do is return no results. You're mad. Or you are trolling. It's a spectrum - obviously. > > So you have to know which type of program you are writing before you decide > your error strategy. No, you have to know what kind of error handling you intend for the /code/ you are writing - which might be used in many different kinds of program. You have to know where the boundaries of responsibility lie - do you expect that the person using your code is capable of reading the specifications and following them, or do you have to consider that the person using it is either a moron, or an international hacker, or something in between? Mistakes do happen. Hiding them is a bad idea. Examples of that would include a language/compiler having a default "return 0;" on non-void functions, explicitly adding a "return 0;" when code flow should never reach that point, or having a function that should never be given a NaN have handling for NaNs. An "unreachable();" statement is clearer and avoids misconceptions, as well as giving more efficient code in some cases, and potentially allowing more static error checking. It should be possible to turn it into a trap of some sort (abort, run-time error message, debugger breakpoint, etc.) via either compiler options or changing the definition of a macro or the function - this is something you cannot do with a "return 0;" or "return x;" statement.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-12 12:52 +0100 |
| Message-ID | <udpjda$1hrv7$1@dont-email.me> |
| In reply to | #175185 |
On 12/09/2023 11:49, David Brown wrote: > On 11/09/2023 19:08, Malcolm McLean wrote: >> But things which are liley to be helpful and things which are >> likely not to be. Bascially programs fall into two categories. Life >> support >> systems, where the worst thing you can do is return wrong results. And >> video games, where the worst thing you can do is return no results. > > You're mad. Or you are trolling. > > It's a spectrum - obviously. It's more of a gamut. > Mistakes do happen. Hiding them is a bad idea. Examples of that would > include a language/compiler having a default "return 0;" on non-void > functions, explicitly adding a "return 0;" when code flow should never > reach that point, or having a function that should never be given a NaN > have handling for NaNs. And yet, such default initialisations do exist in C, and they could well hide certain kinds of errors. For example, static objects are set to all zeros unless explicitly initialised. That is generally considered useful, and has come to be something you can confidently rely on. > An "unreachable();" statement is clearer and > avoids misconceptions, as well as giving more efficient code in some > cases, and potentially allowing more static error checking. It should > be possible to turn it into a trap of some sort (abort, run-time error > message, debugger breakpoint, etc.) via either compiler options or > changing the definition of a macro or the function - this is something > you cannot do with a "return 0;" or "return x;" statement. I might use 'return 0' in my language to satisfy a constraint. But I might sometimes return an error code, such as -1, 9999, or i64.min, just in case control does reach that point. I might after all make a modification that could make that possible. Alternately, I can add a call to an error function, one that is defined to have a suitable return type to satisfy the constraint (so no separate return is needed). On PCs, such things have insignificant overheads. I can understand that on your targets, they could be significant. But what you are arguing for is to use such leaner, less foolproof mechanisms even on systems where there are plenty of resources. Ironically, ones which require compilers that need plenty of their own resources to use effectively.
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web