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 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-11 23:40 +0000 |
| Message-ID | <aANLM.5065$yQ_.2956@fx47.iad> |
| In reply to | #175103 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On Monday, 11 September 2023 at 23:38:08 UTC+1, Bart wrote:
>> On 11/09/2023 23:18, 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.
>> You also gave two extreme examples of applications.
>>
>> Is that good or bad? As you seem to be criticising that here.
>>
>> (But I've lost track of the discussion. To backtrack a little, I think
>> it was the possibility of NaNs in floating-point values that would have
>> caused an example non-void function to unexpectedly hit the closing '}'.)
>>
>Yes. Sign() is an example of a function which a programmer might erroneously
>consider to have a closing brace which is unreachable, because he has forgotten
>that NaN always compares false.When we realise that this is a very real
>possibility, what are the implications for how an unreachable() statement
>should behave?
Actually, sign is a terrible example, period. signbit has been around
for decades and handles NaNs just fine. Why would any programmer sloppily
re-invent that as your purported (and quite broken) 'sign' function?
>However the discussion was derailed by someone sniping that, in his code,
>unexpected NaNs never occur.
He stated that was the case for his code. That's hardly sniping. NaNs
never occur in my code either, unexpected or otherwise[*].
A lot of programmers never use floating point (financial, systems - e.g. OS,
drivers, firmware), etc.
Those who do, must be aware of the rules of IEEE floating point and should
be aware of the pitfalls and gotches, which are all well known and well
documented.
[*] the singular exception is the C++ code which emulates ARM64 floating point,
SIMD and SVE instruction sets, which needs deep understanding of IEEE
floating point, NaNs and everything that goes with it.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-12 01:50 +0100 |
| Message-ID | <udock5$18h8p$1@dont-email.me> |
| In reply to | #175105 |
On 12/09/2023 00:40, Scott Lurndal wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> Yes. Sign() is an example of a function which a programmer might erroneously
>> consider to have a closing brace which is unreachable, because he has forgotten
>> that NaN always compares false.When we realise that this is a very real
>> possibility, what are the implications for how an unreachable() statement
>> should behave?
>
> Actually, sign is a terrible example, period. signbit has been around
> for decades and handles NaNs just fine. Why would any programmer sloppily
> re-invent that as your purported (and quite broken) 'sign' function?
signbit and sign do different things. The former returns {1, ?, 0, 0}
for {-3.0, -0.0, 0.0, 5.0}; the latter returns {-1, 0, 0, 1}. (I don't
have signbit to try it.)
BTW what does signbit return for a NaN value?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-09-11 17:59 -0700 |
| Message-ID | <tJOLM.12399$PtYa.7481@fx16.iad> |
| In reply to | #175109 |
On 9/11/23 5:50 PM, Bart wrote:
> On 12/09/2023 00:40, Scott Lurndal wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>>> Yes. Sign() is an example of a function which a programmer might
>>> erroneously
>>> consider to have a closing brace which is unreachable, because he has
>>> forgotten
>>> that NaN always compares false.When we realise that this is a very real
>>> possibility, what are the implications for how an unreachable()
>>> statement
>>> should behave?
>>
>> Actually, sign is a terrible example, period. signbit has been around
>> for decades and handles NaNs just fine. Why would any programmer
>> sloppily
>> re-invent that as your purported (and quite broken) 'sign' function?
>
> signbit and sign do different things. The former returns {1, ?, 0, 0}
> for {-3.0, -0.0, 0.0, 5.0}; the latter returns {-1, 0, 0, 1}. (I don't
> have signbit to try it.)
>
> BTW what does signbit return for a NaN value?
>
>
My understanding is that signbit ALWAYS returns the sign bit of the
number, so -0.0 will have sign bit of 1, and NaN will depend if the NaN
has the sign bit set or not.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-12 01:03 +0000 |
| Message-ID | <dNOLM.1480$U893.644@fx01.iad> |
| In reply to | #175109 |
Bart <bc@freeuk.com> writes:
>On 12/09/2023 00:40, Scott Lurndal wrote:
>>
>> Actually, sign is a terrible example, period. signbit has been around
>> for decades and handles NaNs just fine. Why would any programmer sloppily
>> re-invent that as your purported (and quite broken) 'sign' function?
>
>signbit and sign do different things. The former returns {1, ?, 0, 0}
>for {-3.0, -0.0, 0.0, 5.0}; the latter returns {-1, 0, 0, 1}. (I don't
>have signbit to try it.)
>
>BTW what does signbit return for a NaN value?
>
Is your internet broken?
$ man signbit
SIGNBIT(3) Linux Programmer's Manual SIGNBIT(3)
NAME
signbit - test sign of a real floating-point number
SYNOPSIS
#include <math.h>
int signbit(x);
Link with -lm.
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
signbit():
_XOPEN_SOURCE >= 600 || _ISOC99_SOURCE ||
_POSIX_C_SOURCE >= 200112L;
or cc -std=c99
DESCRIPTION
signbit() is a generic macro which can work on all real floating-point
types. It returns a nonzero value if the value of x has its sign bit
set.
This is not the same as x < 0.0, because IEEE 754 floating point allows
zero to be signed. The comparison -0.0 < 0.0 is false, but sign-
bit(-0.0) will return a nonzero value.
NaNs and infinities have a sign bit.
RETURN VALUE
The signbit() macro returns nonzero if the sign of x is negative; oth-
erwise it returns zero.
ERRORS
No errors occur.
ATTRIBUTES
Multithreading (see pthreads(7))
The signbit() macro is thread-safe.
CONFORMING TO
C99, POSIX.1-2001. This function is defined in IEC 559 (and the appenā
dix with recommended functions in IEEE 754/IEEE 854).
SEE ALSO
copysign(3)
COLOPHON
This page is part of release 3.53 of the Linux man-pages project. A
description of the project, and information about reporting bugs, can
be found at http://www.kernel.org/doc/man-pages/.
GNU 2013-07-04 SIGNBIT(3)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-12 02:39 +0100 |
| Message-ID | <8734zkqie2.fsf@bsb.me.uk> |
| In reply to | #175109 |
Bart <bc@freeuk.com> writes: > (I don't have signbit to try it.) I thought you had a C implementation? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-12 11:28 +0100 |
| Message-ID | <udpeh3$1gvvl$1@dont-email.me> |
| In reply to | #175127 |
On 12/09/2023 02:39, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> (I don't have signbit to try it.)
>
> I thought you had a C implementation?
>
I didn't realise it was in math.h, I thought it was POSIX.
I don't have it, and the implementation is not trivial as it needs to
work generically.
But using other compilers, I get these results:
x sign(x) signbit(x)
-5.0 -1 1
-0.0 0 1
0.0 0 0
3.0 1 0
nan 0 1
(sign(nan) depends on how sign() is written. My test nans always to be
negative, but gcc shows them as 'nan', and tcc as '-1.#IND'.
The same sign(nan) in my bcc gives -1, as I use ordered comparisons
rather than unordered. I haven't been able to discover what the two
kinds mean, except one gives the opposite results for nans to the other.)
My point was that signbit() and sign() do different things.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-12 14:49 +0100 |
| Message-ID | <871qf3pkmb.fsf@bsb.me.uk> |
| In reply to | #175182 |
Bart <bc@freeuk.com> writes: > On 12/09/2023 02:39, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> (I don't have signbit to try it.) >> I thought you had a C implementation? >> > > I didn't realise it was in math.h, I thought it was POSIX. > > I don't have it, and the implementation is not trivial as it needs to work > generically. You do have it. You have posted results from more than one reasonably full C implementation in the past. > But using other compilers, I get these results: > > x sign(x) signbit(x) > -5.0 -1 1 > -0.0 0 1 > 0.0 0 0 > 3.0 1 0 > nan 0 1 > > (sign(nan) depends on how sign() is written. You are tabulating a function without ether specifying or showing it. Is that useful? > My test nans always to be > negative, but gcc shows them as 'nan', and tcc as '-1.#IND'. > > The same sign(nan) in my bcc gives -1, as I use ordered comparisons rather > than unordered. I don't know what that means, but does it matter? You can write sign(x) to do anything you want it to do. There is (even in this thread) no full specification for what it should do. > My point was that signbit() and sign() do different things. We agree! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-12 15:18 +0100 |
| Message-ID | <udprvh$1j9dt$1@dont-email.me> |
| In reply to | #175220 |
On 12/09/2023 14:49, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> On 12/09/2023 02:39, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: >>> >>>> (I don't have signbit to try it.) >>> I thought you had a C implementation? >>> >> >> I didn't realise it was in math.h, I thought it was POSIX. >> >> I don't have it, and the implementation is not trivial as it needs to work >> generically. > > You do have it. You have posted results from more than one reasonably > full C implementation in the past. I can't see it within bcc's math.h header. Other implementations tend to have it as a macro that relies on libray routines. But the library I use, msvcrt.dll, doesn't export those. And I'm reluctant to implement such library code. (I already have a small, internal support library; I'm planning to remove that and move to inline code.) If you mean within the other C compilers I have, then yes, that's what I just posted about. Maybe you mean I'd previously posted code using signbit, then I'd forgotten!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-12 03:58 +0100 |
| Message-ID | <87ledcp05z.fsf@bsb.me.uk> |
| In reply to | #175101 |
Bart <bc@freeuk.com> writes: > On 11/09/2023 23:18, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@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. > > You also gave two extreme examples of applications. I did not (I hope) suggest that there were only two types. Did I? > (But I've lost track of the discussion. To backtrack a little, I think it > was the possibility of NaNs in floating-point values that would have caused > an example non-void function to unexpectedly hit the closing '}'.) I think so. But the discussion is devoid of all useful context. If the numbers come, for example, from reading integer registers on hardware, (and there is no maths library) provided we don't divide by zero you won't get a floating point NaN. But maybe that's the kind of bug that is being envisioned -- get two integers and divide without checking. But if that's the sort of programmer you have on the team, why worry about sign() and NaN? They might write a function that falls off the end because of a missing case in a switch or a forgotten break. The NaNs will be the least of your worries in those cases. So what is the development process? Who reviews code? Are function contracts checked? How formally? Are test cases properly constructed to give overall coverage? Are tests run with a run-time code sanitiser? Can the team use Haskell instead? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-12 02:25 -0700 |
| Message-ID | <678354ed-d89c-4d45-adfd-1ded3d22eecan@googlegroups.com> |
| In reply to | #175156 |
On Tuesday, 12 September 2023 at 03:59:02 UTC+1, Ben Bacarisse wrote: > Bart <b...@freeuk.com> writes: > > > On 11/09/2023 23:18, 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. > > > > You also gave two extreme examples of applications. > I did not (I hope) suggest that there were only two types. Did I? > No. I did. If a program contains an error, it can behave in two ways. It can return wrong results, or it can return no results. 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). Now for some programs, no results are better than wrong results, for other programs, wrong results are better than no results. There are N! possibilities. N is 2, so there are 2! or 2 types of program. > > (But I've lost track of the discussion. To backtrack a little, I think it > > was the possibility of NaNs in floating-point values that would have caused > > an example non-void function to unexpectedly hit the closing '}'.) > I think so. But the discussion is devoid of all useful context. If the > numbers come, for example, from reading integer registers on hardware, > (and there is no maths library) provided we don't divide by zero you > won't get a floating point NaN. But maybe that's the kind of bug that > is being envisioned -- get two integers and divide without checking. > Thats one way you could generate a NaN. > But if that's the sort of programmer you have on the team, why worry > about sign() and NaN? They might write a function that falls off the > end because of a missing case in a switch or a forgotten break. The > NaNs will be the least of your worries in those cases. > 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. > > So what is the development process? Who reviews code? Are function > contracts checked? How formally? Are test cases properly constructed > to give overall coverage? Are tests run with a run-time code sanitiser? > Can the team use Haskell instead? > No we can't use Haskell.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-12 16:17 +0100 |
| Message-ID | <87ttrzo1zm.fsf@bsb.me.uk> |
| In reply to | #175181 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 12 September 2023 at 03:59:02 UTC+1, Ben Bacarisse wrote:
>> Bart <b...@freeuk.com> writes:
>>
>> > On 11/09/2023 23:18, 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.
>> >
>> > You also gave two extreme examples of applications.
>> I did not (I hope) suggest that there were only two types. Did I?
>>
> No. I did.
I know. I was replying to Bart who implied I did as well.
> If a program contains an error, it can behave in two ways.
What you really mean is that your point requires you to divide all the
possible behaviours into those two classes. Other people, in other
situations, might choose to divide the behaviours into correct or
incorrect. Or into within acceptable bound of accuracy, space and time
utilisation or outside those acceptable bounds. One picks the
classification for the point being made. I am not objecting to the
classification of behaviour, I am objecting to the notion that there is
only one.
> It can return wrong results, or it can return no results.
This bring up another problem relating to how we (you and I) view
programs. To me, a program containing an error (singular) can exhibit a
huge range of behaviour (as can, of course, a correct program). One
"error" (say omitting 'return E;' from the end of function) can result
in what you call wrong results on Wednesdays, correct results on Fridays
and no results when the year is divisible by four.
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.
> 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.
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.
> Now for some programs, no results are better than wrong
> results, for other programs, wrong results are better than no
> results. There are N! possibilities. N is 2, so there are 2! or 2
> types of program.
This division can indeed be forced, but it's not a good one. A better
division is whether the program meets the spec or not. After all, that
is exactly what you are in effect calling for -- that all failures to
provide timely correct settings should be fatal errors.
>> > (But I've lost track of the discussion. To backtrack a little, I think it
>> > was the possibility of NaNs in floating-point values that would have caused
>> > an example non-void function to unexpectedly hit the closing '}'.)
>> I think so. But the discussion is devoid of all useful context. If the
>> numbers come, for example, from reading integer registers on hardware,
>> (and there is no maths library) provided we don't divide by zero you
>> won't get a floating point NaN. But maybe that's the kind of bug that
>> is being envisioned -- get two integers and divide without checking.
>>
> Thats one way you could generate a NaN.
They are not magic. In the situation I described, where the floating
point numbers come from non-zero divisions of integers, you won't get
one. Of course someone could come along later and set
double flow = 0.0/0.0;
but that's just a bug like any other (except maybe much easier to spot).
Setting
double flow = 1e-3;
rather than 1e+3 is also a bug and needs to be caught. 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.
>> But if that's the sort of programmer you have on the team, why worry
>> about sign() and NaN? They might write a function that falls off the
>> end because of a missing case in a switch or a forgotten break. The
>> NaNs will be the least of your worries in those cases.
>>
> 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.
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".
>> So what is the development process? Who reviews code? Are function
>> contracts checked? How formally? Are test cases properly constructed
>> to give overall coverage? Are tests run with a run-time code sanitiser?
>> Can the team use Haskell instead?
>>
> 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.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-12 17:28 +0100 |
| Message-ID | <udq3ip$1kqr9$1@dont-email.me> |
| In reply to | #175241 |
On 12/09/2023 16:17, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> 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. You can do a much simpler check in any language that doesn't need clever analysis or knowledge of the special properties of NaNs. Because the last return/last value is conditional, it can fail, but there is no value associated with that failing path. That can provided in various ways including an 'else' branch of an if-else-if chain.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-12 21:07 +0200 |
| Message-ID | <udqcu3$1milh$1@dont-email.me> |
| In reply to | #175245 |
On 12/09/2023 18:28, Bart wrote: > On 12/09/2023 16:17, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> > >>> 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. To be fair, it will also give the same warning if you replace "Double" with "Int". gcc will do the same - complain about a missing return, even when the parameter is of type "int" and the guards /are/ exhaustive. (Note to Bart - you can try the Haskell code on godbolt.org, just like gcc code. For both gcc and Haskell, you should use -Wall for the warnings.) > > You can do a much simpler check in any language that doesn't need clever > analysis or knowledge of the special properties of NaNs. > > Because the last return/last value is conditional, it can fail, but > there is no value associated with that failing path. > That can certainly be a good first step, though you will get false positives. A smart enough compiler (and neither gcc, clang, not the Glasgow Haskell Compiler are smart enough) could do better if it saw the conditionals actually covered all possibilities, such as a final "if (isnan(x)) return 2;" line. > That can provided in various ways including an 'else' branch of an > if-else-if chain. > >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-13 03:01 +0100 |
| Message-ID | <87o7i6ompu.fsf@bsb.me.uk> |
| In reply to | #175275 |
David Brown <david.brown@hesbynett.no> writes: > On 12/09/2023 18:28, Bart wrote: >> On 12/09/2023 16:17, Ben Bacarisse wrote: >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> >> >>>> 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. > > To be fair, it will also give the same warning if you replace "Double" with > "Int". Well that's disappointing. I thought it was doing a more interesting analysis that would exclude such false positives. I must never have written a set of guards that was not obviously exhaustive. You do of course get a run-time error if you call sign with a NaN. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-13 09:38 +0200 |
| Message-ID | <udroug$21cnu$1@dont-email.me> |
| In reply to | #175317 |
On 13/09/2023 04:01, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 12/09/2023 18:28, Bart wrote: >>> On 12/09/2023 16:17, Ben Bacarisse wrote: >>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>> >>> >>>>> 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. >> >> To be fair, it will also give the same warning if you replace "Double" with >> "Int". > > Well that's disappointing. I thought it was doing a more interesting > analysis that would exclude such false positives. I must never have > written a set of guards that was not obviously exhaustive. > > You do of course get a run-time error if you call sign with a NaN. > You get that in gcc C too, if you use "-fsanitize=undefined". I guess Haskell has somewhat equivalent behaviour as standard (like Ada). Interestingly, if you change the C code to "int", the compiler still warns about "control reaches end of non-void function". However, "-fsanitize=undefined" does not result in extra code - the optimiser is smart enough to see that the invalid return is never reached. I feel a gcc "scope for improvement" bug report coming on...
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-13 10:00 +0200 |
| Message-ID | <udrq7j$21lda$1@dont-email.me> |
| In reply to | #175345 |
On 13/09/2023 09:38, David Brown wrote: > On 13/09/2023 04:01, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 12/09/2023 18:28, Bart wrote: >>>> On 12/09/2023 16:17, Ben Bacarisse wrote: >>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>>> >>>> >>>>>> 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. >>> >>> To be fair, it will also give the same warning if you replace >>> "Double" with >>> "Int". >> >> Well that's disappointing. I thought it was doing a more interesting >> analysis that would exclude such false positives. I must never have >> written a set of guards that was not obviously exhaustive. >> >> You do of course get a run-time error if you call sign with a NaN. >> > > You get that in gcc C too, if you use "-fsanitize=undefined". I guess > Haskell has somewhat equivalent behaviour as standard (like Ada). Sorry - you don't get the run-time check for gcc C, only for gcc C++, since missing returns are not undefined behaviour in C. (They're usually a bad idea, but not undefined behaviour in C. They are UB in C++.) I hadn't noticed that I had a "-x c++" flag in my godbolt.org window. > > Interestingly, if you change the C code to "int", the compiler still > warns about "control reaches end of non-void function". However, > "-fsanitize=undefined" does not result in extra code - the optimiser is > smart enough to see that the invalid return is never reached. > > I feel a gcc "scope for improvement" bug report coming on... > >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-09-19 05:22 -0700 |
| Message-ID | <86wmwml5e3.fsf@linuxsc.com> |
| In reply to | #175317 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > David Brown <david.brown@hesbynett.no> writes: > >> On 12/09/2023 18:28, Bart wrote: >> >>> On 12/09/2023 16:17, Ben Bacarisse wrote: >>> >>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>> >>>>> 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. >> >> To be fair, it will also give the same warning if you replace >> "Double" with "Int". > > Well that's disappointing. I thought it was doing a more interesting > analysis that would exclude such false positives. I must never have > written a set of guards that was not obviously exhaustive. > > You do of course get a run-time error if you call sign with a NaN. When you say there is a run-time error you mean an exception is raised, yes? And the exception can be caught and dealt with by code somewhere up the call chain?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-19 14:29 +0100 |
| Message-ID | <878r92i957.fsf@bsb.me.uk> |
| In reply to | #176023 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 12/09/2023 18:28, Bart wrote: >>> >>>> On 12/09/2023 16:17, Ben Bacarisse wrote: >>>> >>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>>> >>>>>> 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. >>> >>> To be fair, it will also give the same warning if you replace >>> "Double" with "Int". >> >> Well that's disappointing. I thought it was doing a more interesting >> analysis that would exclude such false positives. I must never have >> written a set of guards that was not obviously exhaustive. >> >> You do of course get a run-time error if you call sign with a NaN. > > When you say there is a run-time error you mean an exception > is raised, yes? And the exception can be caught and dealt > with by code somewhere up the call chain? Yes. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-13 13:35 +0100 |
| Message-ID | <87cyymntcg.fsf@bsb.me.uk> |
| In reply to | #175245 |
Bart <bc@freeuk.com> writes:
> On 12/09/2023 16:17, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>
>>> 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.
>
> You can do a much simpler check in any language that doesn't need clever
> analysis or knowledge of the special properties of NaNs.
>
> Because the last return/last value is conditional, it can fail, but there
> is no value associated with that failing path.
But that is not always true. Multiple conditions can be exhaustive.
For example, Malcolm's sign:
double sign(double x)
{
if ( x < 0 ) return -1;
if ( x == 0 ) return 0;
if ( x > 0 ) return 1;
if (isnan(x)) return x;
}
> That can [be] provided in various ways including an 'else' branch of an
> if-else-if chain.
I think you are suggesting that a non-explicit "catch-all" should be
given to make the compiler's job easier. It maybe desirable from the
point of view of controlling diagnostics but the result is less clear so
I think it calls for a comment or even an assertion:
double sign(double x)
{
if (x < 0) return -1;
if (x == 0) return 0;
if (x > 0) return 1;
assert(isnan(x)); // all that's left...
return x;
}
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-09-13 20:48 +0100 |
| Message-ID | <87v8cdn9bk.fsf@bsb.me.uk> |
| In reply to | #175385 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Bart <bc@freeuk.com> writes:
>
>> On 12/09/2023 16:17, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>
>>>> 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.
>>
>> You can do a much simpler check in any language that doesn't need clever
>> analysis or knowledge of the special properties of NaNs.
>>
>> Because the last return/last value is conditional, it can fail, but there
>> is no value associated with that failing path.
>
> But that is not always true. Multiple conditions can be exhaustive.
> For example, Malcolm's sign:
>
> double sign(double x)
> {
> if ( x < 0 ) return -1;
> if ( x == 0 ) return 0;
> if ( x > 0 ) return 1;
> if (isnan(x)) return x;
> }
>
>> That can [be] provided in various ways including an 'else' branch of an
>> if-else-if chain.
>
> I think you are suggesting that a non-explicit "catch-all" should be
Some kind of auto-correct going on there: "an explicit catch-all" not a
non-explicit one.
> given to make the compiler's job easier. It maybe desirable from the
> point of view of controlling diagnostics but the result is less clear so
> I think it calls for a comment or even an assertion:
>
> double sign(double x)
> {
> if (x < 0) return -1;
> if (x == 0) return 0;
> if (x > 0) return 1;
> assert(isnan(x)); // all that's left...
> return x;
> }
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web