Re: Converting from scientific to integer/decimal

["M. Lazarus" <mlazarus@xxxxxxxx>]

Barbara,

 I actually had decided on using %DecH().  The business application is 
data originally coming from an Excel spreadsheet.  I wanted to make a 
generic routine (*Module in a *SRVPGM) out of this conversion.   Since I 
don't know ahead of time what the length being passed might be, I was 
hoping that %Dec and %DecH might allow a runtime value to be used as the 
length (2nd parm in the BIF), but unfortunately, that value must be 
available at compile time.

 I'm at v5r2.  Has this changed in v5r3.  If not, are there any plans to 
allow it?

 -mark


At 10/20/04 04:52 PM, you wrote:
> "M. Lazarus" wrote:
> >
> > Bob,
> >
> >   I'm not at the /400 right now, but would this work (assuming atof was
> > prototyped properly)?
> >
> >   IntValue = AtoF( '123456E+4' )
> >
>
> It would be safer to use
>
>    eval(h) IntValue = AtoF(string)
>
> As a rule of thumb, always use (H) when assigning from float to
> non-float.
>
> The mantissa parts of the float values for 123456, 1.23456, .000123456,
> 1234560000 etc. are all the same, either 1.23456, or maybe .123456, I
> forget which.  Either way, there are values after the decimal point even
> though the actual number may have no decimal places.  Not all decimal
> fractions can be stored exactly in floating point, because floating
> point is stored in binary format.
>
> It's possible for a number like say 12345 to be stored as
> .1234499999999e5.  If you use EVAL to assign this to an integer value,
> you would get 12344.  Using EVAL(H) would give you 12345.  (12345 is
> just a made up example - I wish I had a real example to show that using
> EVAL without half-adjust might not give the right result sometimes.)