Re: [Re: RPGILE V4.3 Gotcha]

["Eric N. Wilson" <doulos1@xxxxxxxx>]

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