Re: [Re: RPGILE V4.3 Gotcha]

Well, I can't sit on the sidelines any longer.  It seems that IBM has introduced
this new (to the AS/400) data type called "floating point" which appears to be
mis-understood by many in the AS/400 programming community.  Floating
Point (FP) should never be used in calculations where precise answers are
needed.  To quote from the ILE RPG for AS/400 Reference:

... "Since float variables are intended to represent "scientific" values, a
numeric value stored in a float variable may not represent the exact
same value as it would in a packed variable. Float should not be used
when you need to represent numbers exactly to a specific number of
decimal places, such as monetary amounts."

I'm trying to come up with a good example where FP would be appropriate
in our environment, and I'm not seeing any.  Perhaps someone else has
an example they would share!

In general however, FP allows one to manipulate widely disparate numerical
values.  For example, one could multiply two numbers, one with say 300
digits to the left of the decimal point (although most must be zeros!) by
another with say 250 zeros to the right of the decimal point and then
some numbers.  This is a very common occurance in the scientific community.
Indeed, NASA uses these types of calculations to determine the precise
spot on the moon where our astronaughts will land, but could never account
for exactly how many dollars and cents it cost to get there.

Now, the ultimate question for the IBMers, why did IBM add FP to RPG?
What uses did you forsee?

Ray

"Eric N. Wilson" wrote:

> Again you would be better served by using floating point numbers in this
> situation (That is why your calculator is floating point) at the end you can
> resolve it to a fixed point number by a simple rounding operation.
>
> ______________________________________________
> Eric N. Wilson
> President
> Doulos Software & Computer Services
> 2913 N Alder St
> Tacoma WA 98407
>
> ----- Original Message -----
> From: Jim Langston <jlangston@conexfreight.com>
> To: <RPG400-L@midrange.com>
> Sent: Tuesday, October 05, 1999 2:12 PM
> Subject: Re: [Re: RPGILE V4.3 Gotcha]
>
> > Okay, here is something I would probably use it for.
> >
> > I sum up all the sales for a given period, since this can be in the 10's
> of
> > millions, I'm going to want to use at least 10 digits, right?  We had a
> > report in RPG II giving wrong results, and I found that it was it was only
> > using 9 digits, and was loosing 2 places, so I bumped it up to 13 in
> > my program.  Okay, so I add up all my sales into a variable, and it is
> > 13, 2.  Then I add up all my payables for the same period, and stick them
> > in a 13, 2 field.  The fields are the right size for the numbers they
> contain,
> > and are rather large.  Now, to get a percentage, we divide the amount
> > of payables over the amount of sales, but we want this as a percentage,
> > so we want to multiply it by 100.  Something like:
> > EVAL Percent = (AmountPayable / AmountSales) * 100
> >
> > In here, we are lucky, we only have 29 total digits.  But, what about the
> fact
> > that Percent was based on 4, 2?  (12.35%)  Or what about next year when
> > it overflows again on me, so I kick them up to 15, 2?
> >
> > Are these not real world scenarios?  I am, in fact, writing this program
> now.
> > And why should I have to use floating point numbers to keep dollars and
> cents?
> >
> > The fact is, I'm going to use DIV and MULT just so I don't have to worry
> about
> > it.
> >
> >
> > Ken Sims at SWS Nevada wrote:
> >
> > > <SNIP>
> > > I knew about it, and I don't consider it particularly a problem.
> > > As long as the intermediate result doesn't exceed 30 digits, there
> > > isn't a problem.  Where the order of operations is flexible, I have
> > > always coded to keep the intermediate result as small as possible.
> > >
> > > If your numbers are big enough in themselves to cause problems in
> > > the intermediate results, then perhaps you need to be using
> > > floating point numbers.  If the numbers aren't that big, but the
> > > fields are, then it sounds like a poor design by somebody.
> > >
> > > Ken
> > > Southern Wine & Spirits of Nevada, Inc.
> > >
> > > +---
> > > | This is the RPG/400 Mailing List!
> > > | To submit a new message, send your mail to RPG400-L@midrange.com.
> > > | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> > > | To unsubscribe from this list send email to
> RPG400-L-UNSUB@midrange.com.
> > > | Questions should be directed to the list owner/operator:
> david@midrange.com
> > > +---
> >
> > +---
> > | This is the RPG/400 Mailing List!
> > | To submit a new message, send your mail to RPG400-L@midrange.com.
> > | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> > | Questions should be directed to the list owner/operator:
> david@midrange.com
> > +---
>
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---