Float/Short Float Conversion 
Author Message
 Float/Short Float Conversion

G'day,
We are currently using a Verdix sun4 -> MC68020/MC68881 compiler
in conjunction with VxWorks the compiler version is Version 6.0.

Or in more (Verdix sourced) detail, we are using

    Verdix Ada Compiler, Copyright 1984, 1992
    VADSworks for Sun-4 -> MC68020/30/vxWorks, (VADS 6.0.5)
    Mon Aug 17 09:11:00 EST 1992 2.0.3(b)

We are having fun with the following statement:

     XXX := FLOAT(SHORT_FLOAT_VALUE);

   where XXX is a variable of type FLOAT and SHORT_FLOAT_VALUE is of
type SHORT_FLOAT and would appear to have the value 0.0. That is,

    OUR_SCREEN_IO_PACKAGE.FLOAT_PUT_LINE(FLOAT(SHORT_FLOAT_VALUE));

   prints out the value zero to our debugging screen.

In the odd occaision, say one out of eight executions we get
the NUMERIC_ERROR exception raised.

Any ideas?
TIA.

BTW The target environment is such that we are unable to use the de{*filter*}
so unfortunately that possibillity is out. We have also tried playing with
various levels of optimization.

  Bob Wells                  "C makes it easy for you to shoot yourself in
                              the foot. C++ makes that harder, but when you
                              do, it blows away your whole leg."



Mon, 20 May 1996 00:24:22 GMT  
 Float/Short Float Conversion

: We are having fun with the following statement:

:      XXX := FLOAT(SHORT_FLOAT_VALUE);
I assume the numeric_error occurs here ...
:    where XXX is a variable of type FLOAT and SHORT_FLOAT_VALUE is of
: type SHORT_FLOAT and would appear to have the value 0.0. That is,
:     OUR_SCREEN_IO_PACKAGE.FLOAT_PUT_LINE(FLOAT(SHORT_FLOAT_VALUE));
and does'nt occur here.
:    prints out the value zero to our debugging screen.

: In the odd occaision, say one out of eight executions we get
: the NUMERIC_ERROR exception raised.

My first guess is: This is real strange behaviour, so it might be a
compiler-error. (It looks like one.)
Perhaps (possible, isn't it?) the value 0.0 can be signed in short_float, but
not in float. Then, when converting a value -0.0 to float, out comes a value
-0.0 in float, which is checked and found impossible.

My second guess is: This behaviour is still strange, so it might be some
really peculiar thing.
Perhaps (possible, isn't it?) short_float provides greater accuracy than
float, and, converting some very small value to float, gives 0.0 (or nearly
0.0), which is output. But sometimes, when the value is slightly
different, converting to float is not possible, because float is not
sufficiently accurate. (This would mean that float has a bigger exponent
than short_float has, but has smaller mantissa, which would indeed be
strange.)

My third guess is: This behaviour is still strange, so it might be a thing
to be answered by someone else. (i.e.: I don't know)

Just some wild guesses, but one could be right by chance.

Another guess: Could You instantiate text_io.float_io with short_float to
look wether that value is really 0.0? (Could especially be useful with guess
No. 2)

Have fun!
--
  Merry      !        (,)      Advent, Advent, ein
    .  Xmas! !       **U**       Lichtlein brennt,
  ./.\.      !   , **     ** ,    ich hab' die     \\\\\\\
 .//.\\.     !   U**       **U    Vorlesung   ____-- \\\|||
.///.\\\.    !     **  ,  **    verpennt.    (_____   ,) ==



Tue, 21 May 1996 02:05:33 GMT  
 Float/Short Float Conversion
I only gave some guesses in my last posting, but forgot about the fixes.
Sorry for that.
Please try the following:

               XXX := float ( short_float_value + 0.0 ) + 0.0;

It's possibly a fix for any of my three guesses. (It actually fixed another
problem on another compiler for which I don't know the reason, either.)

You might as well try to omit one of the "+0.0"'s.
Also, You might use "*1.0", but that would be a floating-point-multiplication,
   and therefore is less efficient.

I hope it's o.k. that I didn't compile this before posting... ?:-)
--
no .sig this time. If You want to insist on it, e-mail me to get a free copy.



Tue, 21 May 1996 20:11:38 GMT  
 Float/Short Float Conversion

  > We are having fun with the following statement:

  >  XXX := FLOAT(SHORT_FLOAT_VALUE);

  >    where XXX is a variable of type FLOAT and SHORT_FLOAT_VALUE is of
  > type SHORT_FLOAT and would appear to have the value 0.0. That is,

  >     OUR_SCREEN_IO_PACKAGE.FLOAT_PUT_LINE(FLOAT(SHORT_FLOAT_VALUE));

  >   prints out the value zero to our debugging screen.

  > In the odd occaision, say one out of eight executions we get
  > the NUMERIC_ERROR exception raised.

  > Any ideas?

    I think that Verdix uses a {*filter*} (but frequently legal) cheat when
converting Short_Float to Float on some hardware.  They do't do
anything.  (Thereby extending the value with random looking bits.)  If
this results in choosing some other value in the model interval of the
result that's legal, but not nice.  When the value being converted is
the result of a computation, you often get "extra" significant
bits--nice in some circumstances.  If the conversion results in
replacing a value known to be a model number of of the the short with
a non-model number of the larger type, that is probably not
legitimate.

    In any case I ran into this trying to print the actual values of
floating point values with more places that the default for the type.
In your case, you may be converting a zero to a denormalized value
(within a model interval bounded by zero).  Attempting to normalize
that value can raise NUMERIC_ERROR.

--

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...



Sun, 26 May 1996 01:09:07 GMT  
 Float/Short Float Conversion
G'day,

Thanks for the replies concerning our problem with the type
conversion from SHORT_FLOAT to FLOAT. We have now found some
even more interesting and bizarre behaviour with this type.

NUMERIC_ERROR exceptions are **sometimes** raised at the point
of declaration of the FLOAT variable. After this has occurred
once we have no further problems with the variable! We have put
in a temporary cludge of the type:

   declare

      DUMMY : FLOAT;

   begin

      null;

   exception
      when NUMERIC_ERROR =>
         null;

   end;

which allows us to start the system at least. It would appear
that the 68881 is not being correctly initialized by the Verdix
RTS. They are getting back to us with a solution so I'll let
you know what happens.

Change of Channel

Why are labels on case statements not allowed? For large and/or
nested case statements it would be good to be able to write

   CHECK_INCOMING_VALUE:
   case TEST_VARIABLE is
      when FIRST =>

         CHECK_CURRENT_STATE:
         case STATE is
            when IDLE =>

              ..........

         end case CHECK_CURRENT_STATE;

      when SECOND =>

          .......

   end case CHECK_INCOMING_VALUE;

in the same manner as declare blocks or loops. What was
the rationale behind disallowing this possibility? Thanks.




Wed, 29 May 1996 21:23:27 GMT  
 Float/Short Float Conversion

Quote:
>Change of Channel
>Why are labels on case statements not allowed? For large and/or
>nested case statements it would be good to be able to write
>   CHECK_INCOMING_VALUE:
>   case TEST_VARIABLE is
>      when FIRST =>
>         CHECK_CURRENT_STATE:
>         case STATE is
>            when IDLE =>
>              ..........
>         end case CHECK_CURRENT_STATE;
>      when SECOND =>
>          .......
>   end case CHECK_INCOMING_VALUE;
>in the same manner as declare blocks or loops. What was
>the rationale behind disallowing this possibility? Thanks.

Most likely because no-one thought of it.  Besides what functionality does it
provide over:

-- Check imcoming value
case TSET_VARIABLE is
    when FIRST =>
        -- Check current state
        case STATE is
            when IDLE =>
              ...........
        end case; -- Check current state
    when SECOND =>
        ..................
end case; -- Check incoming value

--
Mark Biggar



Thu, 30 May 1996 05:11:47 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Writing short-floats to binary stream?

2. An alternative to floating point (was Re: Floating point non-exactness)

3. MSBIN float format <-> IEEE float format

4. VAX float to IEEE float converter

5. Getting a floating point number from a float-object

6. vax floating pont to unix floating point

7. IBM 370 Floating point to IEEE floating point

8. Order of float and float precision contaigon defined?

9. Coercing single-float to double-float

10. need floating point conversion method

11. Floating point data conversion

12. floating point conversion

 

 
Powered by phpBB® Forum Software