C++ to Ada95 -- bitten!

C++ to Ada95 -- bitten!

[Nick J Chackowsky]

So just when I think I'm getting the idea of Ada95, along comes this
problem, demonstrated by an admittedly contrived program. Gnat 3.13p crashes
trying to compile this:

   with ada.float_text_io;
   with ada.numerics;
   with ada.numerics.elementary_functions;
   use ada.numerics.elementary_functions;
   procedure crash is
      f, g : float;
   begin
      ada.float_text_io.get(f);
      g := 2.7183 ** (-5340)/f + 21.5;
   end crash;

Now, I can eliminate the problem by changing the -5340 to -5340.0, but it
took me a *long* time to see that (in a student's code). I actually thought
I had a virus infecting the student's computer until I watched the "problem"
follow him from workstation to workstation!

I guess my question is, what _category_ of error is this? I know to look
(now) for an integer in a floating-point calculation, but that doesn't tell
me what _else_ I should be looking for to avoid these "virus-like" crashes.

--
=====================================
N J Chackowsky
Brandon, MB  Canada

Re: C++ to Ada95 -- bitten!

[Al Christians]

If you have a problem understanding what is going on, walk in smaller
steps.  I tend to overuse parentheses and split complications into
separate statements.  For example:

 Really_Small_Number := 2.7183 ** (-5340);
 g := (Really_Small_Number / f) + 21.5;

That's probably not what you wanted. How about:
 
 G_Exponent := -5340.0/ f;
 g := 2.7183 ** G_Exponent + 21.5; 		

If you break the expression up into separate statements, the
statement number out of the crash yields more information. 
		
Sometimes my code is criticized for including redundant parentheses,
but that's much better than spacing that suggests an order of operations
to humans but doesn't mean anything to the compiler.

Your: 

>       g := 2.7183 ** (-5340)/f + 21.5;

has  (-5340)/f closely spaced as a clue that it happens before the 
exponentiation.  Check the reference manual (4.5) for the facts. 
I'd always make it explicit, either

       g := ((2.7183 ** (-5340))/f) + 21.5;

or

       g := (2.7183 ** (-5340/f)) + 21.5;


I might omit the outermost set of parens, since everyone(?) knows(?)
that addition happens last.  It just depends on the situation and
on who I guessed might eventually be reading my code.


Al


Nick J Chackowsky wrote:
> 
> So just when I think I'm getting the idea of Ada95, along comes this
> problem, demonstrated by an admittedly contrived program. Gnat 3.13p crashes
> trying to compile this:
> 
>    with ada.float_text_io;
>    with ada.numerics;
>    with ada.numerics.elementary_functions;
>    use ada.numerics.elementary_functions;
>    procedure crash is
>       f, g : float;
>    begin
>       ada.float_text_io.get(f);
>       g := 2.7183 ** (-5340)/f + 21.5;
>    end crash;
> 
> Now, I can eliminate the problem by changing the -5340 to -5340.0, but it
> took me a *long* time to see that (in a student's code). I actually thought
> I had a virus infecting the student's computer until I watched the "problem"
> follow him from workstation to workstation!
> 
> I guess my question is, what _category_ of error is this? I know to look
> (now) for an integer in a floating-point calculation, but that doesn't tell
> me what _else_ I should be looking for to avoid these "virus-like" crashes.
> 
> --
> =====================================
> N J Chackowsky
> Brandon, MB  Canada

Re: C++ to Ada95 -- bitten!

[(null)]

In article <6oBu5.666$zo.17816@news1.mts.net>,
Nick J Chackowsky <nick@arcticmail.com> wrote:
>So just when I think I'm getting the idea of Ada95, along comes this
>problem, demonstrated by an admittedly contrived program. Gnat 3.13p crashes
>trying to compile this:
>
>   with ada.float_text_io;
>   with ada.numerics;
>   with ada.numerics.elementary_functions;
>   use ada.numerics.elementary_functions;
>   procedure crash is
>      f, g : float;
>   begin
>      ada.float_text_io.get(f);
>      g := 2.7183 ** (-5340)/f + 21.5;
>   end crash;

The compiler shouldn't crash no matter what kind of input you feed it.
You should send a bug report to ACT.  The file gnatinfo.txt will explain
where and how to send the bug report.


[snip]

>I guess my question is, what _category_ of error is this? I know to look
>(now) for an integer in a floating-point calculation, 


No, raising 2.7183 to an integer power is fine, what probably killed[1] the compiler was trying to figure out 2.7183 raised the to -5340 power. 


-- 
=======================================================================
 Life is short.                  | Craig Spannring 
      Bike hard, ski fast.       | cts@internetcds.com
 --------------------------------+------------------------------------

Re: C++ to Ada95 -- bitten!

[Nick J Chackowsky]

Ahaaaa... the _compiler_ attempted to "solve" the poorly formed exponent and
crashed in the attempt?

I too would have expected a compile error rather than a compiler crash. I
will submit a bug report.

--
=====================================
N J Chackowsky
Brandon, MB  Canada
"(null)" <cts@kampong.aedinc.net> wrote in message
news:uVCu5.3552$Ek.7557@newsfeed.slurp.net...
> In article <6oBu5.666$zo.17816@news1.mts.net>,
> Nick J Chackowsky <nick@arcticmail.com> wrote:
> >So just when I think I'm getting the idea of Ada95, along comes this
> >problem, demonstrated by an admittedly contrived program. Gnat 3.13p
crashes
> >trying to compile this:
> >
> >   with ada.float_text_io;
> >   with ada.numerics;
> >   with ada.numerics.elementary_functions;
> >   use ada.numerics.elementary_functions;
> >   procedure crash is
> >      f, g : float;
> >   begin
> >      ada.float_text_io.get(f);
> >      g := 2.7183 ** (-5340)/f + 21.5;
> >   end crash;
>
> The compiler shouldn't crash no matter what kind of input you feed it.
> You should send a bug report to ACT.  The file gnatinfo.txt will explain
> where and how to send the bug report.
>
>
> [snip]
>
> >I guess my question is, what _category_ of error is this? I know to look
> >(now) for an integer in a floating-point calculation,
>
>
> No, raising 2.7183 to an integer power is fine, what probably killed[1]
the compiler was trying to figure out 2.7183 raised the to -5340 power.
>
>
> --
> =======================================================================
>  Life is short.                  | Craig Spannring
>       Bike hard, ski fast.       | cts@internetcds.com
>  --------------------------------+------------------------------------

Re: C++ to Ada95 -- bitten!

[Laurent Guerby]

"Nick J Chackowsky" <nick@arcticmail.com> writes:
> Ahaaaa... the _compiler_ attempted to "solve" the poorly formed exponent and
> crashed in the attempt?

That's likely to be the explanation. Note that the compiler is
required by the standard to be exact for static numerical computations.

The following code should print 1.0 on all Ada 95 compilers
(and the constant will be generated at compile time, look at
the assembly generated using the -S GCC switch).

with Ada.Text_IO; use Ada.Text_IO;

procedure PT is
   X : constant := 1.0 + 2.0 ** (-1000);
   Y : constant := 1.0 + 2.0 ** (-1001);
   Z : constant := 2.0 ** (1001) * (X - Y);
begin
   Put_Line (Float'Image (Z));
end PT;


> I too would have expected a compile error rather than a compiler crash. I
> will submit a bug report.

Reasonable. Note that you should mention what compiler you are using
together with its version and the OS (wether you're submitting a bug
or posting here for help ;-).

-- 
Laurent Guerby <guerby@acm.org>

Re: C++ to Ada95 -- bitten!

[Robert Dewar]

In article <867l8kelvx.fsf@acm.org>,
  Laurent Guerby <guerby@acm.org> wrote:
> "Nick J Chackowsky" <nick@arcticmail.com> writes:
> > Ahaaaa... the _compiler_ attempted to "solve" the poorly
formed exponent and
> > crashed in the attempt?

Actually the compiler did not crash, it complained it was
out of memory (Storage_Error raised during compilation), and
indeed that's likely what is going on, since computing that
rather large number absolutely precisely (as required by
the standard since it is a static expression), requires a huge
amount of memory. GNAT does not particularly try to optimize
this kind of case since it is unlikely to occur in correct
programs :-)

A general note is that if you get a Storage_Error, and you
know what caused it (GNAT certainly tells you where you were
in the source), then it is worth checking for this case. Even
if GNAT were to improve its storage efficiency in handling
large expressions, it is always possible (and in fact pretty)
easy, to write ones that will require arbitrary amounts of
memory (and computing power -- absurd static expressions can
also appear to put a compiler into an infinite loop!)




Sent via Deja.com http://www.deja.com/
Before you buy.