Assignment of small Float values

Assignment of small Float values

[David W. Glessner]

Why does GNAT treat the non-zero constant as 0.0 in the assignment to
F1 in the following example?  32-bit IEEE floating-point should
support values down to around 10**-38 (and even down to 10**-45 or
so for subnormal numbers).

Note that Rational Apex Ada behaves as I expected.

Is there something in Ada that allows the assignment of 0.0 or is
this a GNAT bug?


-- Test program that shows unexplained (to me at least) GNAT behavior
for
-- floating point assignments.
--
-- GNAT 3.12p Win98 displays:
-- 0.00000E+00                           <-- Why does GNAT display 0.0?
-- 6.66666666666667E-33
-- 6.66667E-33
--
-- Rational Apex 3.0.0b for Solaris (Sparc) displays:
-- 6.66667E-33
-- 6.66666666666667E-33
-- 6.66667E-33
with Ada.Text_Io;
procedure Test_Float_Range is
    C : constant := 6.6666666666666666E-33;
    F1 : Float := C;
    F2 : Long_Float := C;
    F3 : Float := Float (F2);
    use Ada.Text_Io;
begin
    Put_Line (Float'Image (F1));
    Put_Line (Long_Float'Image (F2));
    Put_Line (Float'Image (F3));
end Test_Float_Range;


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

Re: Assignment of small Float values

[swhalen]

David W. Glessner <david_glessner@my-deja.com> wrote:
: Why does GNAT treat the non-zero constant as 0.0 in the assignment to
: F1 in the following example?  32-bit IEEE floating-point should
: support values down to around 10**-38 (and even down to 10**-45 or
: so for subnormal numbers).

: Note that Rational Apex Ada behaves as I expected.

: Is there something in Ada that allows the assignment of 0.0 or is
: this a GNAT bug?


: -- Test program that shows unexplained (to me at least) GNAT behavior
: for
: -- floating point assignments.
: --
: -- GNAT 3.12p Win98 displays:
: -- 0.00000E+00                           <-- Why does GNAT display 0.0?
: -- 6.66666666666667E-33
: -- 6.66667E-33
: --
: -- Rational Apex 3.0.0b for Solaris (Sparc) displays:
: -- 6.66667E-33
: -- 6.66666666666667E-33
: -- 6.66667E-33
: with Ada.Text_Io;
: procedure Test_Float_Range is
:     C : constant := 6.6666666666666666E-33;
:     F1 : Float := C;
:     F2 : Long_Float := C;
:     F3 : Float := Float (F2);
:     use Ada.Text_Io;
: begin
:     Put_Line (Float'Image (F1));
:     Put_Line (Long_Float'Image (F2));
:     Put_Line (Float'Image (F3));
: end Test_Float_Range;

I get the same results from ObjectAda 7.1 WinNT that you got from
Rational. I get the same results from GNAT 3.12p WinNT as you got with
GNAT Win98 (which eliminates a few variables).

I'm no floating point expert (I used one once, but didn't like it and
went right back to integers <g>), so I'm not a good one to answer your
question. Hopefully other's will chime in.

I did notice 

   type Short_Float     is digits 6
     range -16#0.FFFF_FF#E+32 .. 16#0.FFFF_FF#E+32;
     --    -3.40282E+38 ..  3.40282E+38

   type Float           is digits 6
     range -16#0.FFFF_FF#E+32 .. 16#0.FFFF_FF#E+32;
     --    -3.40282E+38 ..  3.40282E+38

   type Long_Float      is digits 15
     range -16#0.FFFF_FFFF_FFFF_F8#E+256 .. 16#0.FFFF_FFFF_FFFF_F8#E+256;
     --    -1.79769313486232E+308 ..  1.79769313486232E+308

   ...

in GNAT's "Standard" package definitions. I couldn't find the
equivalent in ObjectAda to see what they did.

Given Dr. Dewar's level of expertise in both math and Ada compilers,
I'd be surprised if GNAT's definitions are wrong, but given the
complexity of an Ada95 compiler, I wouldn't be shocked if there was a
bug.

I find it interesting that the 0.0 result comes back for anything
"more" than E-32 given the above definitions, but I read the RM to say
that float literals are supposed to be of the highest precision
supported by the implementation. But remember, I stay away from
heavy duty floating point stuff, because I _know_ I don't know
what I'm doing <g>...

Steve

-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}

Re: Assignment of small Float values

[Robert I. Eachus]

David W. Glessner <david_glessner@my-deja.com> wrote:
> Why does GNAT treat the non-zero constant as 0.0 in the assignment to
> F1 in the following example?  32-bit IEEE floating-point should
> support values down to around 10**-38 (and even down to 10**-45 or
> so for subnormal numbers).

    Jumping in where angels fear to tread--because it is so difficult to
explain the "correct" answer:

    First, the realistic answer:  It is probably a bug.

    Second, the language lawyerly answer:

        If you did not compile in strict mode, you cannot reason about
the arithmetical model at all.  If this problem occurs in strict mode,
and if the exponent is greater than S'Model_Emin (not T'Machine_Emin),
then the compiler fails to comply with the standard.  If there are in
fact no model numbers between 6.6666666666666666E-33 and 0.0, then the
implementation is valid.  (The trickiness here is that for some floating
point representations without gradual underflow, there is a significant
gap in the model numbers on either side of zero.  In other words, the
gap between the model number just above zero and zero is much greater
than the gap between that model number and the model number next above
it.)

Disturbing float conversions...

[jboulais]

I'm seeing something similar, but perhaps a little more disturbing
(Gnat 3.11p and WinNT 4.0).

I've got the following types defined:

   type Long_Float_Type is digits 8 range -32768.000 .. 32767.000 ;

   subtype Angle_Type is Long_Float_Type range -180.00000 .. 179.99451 ;

I find that when I do a 'Image on the 'First and 'Last of Angle_Type, I
get -1.7999872E+02 and 1.7999872E+02 respectively.

If I convert to a long_float (Ada standard, not Long_Float_Type) I get
-1.80000000000000E+02 and 1.79994510000127E+02 respectively, which is
closer, but the 'Last is a little bigger than I defined it to.

If I instantiate Text_IO.Float_IO with Angle_Type, I get -204.7 and
204.7, which really blows me away.



In article <8dfm0q$8nr$1@nnrp1.deja.com>,
  David W. Glessner <david_glessner@my-deja.com> wrote:
> Why does GNAT treat the non-zero constant as 0.0 in the assignment to
> F1 in the following example?  32-bit IEEE floating-point should
> support values down to around 10**-38 (and even down to 10**-45 or
> so for subnormal numbers).
>
> Note that Rational Apex Ada behaves as I expected.
>
> Is there something in Ada that allows the assignment of 0.0 or is
> this a GNAT bug?
>
> -- Test program that shows unexplained (to me at least) GNAT behavior
> for
> -- floating point assignments.
> --
> -- GNAT 3.12p Win98 displays:
> -- 0.00000E+00                           <-- Why does GNAT display
0.0?
> -- 6.66666666666667E-33
> -- 6.66667E-33
> --
> -- Rational Apex 3.0.0b for Solaris (Sparc) displays:
> -- 6.66667E-33
> -- 6.66666666666667E-33
> -- 6.66667E-33
> with Ada.Text_Io;
> procedure Test_Float_Range is
>     C : constant := 6.6666666666666666E-33;
>     F1 : Float := C;
>     F2 : Long_Float := C;
>     F3 : Float := Float (F2);
>     use Ada.Text_Io;
> begin
>     Put_Line (Float'Image (F1));
>     Put_Line (Long_Float'Image (F2));
>     Put_Line (Float'Image (F3));
> end Test_Float_Range;
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>

--
-----------------
Jeffrey Boulais


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

Re: Disturbing float conversions...

[JP Thornley]

In article <8en7ij$kr7$1@nnrp1.deja.com>, jboulais@my-deja.com writes
>I'm seeing something similar, but perhaps a little more disturbing
>(Gnat 3.11p and WinNT 4.0).

With Gnat 3.11p and Win98SE on a PIII the answers look a lot more like
you would expect:

>
>I've got the following types defined:
>
>   type Long_Float_Type is digits 8 range -32768.000 .. 32767.000 ;
>
>   subtype Angle_Type is Long_Float_Type range -180.00000 .. 179.99451 ;
>
>I find that when I do a 'Image on the 'First and 'Last of Angle_Type, I
>get -1.7999872E+02 and 1.7999872E+02 respectively.

I get:
-1.8000000E+02
 1.7999451E+02

>If I convert to a long_float (Ada standard, not Long_Float_Type) I get
>-1.80000000000000E+02 and 1.79994510000127E+02 respectively, which is
>closer, but the 'Last is a little bigger than I defined it to.

I get:
-1.80000000000000E+02
 1.79994510000000E+02

But, of course, 179.99451 cannot be represented *exactly* in any binary
floating point value (the fractional part doesn't end in a decimal '5').

>If I instantiate Text_IO.Float_IO with Angle_Type, I get -204.7 and
>204.7, which really blows me away.
now that is bizarre, I get:
-1.8000000E+02
 1.7999451E+02

Phil Thornley

My code is:

with Ada.Text_IO;
procedure Float_Values is

   type Long_Float_Type is digits 8 range -32768.000 .. 32767.000 ;

   subtype Angle_Type is Long_Float_Type range -180.00000 .. 179.99451 ;
   
   package AT_IO is new Ada.Text_IO.Float_IO(Angle_Type);
   
begin
   Ada.Text_IO.Put_Line(Long_Float_Type'Image(Angle_Type'First));
   Ada.Text_IO.Put_Line(Long_Float_Type'Image(Angle_Type'Last));

   Ada.Text_IO.Put_Line(Long_Float'Image(Long_Float(Angle_Type'First)));
   Ada.Text_IO.Put_Line(Long_Float'Image(Long_Float(Angle_Type'Last)));
   
   AT_IO.Put(Angle_Type'First);
   Ada.Text_IO.New_Line;
   AT_IO.Put(Angle_Type'Last);
   Ada.Text_IO.New_Line;
   
end Float_Values;
-- 
JP Thornley

Re: Disturbing float conversions...

[jboulais]

Hmmm... I tried your source and got the same results...

The only other thing that's different is the heiarchy.  My
Long_Float_Type and Angle Type are defined in the spec DGS.ads.  The
print routines are in MFD_Pkg-Properties, a child of MFD_Pkg.adb.  DGS
is withed into MFD_Pkg.ads.  I wonder if that could possibly be having
any effect?

-----------------
Jeffrey Boulais


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

Re: Disturbing float conversions...

[JP Thornley]

In article <8ff2cg$ns5$1@nnrp1.deja.com>, jboulais@my-deja.com writes
>Hmmm... I tried your source and got the same results...
>
>The only other thing that's different is the heiarchy.  My
>Long_Float_Type and Angle Type are defined in the spec DGS.ads.  The
>print routines are in MFD_Pkg-Properties, a child of MFD_Pkg.adb.  DGS
>is withed into MFD_Pkg.ads.  I wonder if that could possibly be having
>any effect?

I built the hierarchy you describe, but this doesn't change my output.

If you mail me the actual code you started with then I can try that (the
reply address is valid).

Cheers,

Phil Thornley

-- 
JP Thornley