HP3000-L Archives

July 1995, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stan Sieler <[log in to unmask]>
Reply To:
Stan Sieler <[log in to unmask]>
Date:
Thu, 6 Jul 1995 11:37:36 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (31 lines)
Chris asks:
 
> The question is: is this routine capable (if it's at all possible) to recognize
> the current format of the float to convert. In other words, what happens when
> we convert from native to IEEE, and the source is ALREADY in IEEE format ?
 
That never happens.  By definition, the data you give it to convert from
Classic format to IEEE format is in Classic format.  If you *thought* the
data was in IEEE format, then you wouldn't have passed it to the routine, eh?
 
> My guess is that HPFPCONVERT would screw up, but perhaps it does a check and sees
 
Nope.  It would work perfectly well, converting the Classic format number
you passed it into IEEE format.  The results wouldn't be worthwhile, of
course, but that isn't a "screw up" on the part of the *intrinsic*...
it did what it was told:
 
   1) assume the input is Classic format;
   2) convert it to IEEE format.
 
There's no way for it, or you, or me, to look at a pile of 32 bits and
say "aha, that's IEEE".
 
Have you considered storing your data in the Image database in IEEE
format, using the relatively new E data type?
(E is an IEEE real)
 
--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html

ATOM RSS1 RSS2