× 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.




On Friday, February 20, 2004, at 05:40 AM, Joe Pluta wrote:


And thus from a backwards compatibility standpoint, it's pretty clear
that changing exponentiation to use a floating point value (if that's
indeed what happened) actually reduced precision. This should have at
least been enough to warrant a warning somewhere in the release notes
(and there may well have been, I haven't read the release notes for V5R2
yet).


Think about it: if indeed exponentiation was changed, and somebody is
currently using exponentiation in a production program, that program is
now possibly giving erroneous results.  That is something IBM has been
extremely good about in the past, and is something I'd hope they'd
continue to adhere to: "Break no code (and if you do, let the users no
in REALLY BIG letters)."


The ** operator has used floating-point since its inception. I did not look further back than 440 but in the RPG Reference for 440 section 4.2.5.2.3 contains the same information Buck quoted from the 520 RPG Reference. It doesn't have a change flag so I presume it was documented the same way in earlier releases.


The only 'error' was choosing to use floating-point when both operands were decimal. Especially when the decimal values have more than 16 digits on either side of the decimal point. This results in a conversion to float (possibly losing accuracy), the operation (possibly losing accuracy), and conversion back to decimal (possibly losing accuracy).

Anyone who uses floating point should know that it is an approximation and is only accurate to nearly 16 digits. I understand 16 digits of precision exceeds the experimental accuracy of all known constants of nature but that doesn't help in the business world. The approximation is why you should never check floating-point numbers for equality (i.e., IF float1 = float2 is a bad idea).

The fact that the behaviour has changed between releases is a means for opening a PMR with IBM to get a formal response. Given the results it looks to me like a rounding issue during conversion to decimal. Whether that is a defect or a correction of previously erroneous behaviour is for IBM to say. But even allowing for the inaccuracy of floating-point the fact the releases 440 to 510 give result of 1152921504606846976 and 520 gives 1152921504606846980 suggests a change in rounding during conversion to decimal. Peter Colpaert's experiments showing the ..76 answer for 20i 0 variables lends weight to that theory.

I see that Rob opened a PMR and got told that this is expected with floating point. I would point out the previous release behaviour and the behaviour with 20-digit integers and have them look at it again.

Has anyone tried the example on 520 in a language other than RPG IV to see if the behaviour is with RPG or the machine?

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------



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.