Re: How to check a Float for NaN

"Stuart" <stuart@[EMAIL PROTECTED]
> wrote in message
news:4819f65b$1_1@[EMAIL PROTECTED]
> "Adam Beneschan" <adam@[EMAIL PROTECTED]
> wrote in message
> news:fe6a8cc1-eac7-4b25-bd21-39f9c2015c4a@[EMAIL PROTECTED]
> >> Would not 13.9.2(10) cover this:
> >>    "disrupting an assignment due to the failure of a language-defined
> >> check
> >> (see 11.6)"
> >
> > Did you read 11.6?
>
> I tried, but legalese is not my first language and I find some of the
> 'language lawyerly' stuff rather impenetrable at times. ;-)

If either of you can clearly understand and explain 11.6, then you need to
join the ARG immediately and explain it to us. ;-)

Seriously, 11.6 is a very murky part of the Standard, while everyone
understands what is generally intended, its not clear that the wording
actually has the right effect in many detailed cases. Nor is it clear
exactly what boundaries are correct. It was the best that the Ada 95 team
could do, and no one much wants to open the can of worms that it
represents.

We had a series of lengthy and rather heated discussions about the data
validity model in Ada during the Amendment process. We were trying to fix
the Ada 95 problem that if an Unchecked_Conversion produces an invalid
result, using 'Valid to check that result made your program erroneous
(thus,
'Valid could always return True in that case, and in fact at least one
compiler did that). We hacked around with the rules to eliminate that
particular problem (at the cost of making them much more complex).

But we weren't able to completely eliminate the problem (exceptions still
can be raised in this case): the problem being one camp that thinks that
there should be no checks on Unchecked_Conversion ever and the other camp
that will not allow valid objects to become invalid in any cir***stances
(the alternative being erroneous execution, which is uncalled for for
something whose primary purpose is to eliminate checks). We ended up
compromising in the middle (I would have preferred to get rid of the
erroneousness completely, but at least the current rules don't require an
implementer to generate erroneous programs - you can make extra checks to
prevent it).

                                  Randy.