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

[Anatoly Chernyshev <rhezusfactor@yahoo.com>]

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

>