I think - it's a bug...

I think - it's a bug...

[Anatoly Chernyshev]

Hello everybody!

Look at this piece of code:

-------------------------------------------------------------------------------------------------

WITH ada.text_io,ada.numerics.elementary_functions;
USE ada.text_io, ada.numerics.elementary_functions;
PROCEDURE el_stat_fun IS
   b            : float := 7.5;
   a:float:=4.0;
   rr, z : float;
   r            : float := 4.0;
   dz           : float := 0.3;
BEGIN
   FOR k IN 0..integer(b/dz) LOOP
      z:=float(k)*dz;
      put_line (float'image(1.0-(z/b)));
      rr:=-a*sqrt((1.0-(z/b)**2))+a+r;
   END LOOP;
END el_stat_fun;
----------------------------------------------------------------------------------------------------




When compiled using GNAT 3.14 (WinNT sp 6) it raises
ADA.NUMERICS.ARGUMENT_ERROR in sqrt function when k goes to 25 because
the argument for sqrt becomes
negative (like -X.XXXXXE-07 ... And this is a headache No 1).
However, if one comments out the put_line string - everything works
fine.

I don't know whether this is a bug or feature, but any kind of help for
how to avoid the situation when 1.0-1.0/1.0 yields  something different
from 0.0 will be greatly appreciated.

Thanks in advance,

Anatoly.

Re: I think - it's a bug...

[David C. Hoos, Sr.]

This is not a bug.  The problem comes about by not being aware of
the nature of floating point representation in computers.

In your example, the value of dz (0.3) is not exactly representable in
binary -- it is an infinitely repeating binary fraction. Hence, all values of
z that you compute are not exactly representable.

Thus, if the value of dz was rounded upward to the next lsb when
converting from decimal to binary, all values of z will be slightly
larger than their true value.

The only solution is to test the values of which you are about to take
the square root, and if the absolute value is less than some very small
threshold, set the value to 0.0.

Alternatively, if you are sure (given the nature of the problem you
are solving) that z can never be greater than b, you could replace
(z/b) by Float'Min (1.0, z/b).

Additionally, you might want to consider the following statement
from the GNAT User's Guide:
In particular, if the Ada code will do any floating-point operations,
then the FPU must be setup in an appropriate manner. For the case
of the x86, for example, full precision mode is required. The
procedure GNAT.Float_Control.Reset may be used to ensure that
the FPU is in the right state.

Finally you can obtain greater precision by using Long_Float or
Long_Long_Float instead of Float.

----- Original Message -----
From: "Anatoly Chernyshev" <rhezusfactor@yahoo.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: March 10, 2002 2:24 AM
Subject: I think - it's a bug...


> Hello everybody!
>
> Look at this piece of code:
>
> ----------------------------------------------------------------------------
---------------------
>
> WITH ada.text_io,ada.numerics.elementary_functions;
> USE ada.text_io, ada.numerics.elementary_functions;
> PROCEDURE el_stat_fun IS
>    b            : float := 7.5;
>    a:float:=4.0;
>    rr, z : float;
>    r            : float := 4.0;
>    dz           : float := 0.3;
> BEGIN
>    FOR k IN 0..integer(b/dz) LOOP
>       z:=float(k)*dz;
>       put_line (float'image(1.0-(z/b)));
>       rr:=-a*sqrt((1.0-(z/b)**2))+a+r;
>    END LOOP;
> END el_stat_fun;
> ----------------------------------------------------------------------------
------------------------
>
>
>
>
> When compiled using GNAT 3.14 (WinNT sp 6) it raises
> ADA.NUMERICS.ARGUMENT_ERROR in sqrt function when k goes to 25 because
> the argument for sqrt becomes
> negative (like -X.XXXXXE-07 ... And this is a headache No 1).
> However, if one comments out the put_line string - everything works
> fine.
>
> I don't know whether this is a bug or feature, but any kind of help for
> how to avoid the situation when 1.0-1.0/1.0 yields  something different
> from 0.0 will be greatly appreciated.
>
> Thanks in advance,
>
> Anatoly.
>
>
>
>
>
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: I think - it's a bug...

[Anatoly Chernyshev]

"David C. Hoos, Sr." wrote:

> This is not a bug.  The problem comes about by not being aware of
> the nature of floating point representation in computers.
>
> In your example, the value of dz (0.3) is not exactly representable in
> binary -- it is an infinitely repeating binary fraction. Hence, all values of
> z that you compute are not exactly representable.
>
> Thus, if the value of dz was rounded upward to the next lsb when
> converting from decimal to binary, all values of z will be slightly
> larger than their true value.
>

That's true, but still, why inserting of "put_line (float'image(1.0-(z/b)));"
influences the behaviour of the program so much.
Beyound that, I've got similar things with z=0.1 and 0.25. They were solved
though, by using different optomization levels (-O, -O2...).


>
> The only solution is to test the values of which you are about to take
> the square root, and if the absolute value is less than some very small
> threshold, set the value to 0.0.
>
> Alternatively, if you are sure (given the nature of the problem you
> are solving) that z can never be greater than b, you could replace
> (z/b) by Float'Min (1.0, z/b).
>
> Additionally, you might want to consider the following statement
> from the GNAT User's Guide:
> In particular, if the Ada code will do any floating-point operations,
> then the FPU must be setup in an appropriate manner. For the case
> of the x86, for example, full precision mode is required. The
> procedure GNAT.Float_Control.Reset may be used to ensure that
> the FPU is in the right state.

> Finally you can obtain greater precision by using Long_Float or Long_Long_Float
> instead of Float.

Thanks a lot for those suggestions (but you are omitted what is coming from the
GNAT UG).

>

Re: I think - it's a bug...

[David C. Hoos]

I think what happens when the put_line call is present is that the
C runtime library is called, which on NT can result in the
FPU unit state being changed, hence the desirability (or need) to
call GNAT.Float_Control.Reset, as suggested.

The statement from the UG _was_ included, and is:

In particular, if the Ada code will do any floating-point operations,
then the FPU must be setup in an appropriate manner. For the case
of the x86, for example, full precision mode is required. The
procedure GNAT.Float_Control.Reset may be used to ensure that
the FPU is in the right state.

----- Original Message -----
From: "Anatoly Chernyshev" <rhezusfactor@yahoo.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Sunday, March 10, 2002 11:33 PM
Subject: Re: I think - it's a bug...


>
>
> "David C. Hoos, Sr." wrote:
>
> > This is not a bug.  The problem comes about by not being aware of
> > the nature of floating point representation in computers.
> >
> > In your example, the value of dz (0.3) is not exactly representable in
> > binary -- it is an infinitely repeating binary fraction. Hence, all
values of
> > z that you compute are not exactly representable.
> >
> > Thus, if the value of dz was rounded upward to the next lsb when
> > converting from decimal to binary, all values of z will be slightly
> > larger than their true value.
> >
>
> That's true, but still, why inserting of "put_line
(float'image(1.0-(z/b)));"
> influences the behaviour of the program so much.
> Beyound that, I've got similar things with z=0.1 and 0.25. They were
solved
> though, by using different optomization levels (-O, -O2...).
>
>
> >
> > The only solution is to test the values of which you are about to take
> > the square root, and if the absolute value is less than some very small
> > threshold, set the value to 0.0.
> >
> > Alternatively, if you are sure (given the nature of the problem you
> > are solving) that z can never be greater than b, you could replace
> > (z/b) by Float'Min (1.0, z/b).
> >
> > Additionally, you might want to consider the following statement
> > from the GNAT User's Guide:
> > In particular, if the Ada code will do any floating-point operations,
> > then the FPU must be setup in an appropriate manner. For the case
> > of the x86, for example, full precision mode is required. The
> > procedure GNAT.Float_Control.Reset may be used to ensure that
> > the FPU is in the right state.
>
> > Finally you can obtain greater precision by using Long_Float or
Long_Long_Float
> > instead of Float.
>
> Thanks a lot for those suggestions (but you are omitted what is coming
from the
> GNAT UG).
>
> >
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: I think - it's a bug...

[Stephen Leake]

Anatoly Chernyshev <rhezusfactor@yahoo.com> writes:

> That's true, but still, why inserting of "put_line (float'image(1.0-(z/b)));"
> influences the behaviour of the program so much.
> Beyound that, I've got similar things with z=0.1 and 0.25. They were solved
> though, by using different optomization levels (-O, -O2...).

Since that is the _only_ place you have Text_IO, if you leave out the
"put_line", Text_IO is not linked in. Then you don't need the
Microsoft runtime library. The Microsoft runtime library sets the FPU
to the "wrong" mode. If you Use GNAT.Float_Control.Reset, the presence
of "put_line" will no longer matter.

-- 
-- Stephe

Re: I think - it's a bug...

[Jeffrey Carter]

"David C. Hoos, Sr." wrote:
> 
> Additionally, you might want to consider the following statement
> from the GNAT User's Guide:
> In particular, if the Ada code will do any floating-point operations,
> then the FPU must be setup in an appropriate manner. For the case
> of the x86, for example, full precision mode is required. The
> procedure GNAT.Float_Control.Reset may be used to ensure that
> the FPU is in the right state.

Note that this is in the section "Binding with Non-Ada Main Programs",
which clearly doesn't apply in this case.

-- 
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail

Re: I think - it's a bug...

[Wes Groleau]

> This is not a bug.  The problem comes about by not being aware of
> the nature of floating point representation in computers.

Unless I misunderstood the original post, there IS a bug.

If commenting out this

> >       put_line (float'image(1.0-(z/b)));

causes this to stop raising an exception

> >       rr:=-a*sqrt((1.0-(z/b)**2))+a+r;

then I think there must be a bug in the optimizer.

But it should be sent to report@gnat.com and not to comp.lang.ada

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: I think - it's a bug...

[David C. Hoos]

There are two problems, viz.

   1.  When z is essentially equal to b but (say) 1 lsb greater,
         then z/b is greater than 1.0, causing a negative argument
         to sqrt.

   2.   The problem with commenting out the put_line statement I
         believe to be a documented case where the NT C runtime
         can leave the FPU in a bad state.

----- Original Message ----- 
From: "Wes Groleau" <wesgroleau@despammed.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Monday, March 11, 2002 8:53 AM
Subject: Re: I think - it's a bug...


> 
> > This is not a bug.  The problem comes about by not being aware of
> > the nature of floating point representation in computers.
> 
> Unless I misunderstood the original post, there IS a bug.
> 
> If commenting out this
> 
> > >       put_line (float'image(1.0-(z/b)));
> 
> causes this to stop raising an exception
> 
> > >       rr:=-a*sqrt((1.0-(z/b)**2))+a+r;
> 
> then I think there must be a bug in the optimizer.
> 
> But it should be sent to report@gnat.com and not to comp.lang.ada
> 
> -- 
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 

Re: I think - it's a bug...

[Jeffrey Carter]

Anatoly Chernyshev wrote:
> 
> WITH ada.text_io,ada.numerics.elementary_functions;
> USE ada.text_io, ada.numerics.elementary_functions;
> PROCEDURE el_stat_fun IS
>    b            : float := 7.5;
>    a:float:=4.0;
>    rr, z : float;
>    r            : float := 4.0;
>    dz           : float := 0.3;

B, A, R, and Dz are constants. Why not make them named numbers?

> BEGIN
>    FOR k IN 0..integer(b/dz) LOOP
>       z:=float(k)*dz;
>       put_line (float'image(1.0-(z/b)));
>       rr:=-a*sqrt((1.0-(z/b)**2))+a+r;

The parentheses here look funny. Did you perhaps mean

rr:=-a*sqrt((1.0-(z/b))**2)+a+r;

?

>    END LOOP;
> END el_stat_fun;

-- 
Jeff Carter
"English bed-wetting types."
Monty Python & the Holy Grail

Re: I think - it's a bug...

[Anatoly Chernyshev]

Jeffrey Carter wrote:

> Anatoly Chernyshev wrote:
> >
> > WITH ada.text_io,ada.numerics.elementary_functions;
> > USE ada.text_io, ada.numerics.elementary_functions;
> > PROCEDURE el_stat_fun IS
> >    b            : float := 7.5;
> >    a:float:=4.0;
> >    rr, z : float;
> >    r            : float := 4.0;
> >    dz           : float := 0.3;
>
> B, A, R, and Dz are constants. Why not make them named numbers?

This was cut from the much bigger program, actually there they are not
constants.

>
> The parentheses here look funny. Did you perhaps mean
>
> rr:=-a*sqrt((1.0-(z/b))**2)+a+r;

This is just a mistyping - I meant what I meant. Anyway, after removing
of extra brackets the problem still persists.

Re: I think - it's a bug...

[Phil Thornley]

"Anatoly Chernyshev" <rhezusfactor@yahoo.com> wrote in message
news:3C8B184D.49214059@yahoo.com...
> Hello everybody!
>
> Look at this piece of code:
>
> ----------------------------------------------------------------------
---------------------------
>
> WITH ada.text_io,ada.numerics.elementary_functions;
> USE ada.text_io, ada.numerics.elementary_functions;
> PROCEDURE el_stat_fun IS
>    b            : float := 7.5;
>    a:float:=4.0;
>    rr, z : float;
>    r            : float := 4.0;
>    dz           : float := 0.3;
> BEGIN
>    FOR k IN 0..integer(b/dz) LOOP
>       z:=float(k)*dz;
>       put_line (float'image(1.0-(z/b)));
>       rr:=-a*sqrt((1.0-(z/b)**2))+a+r;
>    END LOOP;
> END el_stat_fun;
> ----------------------------------------------------------------------
------------------------------
>
>
>
>
> When compiled using GNAT 3.14 (WinNT sp 6) it raises
> ADA.NUMERICS.ARGUMENT_ERROR in sqrt function when k goes to 25 because
> the argument for sqrt becomes
> negative (like -X.XXXXXE-07 ... And this is a headache No 1).
> However, if one comments out the put_line string - everything works
> fine.
>

You need to look at the generated code. All the variables are local to
the procedure, so if you comment out the Put_Line then the compiler
might be generating no code at all for the procedure.

Alternatively try changing it so that the variable rr is external to the
procedure (and make it volatile as well).

Cheers,

Phil

--
Phil Thornley
Programmes, Engineering
Warton

Re: I think - it's a bug...

[Anatoly Chernyshev]

Thanks to everyone who tried to answer this post.
Eventually, I've found a solution that always put me on the safe side:

replace
FOR k IN 0..integer(b/dz) LOOP
with
FOR K IN 0..Integer(Float'Truncation(B/Dz)) LOOP

Anatoly Chernyshev wrote:

> Look at this piece of code:
>
> -------------------------------------------------------------------------------------------------
>
> WITH ada.text_io,ada.numerics.elementary_functions;
> USE ada.text_io, ada.numerics.elementary_functions;
> PROCEDURE el_stat_fun IS
>    b            : float := 7.5;
>    a:float:=4.0;
>    rr, z : float;
>    r            : float := 4.0;
>    dz           : float := 0.3;
> BEGIN
>    FOR k IN 0..integer(b/dz) LOOP
>       z:=float(k)*dz;
>       put_line (float'image(1.0-(z/b)));
>       rr:=-a*sqrt((1.0-(z/b)**2))+a+r;
>    END LOOP;
> END el_stat_fun;
> ----------------------------------------------------------------------------------------------------
>
> When compiled using GNAT 3.14 (WinNT sp 6) it raises
> ADA.NUMERICS.ARGUMENT_ERROR in sqrt function when k goes to 25 because
> the argument for sqrt becomes
> negative (like -X.XXXXXE-07 ... And this is a headache No 1).
> However, if one comments out the put_line string - everything works
> fine.
>
> I don't know whether this is a bug or feature, but any kind of help for
> how to avoid the situation when 1.0-1.0/1.0 yields  something different
> from 0.0 will be greatly appreciated.
>
> Thanks in advance,
>
> Anatoly.