× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I just want to add that in all fairness to IBM this is not really an RPG or 
AS/400
issue, but an issue with how floating point values are stored in computers.  You
could expect similar types of results in other langauges and platforms using 
floating
point.

I think that Barbara's solution is actually the best of the lot, convert any 
floating
point numbers that crop up immediatly to a decimal value before using it 
further in
calculations for dollars.  %dech(floating value : length : decimals)

I don't think that resdespos actually has anything to do with floating point 
values.

Another alternative you might want to look at is replacing your formula of (10 
** #Expo)
with something that returns a decimal value.  Perhaps create a %Pow function 
that returns
a decimal that you could stick in your library (er, directory?) of calls.  You 
could do all
that weird math stuff in there to get an accurate decimal result, then use:

Eval      #Result = #Base + (1 / %Pow(10, #Expo)) and not have to worry about
the floating point value messing up your formula.

Regards,

Jim Langston

bmorris@ca.ibm.com wrote:

> >Date: Mon, 7 Aug 2000 13:31:23 -0400
> >From: Contractor1@Parkdalemills.com
> > ...
> >D#ExPo         S              1P 0   Inz(0)
> >D#Base         S              4P 2   Inz(18.10)
> >D#Result       S              5P 2
> >
> >The Eval statement:
> >Eval      #Result = #Base + (1 / (10 ** #Expo))
> >
> >     Expected answer:    19.10
> >     Actual answer:      19.09
> > ...
>
> Patrick,
>
> Others have already suggested that you use (R) and (H), both
> good suggestions, especially when division and floating point
> are being used in an expression.  But even when resdecpos and
> half-adjust are both active, using floating point can introduce
> errors into your program.  This is because floating point uses
> a binary representation and some decimal values can't be expressed
> exactly as binary numbers.
>
> To limit the effects of the floating point to just the
> exponentiation, try this, getting the result of (10 ** #Expo)
> in a decimal(x,y) value (for x and y, use whatever you used
> as the length and decimals for your #CalcExpo temporary):
>
>   #Base + (1 / %dech(10 ** #Expo : x : y))
>
> I can't tell if this will always give the correct answer, but
> it will give the same results as your 2-operation method using the
> #CalcExpo temporary.
>
> (To avoid floating point completely, you could do the exponentiation
> in a loop, or you could handle it with a character overlay of a zoned
> value, shifting the data #Expo places left or right.)
>
> Barbara Morris

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.