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.

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. There is a
particular implementation of posits using C++ templates called
cppPosits, that provides non-standard support for posit NaNs that are
similar to IEEE NaNs.

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().

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.)

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.

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. It's a repugnancy that they do not.

https://en.wikipedia.org/wiki/Law_of_identity

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

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.

On 2023-09-13, Malcolm McLean <malcolm.arthur.mclean@gmail.com> 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.

The main reason you would be having problems filtering is that you're on
Google Groups, where not only does most of the spam originate, but where
you have next to no tools to deal with it.

I don't see a problem here. Everything coming from Google Groups is
killed, except for people on my whitelist, including yourself.

Two idiots from non-Google-group accounts recently started replying to
spam posts. They are turfed. I'm referring to <doctor@doctor.nl2k.ab.ca>
and <yeti@tilde.institute>. That's a minor problem.

Everything looks clean from slrn connected to Eternal September.
The only hint of spam is that the newsgroup might show, say, 31
unread posts, but when I select it, there are only 7.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On Wednesday, 13 September 2023 at 19:40:47 UTC+1, Kaz Kylheku wrote:
> On 2023-09-13, Malcolm McLean <malcolm.ar...@gmail.com> 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.
> The main reason you would be having problems filtering is that you're on
> Google Groups, where not only does most of the spam originate, but where
> you have next to no tools to deal with it.
>
> I don't see a problem here. Everything coming from Google Groups is
> killed, except for people on my whitelist, including yourself.
>
> Two idiots from non-Google-group accounts recently started replying to
> spam posts. They are turfed. I'm referring to <doc...@doctor.nl2k.ab.ca>
> and <ye...@tilde.institute>. That's a minor problem.
>
> Everything looks clean from slrn connected to Eternal September.
> The only hint of spam is that the newsgroup might show, say, 31
> unread posts, but when I select it, there are only 7.
>
I might have to move to a newsreader. I did use one before Google groups
was invented.
But I've only room for one computer, and so it has to be the computer provided
by work. And I'm a bit reluctant to put lots of non-work software on it.

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.

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.

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.

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".

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.

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 */

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?

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 [an 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;
> }

I agree with your sentiment about not worrying about making the
compiler's job easier. For the code, though, I think it's better
to preserve the symmetry of the case tests, and put in a final
failure call - not to make the compiler's job easier, but to make
the intent more apparent to a human reader. An assert() in place
of the final line would do the job instead, except that assert()
calls might be disabled by setting the macro NDEBUG.

double sign(double x)
{
if (isnan(x)) return x;
if (x < 0 ) return -1;
if (x == 0 ) return 0;
if (x > 0 ) return 1;
print_error_message_and_quit( "..whatever.." );
}

Incidentally, putting the test for isnan(x) first allows the
function to work with signaling NaNs as well as quiet NaNs.
(I confess that I don't know if comparing a signaling NaN
to zero gives rise to a program exception.)

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.

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).

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... :^)

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 */

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.