Re: Rational/Verdix Number Bug

Re: Rational/Verdix Number Bug

[Alan D Zimmerman]

In article <3i0nip$b55@rational.rational.com>, kdm@rational.com (Kent Mitchell) writes:
> Roger C Hennesen (rch@odo.amherst.com) wrote:
> : We have discovered that the number 2147.483648 is not handled properly by the
> : Sun/Rational/Verdix Ada compiler. Multiplying or dividing by this number
> : results in a sign inversion in the result.
> 
> : The position of the decimal point does not matter. The number is 2^31. Also
> : numbers around this number (e.g. +/- 0.000003) exhibit strange results in 
> : floating point calculations.
> 
> : The problem was discovered in SunAda version 2.1.1 and duplicated with the SCO
> : Verdix Compiler version 6.2.1.
> 
> : Rational was notified of the problem, but has not responded.
> 
> O.K. I'll respond here since I'm concerned about both the bug *and* the
> statement that we didn't respond.
> First WRT the "no response" issue, hHow did you report the bug (phone,
> e-mail, or?).  Did you get *no* response (not even a customer support "log"
> number or automated e-mail response) or ???.
> 
> Second WRT the bug, do you have a minimum faulty program which reproduces
> the problem?  If so mail it to me so I can take a look at is and reproduce
> the problem internally.  I'll see if I can't grease the skids a bit.
> 
> --
> Kent Mitchell                   | One possible reason that things aren't
> Technical Consultant            | going according to plan is .....
> Rational Software Corporation   | that there never *was* a plan!

Well, I am in a perplexing situation.  I tried this when I first heard
about the problem and duplicated it with a program like the one attached.
I just tried it and  I could not duplicate it.  I am running SunAda 1.1(j)
on a SPARC LX.  Below is the test program.

with text_io;
procedure test_float is
  test : float := 2147.486348;
  package flt_io is new text_io.float_io(float);
begin
  flt_io.put(test);
  text_io.new_line;
  flt_io.put(test * 2.0);
  text_io.new_line;
  flt_io.put(test / 2.0);
end test_float;

Here are my results:

2.14748634800000E+03
 4.29497269600000E+03
 1.07374317400000E+03

Alan

-- 
|        Alan D. Zimmerman        | Eagle Scout                     |
|   azimmer@rsa.hisd.harris.com   | Scoutmaster T324                |
|-------------------------------------------------------------------|
|     All opinions are solely my own and do not represent Loral     |
|                   On My Honor I will do my best...                |

Re: Rational/Verdix Number Bug

[Mats Weber]

In article <3il66m$ps1@jabba.ess.harris.com>, azimmer@rsa.hisd.harris.com wrote:

> Well, I am in a perplexing situation.  I tried this when I first heard
> about the problem and duplicated it with a program like the one attached.
> I just tried it and  I could not duplicate it.  I am running SunAda 1.1(j)
> on a SPARC LX.  Below is the test program.
> 
> with text_io;
> procedure test_float is
>   test : float := 2147.486348;
>   package flt_io is new text_io.float_io(float);
> begin
>   flt_io.put(test);
>   text_io.new_line;
>   flt_io.put(test * 2.0);
>   text_io.new_line;
>   flt_io.put(test / 2.0);
> end test_float;

Here, except in the implicit converion of the literal 2147.486348 from
universal_real to float, you only use floating point arithmetic (the basic
operations of the predefined type float), not the compiler's internal
infinite precision arithmetic, which is where the bug is from my
understanding of the problem.

You should try this instead:

 with text_io;
 procedure test_float is
   test : constant := 2147.486348;
   double_test : constant := 2.0 * test;
   half_test : constant := test / 2.0;
   package flt_io is new text_io.float_io(float);
 begin
   flt_io.put(test);         -- implicit conversion universal_real -> float
   text_io.new_line;
   flt_io.put(double_test);  -- idem
   text_io.new_line;
   flt_io.put(half_test);    -- idem
 end test_float;

Re: Rational/Verdix Number Bug

[Kent Mitchell]

Mats Weber (Mats.Weber@matrix.ch) wrote:
: You should try this instead:

:  with text_io;
:  procedure test_float is
:    test : constant := 2147.486348;
:    double_test : constant := 2.0 * test;
:    half_test : constant := test / 2.0;
:    package flt_io is new text_io.float_io(float);
:  begin
:    flt_io.put(test);         -- implicit conversion universal_real -> float
:    text_io.new_line;
:    flt_io.put(double_test);  -- idem
:    text_io.new_line;
:    flt_io.put(half_test);    -- idem
:  end test_float;

To whoever posted this orignally (and my news has deleted the old
articles):

I've been trying to reproduce this problem but I've not yet been successful.
Can you tell me which platform, compiler target, compiler version this
problem can be reproduced on.  I can't seem to get it to happen for me 
on the 6.2 version of VADS on solaris.  Also, do you have a support log
number for this defect so I can look at the log.

--
Kent Mitchell                   | One possible reason that things aren't
Technical Consultant            | going according to plan is .....
Rational Software Corporation   | that there never *was* a plan!

Re: Rational/Verdix Number Bug

[Alan D Zimmerman]

In article <Mats.Weber-2702951928090001@mlma11.matrix.ch>, Mats.Weber@matrix.ch (Mats Weber) writes:
> In article <3il66m$ps1@jabba.ess.harris.com>, azimmer@rsa.hisd.harris.com wrote:
> 
> > Well, I am in a perplexing situation.  I tried this when I first heard
> > about the problem and duplicated it with a program like the one attached.
> > I just tried it and  I could not duplicate it.  I am running SunAda 1.1(j)
> > on a SPARC LX.  Below is the test program.
> > 
> > with text_io;
> > procedure test_float is
> >   test : float := 2147.486348;
> >   package flt_io is new text_io.float_io(float);
> > begin
> >   flt_io.put(test);
> >   text_io.new_line;
> >   flt_io.put(test * 2.0);
> >   text_io.new_line;
> >   flt_io.put(test / 2.0);
> > end test_float;
> 
> Here, except in the implicit converion of the literal 2147.486348 from
> universal_real to float, you only use floating point arithmetic (the basic
> operations of the predefined type float), not the compiler's internal
> infinite precision arithmetic, which is where the bug is from my
> understanding of the problem.
No, actually the problem is that I reversed the 3 and the six.  With the 
following program, I get the proper (incorrect) results:

Program:

with text_io;
procedure test_float is
  test : float := 2147.483648;
  package flt_io is new text_io.float_io(float);
begin
  flt_io.put(test);
  text_io.new_line;
  flt_io.put(test * 2.0);
  text_io.new_line;
  flt_io.put(test / 2.0);
end test_float;

Results:

-2.14748364800000E+03
-4.29496729600000E+03
-1.07374182400000E+03

For what it is worth, I have been told that rational knows about this
and that a patch is available.  Thanks to Richard Hash of Team-Ada
who pointed out my problem.

Alan
-- 
|        Alan D. Zimmerman        | Eagle Scout                     |
|   azimmer@rsa.hisd.harris.com   | Scoutmaster T324                |
|-------------------------------------------------------------------|
|     All opinions are solely my own and do not represent Loral     |
|                   On My Honor I will do my best...                |