Re: [Re: RPGILE V4.3 Gotcha]

The 8 byte IEEE floating point datatype is if I remember correctly precise
to the 17th position. That is generally much more precision than is needed
in a business environment. If you are computing averages or extending costs
etc... All I can say is that either you specify the precision that you need
for intermediate results or you use floating point. I still maintain that
accountants rely on the same IEEE floating point data type as we now have
recourse to ( You can get the limitations of the IEEE floating point numbers
from their specification, which lists cases where the result is divergent
from what a person would get if they did the math long hand).

Again if you wish to be lazy you can use floating point variables for those
type calculations or if you are willing to put forth more effort you can use
fixed precision (Packed or Zoned decimals) and make sure that your
intermediate fields are large enough to accomidate the results of a division
or multiplication.

Eric

______________________________________________
Eric N. Wilson
President
Doulos Software & Computer Services
2913 N Alder St
Tacoma WA 98407


----- Original Message -----
From: Ray Peterson <rpeterso@witc.tec.wi.us>
To: <RPG400-L@midrange.com>
Sent: Tuesday, October 05, 1999 8:50 PM
Subject: 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
> +---

+---
| 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
+---