How to catch NaNs with gnat3.14p

How to catch NaNs with gnat3.14p

[Alexander Boucke]

Hello!

One of the announced features of gnat3.14p is the ability to raise contraint
error, when NaN or Inf occures. But how to do it? I was not able to find
something about this in the documentation. And the following program just
behaves as with gnat3.13p:

with ada.text_io; use ada.text_io;
procedure nan is
   float1, float2 : float := 0.0;
   a_nan : float;
begin
   a_nan := float1/float2;
   if not a_nan'valid then
      put_line("A NaN occured " & a_nan'img);
   else
      put_line(a_nan'img);
   end if;
end nan;

compiling (gnatmake -gnato nan) yields the output:
> ./nan
A NaN occured NaN********
>

Did I miss something?

Regards,
Alexander

Re: How to catch NaNs with gnat3.14p

[Preben Randhol]

On Fri, 1 Feb 2002 14:49:56 +0100, Alexander Boucke wrote:
> Hello!
> 
> One of the announced features of gnat3.14p is the ability to raise contraint
> error, when NaN or Inf occures. But how to do it? I was not able to find
[...]
> 
> Did I miss something?

I don't have 3.14p yes, so what does it say in the : Run-time Checks
part of the GNAT User Guide? In 3.13p it says:

`-gnato'
     Enables overflow checking for integer operations.  This causes
     GNAT to generate slower and larger executable programs by adding
     code to check for both overflow and division by zero (resulting in
     raising `Constraint_Error' as required by Ada semantics).  Note
     that the `-gnato' switch does not affect the code generated for
     any floating-point operations; it applies only to integer
     operations. For floating-point, GNAT has the `Machine_Overflows'
     attribute set to `False' and the normal mode of operation is to
     generate IEEE NaN and infinite values on overflow or invalid
     operations (such as dividing 0.0 by 0.0).


-- 
Preben Randhol         �For me, Ada95 puts back the joy in programming.�

Re: How to catch NaNs with gnat3.14p

[Alexander Boucke]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]


Preben Randhol wrote in message ...
>I don't have 3.14p yes, so what does it say in the : Run-time Checks
>part of the GNAT User Guide? In 3.13p it says:
>
>`-gnato'
>     Enables overflow checking for integer operations.  This causes
>     GNAT to generate slower and larger executable programs by adding
>     code to check for both overflow and division by zero (resulting in
>     raising `Constraint_Error' as required by Ada semantics).  Note
>     that the `-gnato' switch does not affect the code generated for
>     any floating-point operations; it applies only to integer
>     operations. For floating-point, GNAT has the `Machine_Overflows'
>     attribute set to `False' and the normal mode of operation is to
>     generate IEEE NaN and infinite values on overflow or invalid
>     operations (such as dividing 0.0 by 0.0).
>
>
>--
>Preben Randhol         �For me, Ada95 puts back the joy in programming.�

This read similar in the gnat3.14p UG, but in the features-file included it
says
that gnat has now been modified so that all generated NaNs "will always fail
any range check and cause Constraint_Error to be raised". That's what I was
looking for.

Regards,
Alexander

Re: How to catch NaNs with gnat3.14p

[Preben Randhol]

On Fri, 1 Feb 2002 15:37:05 +0100, Alexander Boucke wrote:
> 
> This read similar in the gnat3.14p UG, but in the features-file included it
> says
> that gnat has now been modified so that all generated NaNs "will always fail
> any range check and cause Constraint_Error to be raised". That's what I was
> looking for.

For floats too or just Integers?


-- 
Preben Randhol         �For me, Ada95 puts back the joy in programming.�

Re: How to catch NaNs with gnat3.14p

[Alexander Boucke]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 427 bytes --]


Preben Randhol wrote in message ...
>> that gnat has now been modified so that all generated NaNs "will always
fail
>> any range check and cause Constraint_Error to be raised". That's what I
was
>> looking for.
>
>For floats too or just Integers?
>
>
>--
>Preben Randhol         �For me, Ada95 puts back the joy in programming.�

Err... As I understand NaN is only defined in the floating-point
environment.
Alexander

Re: How to catch NaNs with gnat3.14p

[Preben Randhol]

On Fri, 1 Feb 2002 15:59:32 +0100, Alexander Boucke wrote:
> Err... As I understand NaN is only defined in the floating-point
> environment.

If you look at the -gnato switch it says it is for integers and not
float.

Re: How to catch NaNs with gnat3.14p

[Jeffrey Creem]

Umm..Read manual againto be sure..I think you are still missing stack checks
without
-fstack-check

"Alexander Boucke" <alexb@lufmech.rwth-aachen.de> wrote in message
news:a3eelm$9sq$1@nets3.rz.RWTH-Aachen.DE...
> yes, -gnato says it's only for integers. But using -gnato is my default,
> since this enables all runtime checks unsing gnat (as intended by the RM).
> And since I did not exclude any checks using a pragma, all possible checks
> should now be enabled.
>
> Alexander
>
>

Re: How to catch NaNs with gnat3.14p

[Alexander Boucke]

yes, -gnato says it's only for integers. But using -gnato is my default,
since this enables all runtime checks unsing gnat (as intended by the RM).
And since I did not exclude any checks using a pragma, all possible checks
should now be enabled.

Alexander

Re: How to catch NaNs with gnat3.14p

[Robert Dewar]

"Alexander Boucke" <alexb@lufmech.rwth-aachen.de> wrote in message news:<a3e6eb$2jt$1@nets3.rz.RWTH-Aachen.DE>...
> Did I miss something?

You missed nothing (and please don't bother to read any
of the first five replies in this thread, they are off
on a wild goose chase :-)

You have no constrained types in your program, so there
are no range checks, so you should not be expecting
any range checks. Remember that float and long_float are
unconstrained types in Ada 95.

Re: How to catch NaNs with gnat3.14p

[Robert Dewar]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrna5l92d.786.randhol+abuse@kiuk0156.chembio.ntnu.no

> `-gnato'
>      Enables overflow checking for integer operations.  

This is entirely irrelevant, as per your quote, this
relates to *integer* operations, it has nothing to do 
with floating-point.

Re: How to catch NaNs with gnat3.14p

[Robert Dewar]

"Alexander Boucke" <alexb@lufmech.rwth-aachen.de> wrote in message news:<a3e96l$54u$1@nets3.rz.RWTH-Aachen.DE>...
> This read similar in the gnat3.14p UG, but in the 
> features-file included it says
> that gnat has now been modified so that all generated 
> NaNs "will always fail any range check and cause 
> Constraint_Error to be raised". That's what I was
> looking for.


And indeed this is true, but your original code had no
range checks, since you had only unconstrained floating-point types,
so obviously such a program is
unaffected by a change in the behavior of range checks!

Re: How to catch NaNs with gnat3.14p

[Robert Dewar]

"Jeffrey Creem" <jeff@thecreems.com> wrote in message news:<A5z68.65994$Ln2.14407993@typhoon.ne.mediaone.net>...
> Umm..Read manual againto be sure..I think you are still missing stack checks
> without
> -fstack-check

Yes, and also if you want dynamic elaboration checks RM
style, you need -gnatE, but don't use -gnatE unless you
understand what you are doing. For most users the default
static elaboration checking is safer.

Re: How to catch NaNs with gnat3.14p

[Preben Randhol]

On 1 Feb 2002 22:20:14 -0800, Robert Dewar wrote:
> Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrna5l92d.786.randhol+abuse@kiuk0156.chembio.ntnu.no
> 
>> `-gnato'
>>      Enables overflow checking for integer operations.  
> 
> This is entirely irrelevant, as per your quote, this
> relates to *integer* operations, it has nothing to do 
> with floating-point.

So is this comment! I would appreciate if you didn't cut down my post
in such a bad manner! I said:

   I don't have 3.14p yet, so what does it say in the : Run-time Checks
   part of the GNAT User Guide? In 3.13p it says:

And then I included the snip from the User Guide which clearly states
that the overflow is not checked for floats in 3.13p so if the User
Guide says the same in 3.14p it must mean that there isn't any overflow
checks in 3.14p for floats either.

Preben

Re: How to catch NaNs with gnat3.14p

[Robert Dewar]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrna5nrk4.nc.randhol+abuse@kiuk0152.chembio.ntnu.no>
 
> And then I included the snip from the User Guide which clearly states
> that the overflow is not checked for floats in 3.13p so if the User
> Guide says the same in 3.14p it must mean that there isn't any overflow
> checks in 3.14p for floats either.


Yes that is completely true and accurate, but that is a totally
irrelevant red herring for this particular
thread which is about range checks, not about overflow checks. Range
checks for constrained floating-point types
work perfectly well in GNAT, and as documented, these
range checks will catch NaN's.

So my objection here was that the entire discussion of
overflow checks is irrelevant. The fact that Machine_Overflows is
false has nothing whatever to do
with range checks, which must of course work properly
for all constrained floating-point types regardless of
the setting of Machine_Overflows.

The point is that "work properly" is not defined for invalid data like
NaN's, where the behavior is implementation dependent. What GNAT 3.14
has done is
to define this implementation dependent behavior to
say that a NaN always looks out of range in a range test.

Re: How to catch NaNs with gnat3.14p

[Marc A. Criley]

Robert Dewar wrote:
> 
>  Remember that float and long_float are
> unconstrained types in Ada 95.

When I fully realized a few years ago that the predefined Float type,
unlike Integer, is an unconstrained type, it did make me wonder by what
rationale Float'Last has a value, since 'Last "denotes the upper bound
of the range of S" [3.5 (13)].  Of course in practical implementations
Float would have an upper bound, but the notion of an unconstrained type
having an upper bound seems awkward.

Marc A. Criley
Consultant
Quadrus Corporation
www.quadruscorp.com

Re: How to catch NaNs with gnat3.14p

[Robert Dewar]

"Marc A. Criley" <mcqada95@earthlink.net> wrote in message news:<3C5D2D77.288208B0@earthlink.net>...
> Robert Dewar wrote:
> > 
> >  Remember that float and long_float are
> > unconstrained types in Ada 95.
> 
> When I fully realized a few years ago that the predefined 
> Float type, unlike Integer, is an unconstrained type,

That's a bit misleading, the base range of all integer
types is also uncontrained (e.g. Integer'Base is unconstrained, and
you should routinely use Integer'Base
if you don't care about the extra range, since it can
generate more efficient code). Or, if you declare your
own type My_Int, then similarly use My_Int'Base.

 
> It.did make me wonder by what rationale Float'Last has a 
> value, since 'Last "denotes the upper bound
> of the range of S" [3.5 (13)].

That's confusing. The whole point of these types is that they have a
base range, see below, but this base range does not constrain the
range of possible values.

>  Of course in practical 
> implementations Float would have an upper bound,

Yes, but this upper bound has nothing to do with 'Last in
this case, see below.

> but the notion of an unconstrained type having an upper 
> bound seems awkward.

Indeed and there is no such notion in Ada 95, the whole
point of an unconstrained scalar base type is that it does
NOT have an upper bound from a semantic point of view. However they do
have a base range which has an upper bound,
but this upper bound is not the maximum possible stored
value.

The base range is defined as follows

6   The base range of a scalar type is the range of finite values of
the type that can be represented in every unconstrained object of the
type; it is also
the range supported at a minimum for intermediate values during the
evaluation of expressions involving predefined operators of the type.

Seems clear enough, and note that is quite different from
an upper bound, objects of the unconstrained base type can
(and often do, e.g. extra precision in fpt registers) have
results outside this base range and that's fine. So yes it
would be peculiar to have an upper bound for an unconstrained type,
and the *whole point* is that these
types do NOT have an upper bound, but it is still useful
to have a notion of guaranteed base range that is accomodated by *all*
objects of the unconstrained base type.

So in practice for example, the 'Last of Float is the
upper limit of 32-bit IEEE for a float object stored in
memory, but on the ia32, you might well use an 80-bit
extended float value in a register to represent a Float
object, and that would have a much much larger range.

Robert Dewar

Re: How to catch NaNs with gnat3.14p

[Alexander Boucke]

Thanks,

that was the Answer I was looking for...
Regards,
Alexander

Robert Dewar wrote in message
>
>And indeed this is true, but your original code had no
>range checks, since you had only unconstrained floating-point types,
>so obviously such a program is
>unaffected by a change in the behavior of range checks!

Re: How to catch NaNs with gnat3.14p

[Marc A. Criley]

Robert Dewar wrote:
> 
> "Marc A. Criley" <mcqada95@earthlink.net> wrote in message news:<3C5D2D77.288208B0@earthlink.net>...
> > Robert Dewar wrote:
> > >
> > >  Remember that float and long_float are
> > > unconstrained types in Ada 95.
> >
> > When I fully realized a few years ago that the predefined
> > Float type, unlike Integer, is an unconstrained type,
> 
> That's a bit misleading, the base range of all integer
> types is also uncontrained (e.g. Integer'Base is unconstrained, and
> you should routinely use Integer'Base
> if you don't care about the extra range, since it can
> generate more efficient code). Or, if you declare your
> own type My_Int, then similarly use My_Int'Base.
> 
> 
> > It.did make me wonder by what rationale Float'Last has a
> > value, since 'Last "denotes the upper bound
> > of the range of S" [3.5 (13)].
> 
> That's confusing. The whole point of these types is that they have a
> base range, see below, but this base range does not constrain the
> range of possible values.

I certainly did not intend to be misleading or confusing, and I do
appreciate the explanation of the detail of the concept behind base and
unconstrained ranges.

From an Ada practitioners point-of-view, however, the fact that the
predefined Integer is constrained, the predefined Float is
unconstrained, and 'Last works on both seems odd.

I encountered this when working on my ASIS_Expression_Resolver package a
couple years ago.  AER handles a number of the range-oriented
attributes, so when implementing recognition and evaluation of 'Last, I
invoke Integer_Constraint() on the Type_Definition corresponding to
Integer on the way to getting its upper bound.  Invoking
Real_Range_Constraint() on the Float Type_Definition, however, gave me a
Nil_Element (which it should, since Float is unconstrained). 
Unfortunately I was left then with no way to use ASIS to extract the
value of Float'Last.  The AER implementation ended up specifically
watching for Float'Last and simply evaluating Float'Last internally for
the result.

Marc A. Criley
Consultant
Quadrus Corporation
www.quadruscorp.com

Re: How to catch NaNs with gnat3.14p

[Robert Dewar]

"Marc A. Criley" <mcqada95@earthlink.net> wrote in message news:<3C5E79EB.72BE43D5@earthlink.net>...
> From an Ada practitioners point-of-view, however, the 
> fact that the predefined Integer is constrained, the 
> predefined Float is unconstrained, and 'Last works on 
> both seems odd.

But as I noted, the predefined type Integer'Base is also
unconstrained. So Float'Base and Integer'Base behave exactly the same.

The decision to make Integer constrained and Float unconstrained is a
pragmatic one that recognizes that
most people are perfectly happy to have extra float range
and a lot of hardware can only be used efficiently if float
is allowed to have extra range.

Once again, for base types, the base range is the minimum
range, guaranteed, but it is not a constraint.
> 
> I encountered this when working on my 
> ASIS_Expression_Resolver package a
> couple years ago. 

The ASIS definition is flawed here, I suspect that those
writing it did not understand the new Ada 95 treatment
of base types as unconstrained (the ASIS definition was
derived directly from Ada 83, so it does not always properly handle
Ada 95 features like this).