Re: [U2] The math just doesn't work.
Hi Bill, I think you would need to set Wide Zero to something like the UV default (2.91 * 10^-11) to do a comparative test. Thanks for checking anyway. Brett "Bill Haskett" wrote in message news:<4e933047.6050...@advantos.net>... > Brett: > > When I run the following code on UD v7.2.7, it works fine. > > * > ** Test program > EXECUTE \SET.WIDEZERO 0.01\ > * > NUL = '' > CM = ',' > A = -409071.8775: CM: 475000: CM: -652413: CM: 652413: CM: -475000: CM: > 409071.8775 > * > TEST.VMC = 1 > TEST.TOTAL = 0 > * > LOOP UNTIL FIELD(A, CM, TEST.VMC) = NUL DO > TEST.TOTAL += FIELD(A, CM, TEST.VMC) > TEST.VMC += 1 > REPEAT > * > IF TEST.TOTAL = 0 THEN > PRINT 'OK' > END ELSE > PRINT TEST.TOTAL, (TEST.TOTAL = 0), TEST.TOTAL - 0, > (OCONV(TEST.TOTAL, 'MD0') = 0) > END > > *2 Dev (0)-> RUN BP BILL > OK* > > HTH, > > Bill > > ------------ > - Original Message - > *From:* bre...@gpmdev.co.uk > *To:* u2-users@listserver.u2ug.org > *Date:* 10/10/2011 1:16 AM > *Subject:* Re: [U2] The math just doesn't work. > > I also thought: "great explanation" and nodded sagely when I read this. > > However, consider this code: > > > > > > > >NUL = '' > > > >CM = ',' > > > >A = -409071.8775: CM: 475000: CM: -652413: CM: 652413: CM: -475000: > > CM: 409071.8775 > > > > * > > > > * > > > >TEST.VMC = 1 > > > >TEST.TOTAL = 0 > > > > * > > > >LOOP UNTIL FIELD(A, CM, TEST.VMC) = NUL DO > > > > TEST.TOTAL += FIELD(A, CM, TEST.VMC) > > > > TEST.VMC += 1 > > > >REPEAT > > > > * > > > >IF TEST.TOTAL = 0 THEN > > > > PRINT 'OK' > > > >END ELSE > > > > PRINT TEST.TOTAL, (TEST.TOTAL = 0), TEST.TOTAL - 0, > > (OCONV(TEST.TOTAL, 'MD0') = 0) > > > >END > > > > > > > > > > > > Running this on our Universe system 11.1.1 produces: > > > > > > > > 0 0 0 1 > > > > > > > > So, in other words zero is the total result in TEST.TOTAL but this does not > > equate to zero. > > > > > > > > Now I know I can get round this by rounding the answer but am not sure why > > I should have to. Any ideas? > > > > > > > > Thanks > > > > > > > > Brett > > > > > > > > "Martin > > Phillips"mailto:martinphill...@ladybridge.com>> > > wrote in message > > news:<2636297EDC484501AD1A5AC277EE76A7@lbs8<news:%3c2636297EDC484501AD1A5AC277EE76A7@lbs8>>... > > > >> Hi George, > >> As a general rule in programming, comparison of floating point values > >> for equality should be avoided. This is because, just as we cannot > >> write the number one third accurately in decimal notation, so the IEEE > >> floating point format used by computer systems cannot store numbers > >> accurately. The example that I use when teaching training courses is > >> 14.2 which actually ends up as something close to 14.197. > >> UniVerse gets around this with a wonderful concept called "wide zero" > >> that says, when testing for equality of floating point numbers, they > >> must be within some specified value of being equal rather than > >> strictly equal. The default wide zero error tolerance, set in IEEE > >> format with the WIDEZERO configuration parameter, is 2.91 * 10^-11 (2^ > >> 035) which is good for most business applications but occasionally needs > >> adjusting. > >> Unidata has a command, SET.WIDEZERO, to serve the same purpose but > >> defaults to 0.0 for backward comaptibility. > >> Martin Phillips > >> Ladybridge Systems Ltd > >> 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England > >> +44 (0)1604-709200 > >> - Original Message - > >> From: "George Hammerle"mailto:zhamme...@hubert.com>> > >> To:mailto:u2-users@listserver.u2ug.org>> > >> Sent: Thursday, September 29, 2011 1:30 PM > >> Subject: [U2] The math just doesn't work. > >>> Can anybody please help? > >>> For some reason A + B does not equal C
Re: [U2] The math just doesn't work.
Hi all, If my memory over 20 years ago in PI/open development is reliable (probably not), I seem to recall that the string arithmetic functions were invented to handle either very large integer numbers or fractional numbers with a large number of decimal places. I think it was the high precision daily interest calculations required by banking systems that motivated the development. Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England +44 (0)1604-709200 - Original Message - From: "Wjhonson" To: Sent: Monday, October 10, 2011 6:35 PM Subject: Re: [U2] The math just doesn't work. I thought that large integer addition is why the functions SADD, SCMP and SDIV were invented? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
Brett: When I run the following code on UD v7.2.7, it works fine. * ** Test program EXECUTE \SET.WIDEZERO 0.01\ * NUL = '' CM = ',' A = -409071.8775: CM: 475000: CM: -652413: CM: 652413: CM: -475000: CM: 409071.8775 * TEST.VMC = 1 TEST.TOTAL = 0 * LOOP UNTIL FIELD(A, CM, TEST.VMC) = NUL DO TEST.TOTAL += FIELD(A, CM, TEST.VMC) TEST.VMC += 1 REPEAT * IF TEST.TOTAL = 0 THEN PRINT 'OK' END ELSE PRINT TEST.TOTAL, (TEST.TOTAL = 0), TEST.TOTAL - 0, (OCONV(TEST.TOTAL, 'MD0') = 0) END *2 Dev (0)-> RUN BP BILL OK* HTH, Bill - Original Message - *From:* bre...@gpmdev.co.uk *To:* u2-users@listserver.u2ug.org *Date:* 10/10/2011 1:16 AM *Subject:* Re: [U2] The math just doesn't work. I also thought: "great explanation" and nodded sagely when I read this. However, consider this code: NUL = '' CM = ',' A = -409071.8775: CM: 475000: CM: -652413: CM: 652413: CM: -475000: CM: 409071.8775 * * TEST.VMC = 1 TEST.TOTAL = 0 * LOOP UNTIL FIELD(A, CM, TEST.VMC) = NUL DO TEST.TOTAL += FIELD(A, CM, TEST.VMC) TEST.VMC += 1 REPEAT * IF TEST.TOTAL = 0 THEN PRINT 'OK' END ELSE PRINT TEST.TOTAL, (TEST.TOTAL = 0), TEST.TOTAL - 0, (OCONV(TEST.TOTAL, 'MD0') = 0) END Running this on our Universe system 11.1.1 produces: 0 0 0 1 So, in other words zero is the total result in TEST.TOTAL but this does not equate to zero. Now I know I can get round this by rounding the answer but am not sure why I should have to. Any ideas? Thanks Brett "Martin Phillips"mailto:martinphill...@ladybridge.com>> wrote in message news:<2636297EDC484501AD1A5AC277EE76A7@lbs8<news:%3c2636297EDC484501AD1A5AC277EE76A7@lbs8>>... Hi George, As a general rule in programming, comparison of floating point values for equality should be avoided. This is because, just as we cannot write the number one third accurately in decimal notation, so the IEEE floating point format used by computer systems cannot store numbers accurately. The example that I use when teaching training courses is 14.2 which actually ends up as something close to 14.197. UniVerse gets around this with a wonderful concept called "wide zero" that says, when testing for equality of floating point numbers, they must be within some specified value of being equal rather than strictly equal. The default wide zero error tolerance, set in IEEE format with the WIDEZERO configuration parameter, is 2.91 * 10^-11 (2^ 035) which is good for most business applications but occasionally needs adjusting. Unidata has a command, SET.WIDEZERO, to serve the same purpose but defaults to 0.0 for backward comaptibility. Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England +44 (0)1604-709200 - Original Message - From: "George Hammerle"mailto:zhamme...@hubert.com>> To:mailto:u2-users@listserver.u2ug.org>> Sent: Thursday, September 29, 2011 1:30 PM Subject: [U2] The math just doesn't work. Can anybody please help? For some reason A + B does not equal C in the comparison below. Is there any trick to get the comparisons to work properly? Unidata 7.2 on Hp Unix 11+ Top of "TEST.COMP" in "RMH.MAIN", 13 lines, 263 characters. *--: P 001: A = 3176.79 002: B = 106.19 003: C = 3282.98 004: D = 920.11 005: A = A + D 006: C = C + D 007: IF (A+B) # C THEN 008: CRT '(A+B) # C? YOU LIE' 009: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C 010: END ELSE 011: CRT '(A+B) = C? YOU ROCK' 012: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C 013: END Bottom. *--: FIBR Filed "TEST.COMP" in file "RMH.MAIN" unchanged. Compiling Unibasic: /db1/ud1/PGM/RMH.MAIN/TEST.COMP in mode 'u'. compilation finished (A+B) # C? YOU LIE A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09 George Hammerle Programming Dude Hubert Company LLC. 9555 Dry Fork Road Harrison, Ohio 45030 513-367-8974 zhammerle@hubertREMOVE_THIS.com<mailto:zhammerle@hubertREMOVE_THIS.com> ___ U2-Users mailing list U2-Users@listserver.u2ug.org<mailto:U2-Users@listserver.u2ug.org> http://listserver.u2ug.org/mailman/listinfo/u2-users This message contains information that may be privileged or confidential and is the property of GPM Development Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient ,you are not authorized to read,
Re: [U2] The math just doesn't work.
Oh great... here come the SADD, MADD, and other assorted jokes... :| On Mon, Oct 10, 2011 at 1:35 PM, Wjhonson wrote: > > I thought that large integer addition is why the functions SADD, SCMP and > SDIV were invented? > ___ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users > -- John Thompson ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
I thought that large integer addition is why the functions SADD, SCMP and SDIV were invented? ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
On 10/10/2011 12:31 PM, Wols Lists wrote: > On 10/10/11 13:31, Allen Egerton wrote: >> On 10/10/2011 8:12 AM, Israel, John R. wrote: >>> I am coming late to this party, but wanted to throw out a bug that was just >>> reported to Rocket. We found that PERCISION was causing a calculation to >>> round in some cases and truncate in others. I am not sure where this >>> stands because someone else on my team is driving this ticket, but it was >>> pretty disturbing that the same calculation worked differently. >>> >>> John Israel >> >> John, >> >> Here's the essence of an open ticket we've got with Rocket for Universe >> 10.3.7 on a windows server: >> >> >>> CT ADE.BP TT >> >> TT >> 0001 FOR II = 1 TO 18 >> 0002 CRT FMT(II, "2R"): " ": FMT(10^II + 1, "35R,") >> 0003 NEXT II >> 0004 STOP >>> RUN ADE.BP TT >> 1 11 >> 2 101 >> 3 1,001 >> 4 10,001 >> 5 100,001 >> 6 1,000,001 >> 7 10,000,001 >> 8 100,000,001 >> 9 1,000,000,001 >> 10 10,000,000,001 >> 11 100,000,000,001 >> 12 1,000,000,000,001 >> 13 10,000,000,000,001 >> 14 100,000,000,000,001 >> 15 1,000,000,000,000,000 >> 16 10,000,000,000,000,000 >> 17 100,000,000,000,000,000 >> 18 1,000,000,000,000,000,000 >> >> See anything wrong with the least significant column? >> > I notice that it starts going wrong beyond 14... Which I understood was > the maximum possible value of PRECISION. Maybe you can set it higher, > but it doesn't *work* any higher, because, iirc, a DOUBLE PRECISION > mantissa only has 14 decimal digits of precision. > > Drifting slightly, Brett's comment that PRECISION only affected display > output is interesting. I always thought it actually controlled the store > (ie A = B * C, the calculation would be accurate precision, but A would > be stored to PRECISION places). HOWEVER this is what I understood from > Pr1me days. And, iirc, Pr1me had BCD microcode which INFORMATION used, > so it makes sense that Pr1me behaviour would be noticeably different > (and that Pr1me behaviour would also be far more "sensible" when viewed > through our decimal eyes :-) I'm reasonably familiar with PRECISION, but I always thought it applied only to the non-whole portions of numbers, and I don't see anything in the documentation that states otherwise. The example above is pure integer, no decimal places... I'd thought that perhaps the config parameter EXACTNUMERIC would affect this, but setting it to 30 had no impact at all. I've got an open ticket with Rocket, I'm hoping they can shed some light. -- allen egerton; aeger...@pobox.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
On 10/10/11 13:31, Allen Egerton wrote: > On 10/10/2011 8:12 AM, Israel, John R. wrote: >> I am coming late to this party, but wanted to throw out a bug that was just >> reported to Rocket. We found that PERCISION was causing a calculation to >> round in some cases and truncate in others. I am not sure where this stands >> because someone else on my team is driving this ticket, but it was pretty >> disturbing that the same calculation worked differently. >> >> John Israel > > John, > > Here's the essence of an open ticket we've got with Rocket for Universe > 10.3.7 on a windows server: > > >> CT ADE.BP TT > > TT > 0001 FOR II = 1 TO 18 > 0002 CRT FMT(II, "2R"): " ": FMT(10^II + 1, "35R,") > 0003 NEXT II > 0004 STOP >> RUN ADE.BP TT > 1 11 > 2 101 > 3 1,001 > 4 10,001 > 5 100,001 > 6 1,000,001 > 7 10,000,001 > 8 100,000,001 > 9 1,000,000,001 > 10 10,000,000,001 > 11 100,000,000,001 > 12 1,000,000,000,001 > 13 10,000,000,000,001 > 14 100,000,000,000,001 > 15 1,000,000,000,000,000 > 16 10,000,000,000,000,000 > 17 100,000,000,000,000,000 > 18 1,000,000,000,000,000,000 > > See anything wrong with the least significant column? > I notice that it starts going wrong beyond 14... Which I understood was the maximum possible value of PRECISION. Maybe you can set it higher, but it doesn't *work* any higher, because, iirc, a DOUBLE PRECISION mantissa only has 14 decimal digits of precision. Drifting slightly, Brett's comment that PRECISION only affected display output is interesting. I always thought it actually controlled the store (ie A = B * C, the calculation would be accurate precision, but A would be stored to PRECISION places). HOWEVER this is what I understood from Pr1me days. And, iirc, Pr1me had BCD microcode which INFORMATION used, so it makes sense that Pr1me behaviour would be noticeably different (and that Pr1me behaviour would also be far more "sensible" when viewed through our decimal eyes :-) Cheers, Wol ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
I was just trying to let folks know that we have a confirmed bug with the PRESISION command. We are on UniData 7.2, HPUX. John Israel John Israel Senior ERP Developer Dayton Superior Corporation 1125 Byers Rd Miamisburg, OH 45342 937-866-0711 x44380 (O) 937-865-9182 (F) This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Allen Egerton Sent: Monday, October 10, 2011 8:31 AM To: U2 Users List Subject: Re: [U2] The math just doesn't work. On 10/10/2011 8:12 AM, Israel, John R. wrote: > I am coming late to this party, but wanted to throw out a bug that was just > reported to Rocket. We found that PERCISION was causing a calculation to > round in some cases and truncate in others. I am not sure where this stands > because someone else on my team is driving this ticket, but it was pretty > disturbing that the same calculation worked differently. > > John Israel John, Here's the essence of an open ticket we've got with Rocket for Universe 10.3.7 on a windows server: >CT ADE.BP TT TT 0001 FOR II = 1 TO 18 0002 CRT FMT(II, "2R"): " ": FMT(10^II + 1, "35R,") 0003 NEXT II 0004 STOP >RUN ADE.BP TT 1 11 2 101 3 1,001 4 10,001 5 100,001 6 1,000,001 7 10,000,001 8 100,000,001 9 1,000,000,001 10 10,000,000,001 11 100,000,000,001 12 1,000,000,000,001 13 10,000,000,000,001 14 100,000,000,000,001 15 1,000,000,000,000,000 16 10,000,000,000,000,000 17 100,000,000,000,000,000 18 1,000,000,000,000,000,000 See anything wrong with the least significant column? -- allen egerton; aeger...@pobox.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
On 10/10/2011 8:12 AM, Israel, John R. wrote: > I am coming late to this party, but wanted to throw out a bug that was just > reported to Rocket. We found that PERCISION was causing a calculation to > round in some cases and truncate in others. I am not sure where this stands > because someone else on my team is driving this ticket, but it was pretty > disturbing that the same calculation worked differently. > > John Israel John, Here's the essence of an open ticket we've got with Rocket for Universe 10.3.7 on a windows server: >CT ADE.BP TT TT 0001 FOR II = 1 TO 18 0002 CRT FMT(II, "2R"): " ": FMT(10^II + 1, "35R,") 0003 NEXT II 0004 STOP >RUN ADE.BP TT 1 11 2 101 3 1,001 4 10,001 5 100,001 6 1,000,001 7 10,000,001 8 100,000,001 9 1,000,000,001 10 10,000,000,001 11 100,000,000,001 12 1,000,000,000,001 13 10,000,000,000,001 14 100,000,000,000,001 15 1,000,000,000,000,000 16 10,000,000,000,000,000 17 100,000,000,000,000,000 18 1,000,000,000,000,000,000 See anything wrong with the least significant column? -- allen egerton; aeger...@pobox.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
I am coming late to this party, but wanted to throw out a bug that was just reported to Rocket. We found that PERCISION was causing a calculation to round in some cases and truncate in others. I am not sure where this stands because someone else on my team is driving this ticket, but it was pretty disturbing that the same calculation worked differently. John Israel John Israel Senior ERP Developer Dayton Superior Corporation 1125 Byers Rd Miamisburg, OH 45342 937-866-0711 x44380 (O) 937-865-9182 (F) This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin Phillips Sent: Monday, October 10, 2011 6:31 AM To: U2 Users List Subject: Re: [U2] The math just doesn't work. Hi Brett, > The realisation for me here is that PRECISION has nothing to do > with the precision of the calculation, it only effects display. Correct. All arithetic operations work at the precision of the underlying hardware. PRECISION applies when converting a floating point number to a character string. Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England +44 (0)1604-709200 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
Hi Brett, The realisation for me here is that PRECISION has nothing to do with the precision of the calculation, it only effects display. Correct. All arithetic operations work at the precision of the underlying hardware. PRECISION applies when converting a floating point number to a character string. Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England +44 (0)1604-709200 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
Hi Martin, Ok, have re-run with PRECISION 14. I now get: 0.0058210 0.0058211 So, the difference is 5.8 * 10^-11 which I can see is greater than the standard Wide Zero setting. The realisation for me here is that PRECISION has nothing to do with the precision of the calculation, it only effects display. Thanks for the insight. Brett "Martin Phillips" wrote in message news:<373068736ABE411796AEF7AD7F0A6B1D@lbs8>... > Hi Brett, > > I think my discussion on this topic still holds. Run your program with >PRECISION 14 > at the top and you can see the rounding errors creeping in. This is exactly > why comparing floating point values is generally considered a bad idea. > > > Martin Phillips > Ladybridge Systems Ltd > 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England > +44 (0)1604-709200 > > - Original Message - > From: "Brett Callacher" > To: > Sent: Monday, October 10, 2011 9:16 AM > Subject: Re: [U2] The math just doesn't work. > > > >I also thought: "great explanation" and nodded sagely when I read this. > >However, consider this code: > > > > > > > > NUL = '' > > > > CM = ',' > > > > A = -409071.8775: CM: 475000: CM: -652413: CM: 652413: CM: -475000: > > CM: 409071.8775 > > > > * > > > > * > > > > TEST.VMC = 1 > > > > TEST.TOTAL = 0 > > > > * > > > > LOOP UNTIL FIELD(A, CM, TEST.VMC) = NUL DO > > > > TEST.TOTAL += FIELD(A, CM, TEST.VMC) > > > > TEST.VMC += 1 > > > > REPEAT > > > > * > > > > IF TEST.TOTAL = 0 THEN > > > > PRINT 'OK' > > > > END ELSE > > > > PRINT TEST.TOTAL, (TEST.TOTAL = 0), TEST.TOTAL - 0, > > (OCONV(TEST.TOTAL, 'MD0') = 0) > > > > END > > > > > > > > > > > > Running this on our Universe system 11.1.1 produces: > > > > > > > > 0 0 0 1 > > > > > > > > So, in other words zero is the total result in TEST.TOTAL but this does > > not equate to zero. > > > > > > > > Now I know I can get round this by rounding the answer but am not sure why > > I should have to. Any ideas? > > > > > > > > Thanks > > > > > > > > Brett > > > > > > > > "Martin Phillips" > > mailto:martinphill...@ladybridge.com>> > > wrote in message > > news:<2636297EDC484501AD1A5AC277EE76A7@lbs8<news:%3c2636297EDC484501AD1A5AC277EE76A7@lbs8>>... > > > >> Hi George, > > > >> > > > >> As a general rule in programming, comparison of floating point values > > > >> for equality should be avoided. This is because, just as we cannot > > > >> write the number one third accurately in decimal notation, so the IEEE > > > >> floating point format used by computer systems cannot store numbers > > > >> accurately. The example that I use when teaching training courses is > > > >> 14.2 which actually ends up as something close to 14.197. > > > >> > > > >> UniVerse gets around this with a wonderful concept called "wide zero" > > > >> that says, when testing for equality of floating point numbers, they > > > >> must be within some specified value of being equal rather than > > > >> strictly equal. The default wide zero error tolerance, set in IEEE > > > >> format with the WIDEZERO configuration parameter, is 2.91 * 10^-11 (2^ > > > >> 035) which is good for most business applications but occasionally needs > >> adjusting. > > > >> > > > >> Unidata has a command, SET.WIDEZERO, to serve the same purpose but > > > >> defaults to 0.0 for backward comaptibility. > > > >> > > > >> > > > >> Martin Phillips > > > >> Ladybridge Systems Ltd > > > >> 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England > > > >> +44 (0)1604-709200 > > > >> > > > >> > > > >> - Original Message - > > > >> From: "George Hammerle" > >> mailto:zhamme...@hubert.com>> > > > >> To: mailto:u2-users@listserver.u2ug.org>> > > > >> Sent: Thursday, Septemb
Re: [U2] The math just doesn't work.
Hi Brett, I think my discussion on this topic still holds. Run your program with PRECISION 14 at the top and you can see the rounding errors creeping in. This is exactly why comparing floating point values is generally considered a bad idea. Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England +44 (0)1604-709200 - Original Message - From: "Brett Callacher" To: Sent: Monday, October 10, 2011 9:16 AM Subject: Re: [U2] The math just doesn't work. I also thought: "great explanation" and nodded sagely when I read this. However, consider this code: NUL = '' CM = ',' A = -409071.8775: CM: 475000: CM: -652413: CM: 652413: CM: -475000: CM: 409071.8775 * * TEST.VMC = 1 TEST.TOTAL = 0 * LOOP UNTIL FIELD(A, CM, TEST.VMC) = NUL DO TEST.TOTAL += FIELD(A, CM, TEST.VMC) TEST.VMC += 1 REPEAT * IF TEST.TOTAL = 0 THEN PRINT 'OK' END ELSE PRINT TEST.TOTAL, (TEST.TOTAL = 0), TEST.TOTAL - 0, (OCONV(TEST.TOTAL, 'MD0') = 0) END Running this on our Universe system 11.1.1 produces: 0 0 0 1 So, in other words zero is the total result in TEST.TOTAL but this does not equate to zero. Now I know I can get round this by rounding the answer but am not sure why I should have to. Any ideas? Thanks Brett "Martin Phillips" mailto:martinphill...@ladybridge.com>> wrote in message news:<2636297EDC484501AD1A5AC277EE76A7@lbs8<news:%3c2636297EDC484501AD1A5AC277EE76A7@lbs8>>... Hi George, As a general rule in programming, comparison of floating point values for equality should be avoided. This is because, just as we cannot write the number one third accurately in decimal notation, so the IEEE floating point format used by computer systems cannot store numbers accurately. The example that I use when teaching training courses is 14.2 which actually ends up as something close to 14.197. UniVerse gets around this with a wonderful concept called "wide zero" that says, when testing for equality of floating point numbers, they must be within some specified value of being equal rather than strictly equal. The default wide zero error tolerance, set in IEEE format with the WIDEZERO configuration parameter, is 2.91 * 10^-11 (2^ 035) which is good for most business applications but occasionally needs adjusting. Unidata has a command, SET.WIDEZERO, to serve the same purpose but defaults to 0.0 for backward comaptibility. Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England +44 (0)1604-709200 - Original Message - From: "George Hammerle" mailto:zhamme...@hubert.com>> To: mailto:u2-users@listserver.u2ug.org>> Sent: Thursday, September 29, 2011 1:30 PM Subject: [U2] The math just doesn't work. > Can anybody please help? > > For some reason A + B does not equal C in the comparison below. Is > there any trick to get the comparisons to work properly? > > Unidata 7.2 on Hp Unix 11+ > > > Top of "TEST.COMP" in "RMH.MAIN", 13 lines, 263 characters. > *--: P > 001: A = 3176.79 > 002: B = 106.19 > 003: C = 3282.98 > 004: D = 920.11 > 005: A = A + D > 006: C = C + D > 007: IF (A+B) # C THEN > 008: CRT '(A+B) # C? YOU LIE' > 009: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C > 010: END ELSE > 011: CRT '(A+B) = C? YOU ROCK' > 012: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C > 013: END > Bottom. > *--: FIBR > Filed "TEST.COMP" in file "RMH.MAIN" unchanged. > > Compiling Unibasic: /db1/ud1/PGM/RMH.MAIN/TEST.COMP in mode 'u'. > compilation finished > > (A+B) # C? YOU LIE > A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09 > > > > >George Hammerle >Programming Dude >Hubert Company LLC. >9555 Dry Fork Road >Harrison, Ohio 45030 >513-367-8974 > > zhammerle@hubertREMOVE_THIS.com<mailto:zhammerle@hubertREMOVE_THIS.com> ___ U2-Users mailing list U2-Users@listserver.u2ug.org<mailto:U2-Users@listserver.u2ug.org> http://listserver.u2ug.org/mailman/listinfo/u2-users This message contains information that may be privileged or confidential and is the property of GPM Development Ltd
Re: [U2] The math just doesn't work.
I also thought: "great explanation" and nodded sagely when I read this. However, consider this code: NUL = '' CM = ',' A = -409071.8775: CM: 475000: CM: -652413: CM: 652413: CM: -475000: CM: 409071.8775 * * TEST.VMC = 1 TEST.TOTAL = 0 * LOOP UNTIL FIELD(A, CM, TEST.VMC) = NUL DO TEST.TOTAL += FIELD(A, CM, TEST.VMC) TEST.VMC += 1 REPEAT * IF TEST.TOTAL = 0 THEN PRINT 'OK' END ELSE PRINT TEST.TOTAL, (TEST.TOTAL = 0), TEST.TOTAL - 0, (OCONV(TEST.TOTAL, 'MD0') = 0) END Running this on our Universe system 11.1.1 produces: 0 0 0 1 So, in other words zero is the total result in TEST.TOTAL but this does not equate to zero. Now I know I can get round this by rounding the answer but am not sure why I should have to. Any ideas? Thanks Brett "Martin Phillips" mailto:martinphill...@ladybridge.com>> wrote in message news:<2636297EDC484501AD1A5AC277EE76A7@lbs8<news:%3c2636297EDC484501AD1A5AC277EE76A7@lbs8>>... > Hi George, > > As a general rule in programming, comparison of floating point values > for equality should be avoided. This is because, just as we cannot > write the number one third accurately in decimal notation, so the IEEE > floating point format used by computer systems cannot store numbers > accurately. The example that I use when teaching training courses is > 14.2 which actually ends up as something close to 14.197. > > UniVerse gets around this with a wonderful concept called "wide zero" > that says, when testing for equality of floating point numbers, they > must be within some specified value of being equal rather than > strictly equal. The default wide zero error tolerance, set in IEEE > format with the WIDEZERO configuration parameter, is 2.91 * 10^-11 (2^ > 035) which is good for most business applications but occasionally needs > adjusting. > > Unidata has a command, SET.WIDEZERO, to serve the same purpose but > defaults to 0.0 for backward comaptibility. > > > Martin Phillips > Ladybridge Systems Ltd > 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England > +44 (0)1604-709200 > > > - Original Message ----- > From: "George Hammerle" mailto:zhamme...@hubert.com>> > To: mailto:u2-users@listserver.u2ug.org>> > Sent: Thursday, September 29, 2011 1:30 PM > Subject: [U2] The math just doesn't work. > > > > Can anybody please help? > > > > For some reason A + B does not equal C in the comparison below. Is > > there any trick to get the comparisons to work properly? > > > > Unidata 7.2 on Hp Unix 11+ > > > > > > Top of "TEST.COMP" in "RMH.MAIN", 13 lines, 263 characters. > > *--: P > > 001: A = 3176.79 > > 002: B = 106.19 > > 003: C = 3282.98 > > 004: D = 920.11 > > 005: A = A + D > > 006: C = C + D > > 007: IF (A+B) # C THEN > > 008: CRT '(A+B) # C? YOU LIE' > > 009: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C > > 010: END ELSE > > 011: CRT '(A+B) = C? YOU ROCK' > > 012: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C > > 013: END > > Bottom. > > *--: FIBR > > Filed "TEST.COMP" in file "RMH.MAIN" unchanged. > > > > Compiling Unibasic: /db1/ud1/PGM/RMH.MAIN/TEST.COMP in mode 'u'. > > compilation finished > > > > (A+B) # C? YOU LIE > > A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09 > > > > > > > > > >George Hammerle > >Programming Dude > >Hubert Company LLC. > >9555 Dry Fork Road > >Harrison, Ohio 45030 > >513-367-8974 > > > > zhammerle@hubertREMOVE_THIS.com<mailto:zhammerle@hubertREMOVE_THIS.com> > > ___ > U2-Users mailing list > U2-Users@listserver.u2ug.org<mailto:U2-Users@listserver.u2ug.org> > http://listserver.u2ug.org/mailman/listinfo/u2-users > This message contains information that may be privileged or confidential and is the property of GPM Development Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient ,you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. This e-mail was sent to you by GPM Development Ltd. We are incorporated under the laws of England and Wales (company no. 2292156 and VAT registration no. 523 5622 63). Our registered office is 6th Floor, AMP House, Croydon, Surrey CR0 2LX. ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
Hi Mecki, I actually wonder if this "feature" is flavour specific? Pick didn't use floating point arithmetic and IIRC the default precision used to be 4. PRECISION affects the number of decimal places in the result when converting a floating point value to a character string. All internal arithmetic operations are performed at the precision of the underlying hardware. Applying precision at each arithmetic operation would introduce "cumulative rounding errors". Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England +44 (0)1604-709200 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
I actually wonder if this "feature" is flavour specific?
Pick didn't use floating point arithmetic and IIRC the default precision
used to be 4.
I'll give it a try tomorrow since we are running UD in Pick flavour at work.
On 29/09/2011 19:32, Oaks, Harold wrote:
Mecki:
Oops, that's right - Martin pointed out it would work in Universe - it
did.
In our uvconfig file the variable setting is
WIDE0 3dc0
which is the default value.
In case anyone wishes to change the value, note that the WIDE0 variable
has an entire appendix devoted to it in the "Administering Universe"
guide.
Harold
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki
Foerthmann
Sent: Thursday, September 29, 2011 8:53 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] The math just doesn't work.
You didn't read Martin's answer, or did you?
So to what value is WIDEZERO set on your UV system?
On 29/09/2011 16:40, Oaks, Harold wrote:
Running Martin's code on a Universe system, got:
(A+B) = C? YOU ROCK
A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09
Interesting - Universe does better than Unidata at this particular
task.
Harold Oaks
Clark County
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Thursday, September 29, 2011 6:21 AM
To: 'U2 Users List'
Subject: Re: [U2] The math just doesn't work.
And just to add to Martin's excellent answer - the normal workround
for
any
computer system is to use integral values, scaling and descaling as
required.
In case you think this is a U2 specific limitation, here's the same in
C# as
a console app -
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
float A = 3176.79f;
float B = 106.19f;
float C = 3282.98f;
float D = 920.11f;
A = A + D;
C = C + D ;
if((A+B) != C ){
Console.WriteLine("You lie, A+B = {0}, C= {1}",(A+B),
C);
} else{
Console.WriteLine("you rock");
}
pressAnyKey();
}
static void pressAnyKey()
{
Console.Write("Press any key ...");
Console.ReadLine();
}
}
}
Result -
You lie, A+B = 4203.09, C= 4203.09
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin
Phillips
Sent: 29 September 2011 13:46
To: U2 Users List
Subject: Re: [U2] The math just doesn't work.
Hi George,
As a general rule in programming, comparison of floating point values
for
equality should be avoided. This is because, just as we cannot write
the
number one third accurately in decimal notation, so the IEEE floating
point
format used by computer systems cannot store numbers accurately. The
example
that I use when teaching training courses is 14.2 which actually ends
up
as
something close to 14.197.
UniVerse gets around this with a wonderful concept called "wide zero"
that
says, when testing for equality of floating point numbers, they must
be
within some specified value of being equal rather than strictly equal.
The
default wide zero error tolerance, set in IEEE format with the
WIDEZERO
configuration parameter, is 2.91 * 10^-11 (2^ 035) which is good for
most
business applications but occasionally needs adjusting.
Unidata has a command, SET.WIDEZERO, to serve the same purpose but
defaults
to 0.0 for backward comaptibility.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200
----- Original Message -
From: "George Hammerle"
To:
Sent: Thursday, September 29, 2011 1:30 PM
Subject: [U2] The math just doesn't work.
Can anybody please help?
For some reason A + B does not equal C in the comparison below. Is
there
any trick to get the comparisons to work properly?
Unidata 7.2 on Hp Unix 11+
Top of "TEST.COMP" in "RMH.MAIN", 13 lines, 263 characters.
*--: P
001: A = 3176.79
002: B = 106.19
003: C = 3282.98
004: D = 920.11
005: A = A + D
006: C = C + D
007: IF (A+B) # C THEN
008: CRT '(A+B) # C? YOU LIE'
009: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C
010: END ELSE
011: CRT '(A+B) = C? YOU ROCK'
012: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C
013: END
Bottom.
*--: FIBR
Filed "TEST.COMP" in file "RMH.MAIN" unchanged.
Compiling Unibasic: /db1/ud1/PGM/RMH.MAIN/TEST.COMP in mode 'u'.
compilation finished
(A+B) # C? YOU
Re: [U2] The math just doesn't work.
In UniData the FLOAT.PRECISION which is an ECL command. It works similar to
SET.WIDEZERO. Execute the command as FLOAT.PRECISION 3 and then run the
program then it works. Then FLOAT.PRECISION 3 is in VOC LOGIN.
(A+B) = C? YOU ROCK
A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09
Kathleené M Hunter
Resolution Provider All
days are great
www.ResolutionProvider.com Some
are just greater than others.
619-922-4116 - phone
resolutionprovider - Skype
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Thursday, September 29, 2011 9:02 AM
To: U2 Users List
Subject: Re: [U2] The math just doesn't work.
I tried this on UD v7.2.7 on Windows 2008 R2. I added the following code at
the top of George's code:
EXECUTE \SET.WIDEZERO 0.001\
This is what I got...
2 Dev (0)->RUN BP BILL
(A+B) = C? YOU ROCK
A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09
2 Dev (0)->
Bill
- Original Message -
*From:* harold.o...@clark.wa.gov
*To:* U2 Users List
*Date:* 9/29/2011 8:40 AM
*Subject:* Re: [U2] The math just doesn't work.
> Running Martin's code on a Universe system, got:
> (A+B) = C? YOU ROCK
> A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09
>
> Interesting - Universe does better than Unidata at this particular task.
>
> Harold Oaks
> Clark County
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
> Sent: Thursday, September 29, 2011 6:21 AM
> To: 'U2 Users List'
> Subject: Re: [U2] The math just doesn't work.
>
> And just to add to Martin's excellent answer - the normal workround
> for any computer system is to use integral values, scaling and
> descaling as required.
>
>
> In case you think this is a U2 specific limitation, here's the same in
> C# as a console app -
>
> namespace ConsoleApplication1
> {
> class Program
> {
> static void Main(string[] args)
> {
> float A = 3176.79f;
> float B = 106.19f;
> float C = 3282.98f;
> float D = 920.11f;
> A = A + D;
> C = C + D ;
>if((A+B) != C ){
>Console.WriteLine("You lie, A+B = {0}, C= {1}",(A+B), C);
>} else{
>Console.WriteLine("you rock");
>}
>pressAnyKey();
> }
>
> static void pressAnyKey()
> {
> Console.Write("Press any key ...");
> Console.ReadLine();
> }
> }
>
> }
> Result -
> You lie, A+B = 4203.09, C= 4203.09
>
>
>
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin
> Phillips
> Sent: 29 September 2011 13:46
> To: U2 Users List
> Subject: Re: [U2] The math just doesn't work.
>
> Hi George,
>
> As a general rule in programming, comparison of floating point values
> for equality should be avoided. This is because, just as we cannot
> write the
>
> number one third accurately in decimal notation, so the IEEE floating
> point format used by computer systems cannot store numbers accurately.
> The example
>
> that I use when teaching training courses is 14.2 which actually ends
> up as something close to 14.197.
>
> UniVerse gets around this with a wonderful concept called "wide zero"
> that
> says, when testing for equality of floating point numbers, they must
> be within some specified value of being equal rather than strictly equal.
> The
> default wide zero error tolerance, set in IEEE format with the
> WIDEZERO configuration parameter, is 2.91 * 10^-11 (2^ 035) which is
> good for most business applications but occasionally needs adjusting.
>
> Unidata has a command, SET.WIDEZERO, to serve the same purpose but
> defaults to 0.0 for backward comaptibility.
>
>
> Martin Phillips
> Ladybridge Systems Ltd
> 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
> +44 (0)1604-709200
>
>
> - Original Message -
> From: "George Hammerle"
> To:
> Sent: Thursday, September 29, 2011 1:30 PM
> Subject: [U2] The math just doesn't work.
>
>
>> Can anybody please help?
>>
>> For some reason A + B does not equal C in the comparison below. Is
> there
>> any trick to get t
Re: [U2] The math just doesn't work.
Mecki:
Oops, that's right - Martin pointed out it would work in Universe - it
did.
In our uvconfig file the variable setting is
WIDE0 3dc0
which is the default value.
In case anyone wishes to change the value, note that the WIDE0 variable
has an entire appendix devoted to it in the "Administering Universe"
guide.
Harold
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki
Foerthmann
Sent: Thursday, September 29, 2011 8:53 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] The math just doesn't work.
You didn't read Martin's answer, or did you?
So to what value is WIDEZERO set on your UV system?
On 29/09/2011 16:40, Oaks, Harold wrote:
> Running Martin's code on a Universe system, got:
> (A+B) = C? YOU ROCK
> A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09
>
> Interesting - Universe does better than Unidata at this particular
task.
>
> Harold Oaks
> Clark County
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
> Sent: Thursday, September 29, 2011 6:21 AM
> To: 'U2 Users List'
> Subject: Re: [U2] The math just doesn't work.
>
> And just to add to Martin's excellent answer - the normal workround
for
> any
> computer system is to use integral values, scaling and descaling as
> required.
>
>
> In case you think this is a U2 specific limitation, here's the same in
> C# as
> a console app -
>
> namespace ConsoleApplication1
> {
> class Program
> {
> static void Main(string[] args)
> {
> float A = 3176.79f;
> float B = 106.19f;
> float C = 3282.98f;
> float D = 920.11f;
> A = A + D;
> C = C + D ;
>if((A+B) != C ){
>Console.WriteLine("You lie, A+B = {0}, C= {1}",(A+B),
C);
>} else{
>Console.WriteLine("you rock");
>}
>pressAnyKey();
> }
>
> static void pressAnyKey()
> {
> Console.Write("Press any key ...");
> Console.ReadLine();
> }
> }
>
> }
> Result -
> You lie, A+B = 4203.09, C= 4203.09
>
>
>
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin
> Phillips
> Sent: 29 September 2011 13:46
> To: U2 Users List
> Subject: Re: [U2] The math just doesn't work.
>
> Hi George,
>
> As a general rule in programming, comparison of floating point values
> for
> equality should be avoided. This is because, just as we cannot write
the
>
> number one third accurately in decimal notation, so the IEEE floating
> point
> format used by computer systems cannot store numbers accurately. The
> example
>
> that I use when teaching training courses is 14.2 which actually ends
up
> as
> something close to 14.197.
>
> UniVerse gets around this with a wonderful concept called "wide zero"
> that
> says, when testing for equality of floating point numbers, they must
be
> within some specified value of being equal rather than strictly equal.
> The
> default wide zero error tolerance, set in IEEE format with the
WIDEZERO
> configuration parameter, is 2.91 * 10^-11 (2^ 035) which is good for
> most
> business applications but occasionally needs adjusting.
>
> Unidata has a command, SET.WIDEZERO, to serve the same purpose but
> defaults
> to 0.0 for backward comaptibility.
>
>
> Martin Phillips
> Ladybridge Systems Ltd
> 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
> +44 (0)1604-709200
>
>
> - Original Message -
> From: "George Hammerle"
> To:
> Sent: Thursday, September 29, 2011 1:30 PM
> Subject: [U2] The math just doesn't work.
>
>
>> Can anybody please help?
>>
>> For some reason A + B does not equal C in the comparison below. Is
> there
>> any trick to get the comparisons to work properly?
>>
>> Unidata 7.2 on Hp Unix 11+
>>
>>
>> Top of "TEST.COMP" in "RMH.MAIN", 13 lines, 263 characters.
>> *--: P
>> 001: A = 3176.79
>> 002: B = 106.19
>> 003: C = 3282.98
>> 004: D = 920.11
>> 005: A = A + D
>> 006: C = C + D
>> 007: IF (A+B) # C THEN
>> 008: CRT '(A+B) # C? YOU LIE'
>> 009: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = &#x
Re: [U2] The math just doesn't work.
I get the same result on UV 10.2.7: (A+B) = C? YOU ROCK A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09 This is what I have for the uvconfig WIDE0 setting: # WIDE0 - is the mask used internally to # decide when the difference between two # numeric values is close enough to zero # to be called zero. For information # please request Technical Bulletin 74-0051 WIDE0 3dc0 I've never changed it from the default, so apparently the UV default is different from the UD default, at least between UV 10.2.7 and UD 7.2. -John -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Oaks, Harold Sent: Thursday, September 29, 2011 8:40 AM To: U2 Users List Subject: Re: [U2] The math just doesn't work. Running Martin's code on a Universe system, got: (A+B) = C? YOU ROCK A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09 Interesting - Universe does better than Unidata at this particular task. Harold Oaks Clark County ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
I tried this on UD v7.2.7 on Windows 2008 R2. I added the following
code at the top of George's code:
EXECUTE \SET.WIDEZERO 0.001\
This is what I got...
2 Dev (0)->RUN BP BILL
(A+B) = C? YOU ROCK
A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09
2 Dev (0)->
Bill
- Original Message -
*From:* harold.o...@clark.wa.gov
*To:* U2 Users List
*Date:* 9/29/2011 8:40 AM
*Subject:* Re: [U2] The math just doesn't work.
Running Martin's code on a Universe system, got:
(A+B) = C? YOU ROCK
A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09
Interesting - Universe does better than Unidata at this particular task.
Harold Oaks
Clark County
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Thursday, September 29, 2011 6:21 AM
To: 'U2 Users List'
Subject: Re: [U2] The math just doesn't work.
And just to add to Martin's excellent answer - the normal workround for
any
computer system is to use integral values, scaling and descaling as
required.
In case you think this is a U2 specific limitation, here's the same in
C# as
a console app -
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
float A = 3176.79f;
float B = 106.19f;
float C = 3282.98f;
float D = 920.11f;
A = A + D;
C = C + D ;
if((A+B) != C ){
Console.WriteLine("You lie, A+B = {0}, C= {1}",(A+B), C);
} else{
Console.WriteLine("you rock");
}
pressAnyKey();
}
static void pressAnyKey()
{
Console.Write("Press any key ...");
Console.ReadLine();
}
}
}
Result -
You lie, A+B = 4203.09, C= 4203.09
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin
Phillips
Sent: 29 September 2011 13:46
To: U2 Users List
Subject: Re: [U2] The math just doesn't work.
Hi George,
As a general rule in programming, comparison of floating point values
for
equality should be avoided. This is because, just as we cannot write the
number one third accurately in decimal notation, so the IEEE floating
point
format used by computer systems cannot store numbers accurately. The
example
that I use when teaching training courses is 14.2 which actually ends up
as
something close to 14.197.
UniVerse gets around this with a wonderful concept called "wide zero"
that
says, when testing for equality of floating point numbers, they must be
within some specified value of being equal rather than strictly equal.
The
default wide zero error tolerance, set in IEEE format with the WIDEZERO
configuration parameter, is 2.91 * 10^-11 (2^ 035) which is good for
most
business applications but occasionally needs adjusting.
Unidata has a command, SET.WIDEZERO, to serve the same purpose but
defaults
to 0.0 for backward comaptibility.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200
- Original Message -----
From: "George Hammerle"
To:
Sent: Thursday, September 29, 2011 1:30 PM
Subject: [U2] The math just doesn't work.
Can anybody please help?
For some reason A + B does not equal C in the comparison below. Is
there
any trick to get the comparisons to work properly?
Unidata 7.2 on Hp Unix 11+
Top of "TEST.COMP" in "RMH.MAIN", 13 lines, 263 characters.
*--: P
001: A = 3176.79
002: B = 106.19
003: C = 3282.98
004: D = 920.11
005: A = A + D
006: C = C + D
007: IF (A+B) # C THEN
008: CRT '(A+B) # C? YOU LIE'
009: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C
010: END ELSE
011: CRT '(A+B) = C? YOU ROCK'
012: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C
013: END
Bottom.
*--: FIBR
Filed "TEST.COMP" in file "RMH.MAIN" unchanged.
Compiling Unibasic: /db1/ud1/PGM/RMH.MAIN/TEST.COMP in mode 'u'.
compilation finished
(A+B) # C? YOU LIE
A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09
George Hammerle
Programming Dude
Hubert Company LLC.
9555 Dry Fork Road
Harrison, Ohio 45030
513-367-8974
zhammerle@hubertREMOVE_THIS.com
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-use
Re: [U2] The math just doesn't work.
You didn't read Martin's answer, or did you?
So to what value is WIDEZERO set on your UV system?
On 29/09/2011 16:40, Oaks, Harold wrote:
Running Martin's code on a Universe system, got:
(A+B) = C? YOU ROCK
A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09
Interesting - Universe does better than Unidata at this particular task.
Harold Oaks
Clark County
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Thursday, September 29, 2011 6:21 AM
To: 'U2 Users List'
Subject: Re: [U2] The math just doesn't work.
And just to add to Martin's excellent answer - the normal workround for
any
computer system is to use integral values, scaling and descaling as
required.
In case you think this is a U2 specific limitation, here's the same in
C# as
a console app -
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
float A = 3176.79f;
float B = 106.19f;
float C = 3282.98f;
float D = 920.11f;
A = A + D;
C = C + D ;
if((A+B) != C ){
Console.WriteLine("You lie, A+B = {0}, C= {1}",(A+B), C);
} else{
Console.WriteLine("you rock");
}
pressAnyKey();
}
static void pressAnyKey()
{
Console.Write("Press any key ...");
Console.ReadLine();
}
}
}
Result -
You lie, A+B = 4203.09, C= 4203.09
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin
Phillips
Sent: 29 September 2011 13:46
To: U2 Users List
Subject: Re: [U2] The math just doesn't work.
Hi George,
As a general rule in programming, comparison of floating point values
for
equality should be avoided. This is because, just as we cannot write the
number one third accurately in decimal notation, so the IEEE floating
point
format used by computer systems cannot store numbers accurately. The
example
that I use when teaching training courses is 14.2 which actually ends up
as
something close to 14.197.
UniVerse gets around this with a wonderful concept called "wide zero"
that
says, when testing for equality of floating point numbers, they must be
within some specified value of being equal rather than strictly equal.
The
default wide zero error tolerance, set in IEEE format with the WIDEZERO
configuration parameter, is 2.91 * 10^-11 (2^ 035) which is good for
most
business applications but occasionally needs adjusting.
Unidata has a command, SET.WIDEZERO, to serve the same purpose but
defaults
to 0.0 for backward comaptibility.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200
- Original Message -----
From: "George Hammerle"
To:
Sent: Thursday, September 29, 2011 1:30 PM
Subject: [U2] The math just doesn't work.
Can anybody please help?
For some reason A + B does not equal C in the comparison below. Is
there
any trick to get the comparisons to work properly?
Unidata 7.2 on Hp Unix 11+
Top of "TEST.COMP" in "RMH.MAIN", 13 lines, 263 characters.
*--: P
001: A = 3176.79
002: B = 106.19
003: C = 3282.98
004: D = 920.11
005: A = A + D
006: C = C + D
007: IF (A+B) # C THEN
008: CRT '(A+B) # C? YOU LIE'
009: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C
010: END ELSE
011: CRT '(A+B) = C? YOU ROCK'
012: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C
013: END
Bottom.
*--: FIBR
Filed "TEST.COMP" in file "RMH.MAIN" unchanged.
Compiling Unibasic: /db1/ud1/PGM/RMH.MAIN/TEST.COMP in mode 'u'.
compilation finished
(A+B) # C? YOU LIE
A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09
George Hammerle
Programming Dude
Hubert Company LLC.
9555 Dry Fork Road
Harrison, Ohio 45030
513-367-8974
zhammerle@hubertREMOVE_THIS.com
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
This e-mail and related attachments and any response may be subject to public
disclosure under state law.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
Running Martin's code on a Universe system, got:
(A+B) = C? YOU ROCK
A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09
Interesting - Universe does better than Unidata at this particular task.
Harold Oaks
Clark County
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Thursday, September 29, 2011 6:21 AM
To: 'U2 Users List'
Subject: Re: [U2] The math just doesn't work.
And just to add to Martin's excellent answer - the normal workround for
any
computer system is to use integral values, scaling and descaling as
required.
In case you think this is a U2 specific limitation, here's the same in
C# as
a console app -
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
float A = 3176.79f;
float B = 106.19f;
float C = 3282.98f;
float D = 920.11f;
A = A + D;
C = C + D ;
if((A+B) != C ){
Console.WriteLine("You lie, A+B = {0}, C= {1}",(A+B), C);
} else{
Console.WriteLine("you rock");
}
pressAnyKey();
}
static void pressAnyKey()
{
Console.Write("Press any key ...");
Console.ReadLine();
}
}
}
Result -
You lie, A+B = 4203.09, C= 4203.09
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin
Phillips
Sent: 29 September 2011 13:46
To: U2 Users List
Subject: Re: [U2] The math just doesn't work.
Hi George,
As a general rule in programming, comparison of floating point values
for
equality should be avoided. This is because, just as we cannot write the
number one third accurately in decimal notation, so the IEEE floating
point
format used by computer systems cannot store numbers accurately. The
example
that I use when teaching training courses is 14.2 which actually ends up
as
something close to 14.197.
UniVerse gets around this with a wonderful concept called "wide zero"
that
says, when testing for equality of floating point numbers, they must be
within some specified value of being equal rather than strictly equal.
The
default wide zero error tolerance, set in IEEE format with the WIDEZERO
configuration parameter, is 2.91 * 10^-11 (2^ 035) which is good for
most
business applications but occasionally needs adjusting.
Unidata has a command, SET.WIDEZERO, to serve the same purpose but
defaults
to 0.0 for backward comaptibility.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200
- Original Message -
From: "George Hammerle"
To:
Sent: Thursday, September 29, 2011 1:30 PM
Subject: [U2] The math just doesn't work.
> Can anybody please help?
>
> For some reason A + B does not equal C in the comparison below. Is
there
> any trick to get the comparisons to work properly?
>
> Unidata 7.2 on Hp Unix 11+
>
>
> Top of "TEST.COMP" in "RMH.MAIN", 13 lines, 263 characters.
> *--: P
> 001: A = 3176.79
> 002: B = 106.19
> 003: C = 3282.98
> 004: D = 920.11
> 005: A = A + D
> 006: C = C + D
> 007: IF (A+B) # C THEN
> 008: CRT '(A+B) # C? YOU LIE'
> 009: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C
> 010: END ELSE
> 011: CRT '(A+B) = C? YOU ROCK'
> 012: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C
> 013: END
> Bottom.
> *--: FIBR
> Filed "TEST.COMP" in file "RMH.MAIN" unchanged.
>
> Compiling Unibasic: /db1/ud1/PGM/RMH.MAIN/TEST.COMP in mode 'u'.
> compilation finished
>
> (A+B) # C? YOU LIE
> A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09
>
>
>
>
>George Hammerle
>Programming Dude
>Hubert Company LLC.
>9555 Dry Fork Road
>Harrison, Ohio 45030
>513-367-8974
>zhammerle@hubertREMOVE_THIS.com
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
This e-mail and related attachments and any response may be subject to public
disclosure under state law.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
And just to add to Martin's excellent answer - the normal workround for any
computer system is to use integral values, scaling and descaling as
required.
In case you think this is a U2 specific limitation, here's the same in C# as
a console app -
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
float A = 3176.79f;
float B = 106.19f;
float C = 3282.98f;
float D = 920.11f;
A = A + D;
C = C + D ;
if((A+B) != C ){
Console.WriteLine("You lie, A+B = {0}, C= {1}",(A+B), C);
} else{
Console.WriteLine("you rock");
}
pressAnyKey();
}
static void pressAnyKey()
{
Console.Write("Press any key ...");
Console.ReadLine();
}
}
}
Result -
You lie, A+B = 4203.09, C= 4203.09
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Martin Phillips
Sent: 29 September 2011 13:46
To: U2 Users List
Subject: Re: [U2] The math just doesn't work.
Hi George,
As a general rule in programming, comparison of floating point values for
equality should be avoided. This is because, just as we cannot write the
number one third accurately in decimal notation, so the IEEE floating point
format used by computer systems cannot store numbers accurately. The example
that I use when teaching training courses is 14.2 which actually ends up as
something close to 14.197.
UniVerse gets around this with a wonderful concept called "wide zero" that
says, when testing for equality of floating point numbers, they must be
within some specified value of being equal rather than strictly equal. The
default wide zero error tolerance, set in IEEE format with the WIDEZERO
configuration parameter, is 2.91 * 10^-11 (2^ 035) which is good for most
business applications but occasionally needs adjusting.
Unidata has a command, SET.WIDEZERO, to serve the same purpose but defaults
to 0.0 for backward comaptibility.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200
- Original Message -
From: "George Hammerle"
To:
Sent: Thursday, September 29, 2011 1:30 PM
Subject: [U2] The math just doesn't work.
> Can anybody please help?
>
> For some reason A + B does not equal C in the comparison below. Is there
> any trick to get the comparisons to work properly?
>
> Unidata 7.2 on Hp Unix 11+
>
>
> Top of "TEST.COMP" in "RMH.MAIN", 13 lines, 263 characters.
> *--: P
> 001: A = 3176.79
> 002: B = 106.19
> 003: C = 3282.98
> 004: D = 920.11
> 005: A = A + D
> 006: C = C + D
> 007: IF (A+B) # C THEN
> 008: CRT '(A+B) # C? YOU LIE'
> 009: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C
> 010: END ELSE
> 011: CRT '(A+B) = C? YOU ROCK'
> 012: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C
> 013: END
> Bottom.
> *--: FIBR
> Filed "TEST.COMP" in file "RMH.MAIN" unchanged.
>
> Compiling Unibasic: /db1/ud1/PGM/RMH.MAIN/TEST.COMP in mode 'u'.
> compilation finished
>
> (A+B) # C? YOU LIE
> A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09
>
>
>
>
>George Hammerle
>Programming Dude
>Hubert Company LLC.
>9555 Dry Fork Road
>Harrison, Ohio 45030
>513-367-8974
>zhammerle@hubertREMOVE_THIS.com
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
Hi George, As a general rule in programming, comparison of floating point values for equality should be avoided. This is because, just as we cannot write the number one third accurately in decimal notation, so the IEEE floating point format used by computer systems cannot store numbers accurately. The example that I use when teaching training courses is 14.2 which actually ends up as something close to 14.197. UniVerse gets around this with a wonderful concept called "wide zero" that says, when testing for equality of floating point numbers, they must be within some specified value of being equal rather than strictly equal. The default wide zero error tolerance, set in IEEE format with the WIDEZERO configuration parameter, is 2.91 * 10^-11 (2^ 035) which is good for most business applications but occasionally needs adjusting. Unidata has a command, SET.WIDEZERO, to serve the same purpose but defaults to 0.0 for backward comaptibility. Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England +44 (0)1604-709200 - Original Message - From: "George Hammerle" To: Sent: Thursday, September 29, 2011 1:30 PM Subject: [U2] The math just doesn't work. Can anybody please help? For some reason A + B does not equal C in the comparison below. Is there any trick to get the comparisons to work properly? Unidata 7.2 on Hp Unix 11+ Top of "TEST.COMP" in "RMH.MAIN", 13 lines, 263 characters. *--: P 001: A = 3176.79 002: B = 106.19 003: C = 3282.98 004: D = 920.11 005: A = A + D 006: C = C + D 007: IF (A+B) # C THEN 008: CRT '(A+B) # C? YOU LIE' 009: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C 010: END ELSE 011: CRT '(A+B) = C? YOU ROCK' 012: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C 013: END Bottom. *--: FIBR Filed "TEST.COMP" in file "RMH.MAIN" unchanged. Compiling Unibasic: /db1/ud1/PGM/RMH.MAIN/TEST.COMP in mode 'u'. compilation finished (A+B) # C? YOU LIE A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09 George Hammerle Programming Dude Hubert Company LLC. 9555 Dry Fork Road Harrison, Ohio 45030 513-367-8974 zhammerle@hubertREMOVE_THIS.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] The math just doesn't work.
ICONV everything MD2 and check that for equality -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of George Hammerle Sent: 29 September 2011 13:30 To: u2-users@listserver.u2ug.org Subject: [U2] The math just doesn't work. Can anybody please help? For some reason A + B does not equal C in the comparison below. Is there any trick to get the comparisons to work properly? Unidata 7.2 on Hp Unix 11+ Top of "TEST.COMP" in "RMH.MAIN", 13 lines, 263 characters. *--: P 001: A = 3176.79 002: B = 106.19 003: C = 3282.98 004: D = 920.11 005: A = A + D 006: C = C + D 007: IF (A+B) # C THEN 008: CRT '(A+B) # C? YOU LIE' 009: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C 010: END ELSE 011: CRT '(A+B) = C? YOU ROCK' 012: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C 013: END Bottom. *--: FIBR Filed "TEST.COMP" in file "RMH.MAIN" unchanged. Compiling Unibasic: /db1/ud1/PGM/RMH.MAIN/TEST.COMP in mode 'u'. compilation finished (A+B) # C? YOU LIE A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09 George Hammerle Programming Dude Hubert Company LLC. 9555 Dry Fork Road Harrison, Ohio 45030 513-367-8974 zhammerle@hubertREMOVE_THIS.com This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or company to whom they are addressed. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail including all attachments from your system. Thank you ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users Click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== AE52BnsDXn5pV+hkVGX5HIJHEbJBLmXkgHQE4zD1Sgchg== to report this email as spam. Epicor Software (UK) is a limited company registered in England & Wales. Registration Number: 2338274. Registered Office: Osborne Clarke OWA, One London Wall, London EC2Y 5EB This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. Any views and/or opinions expressed in this e-mail are of the author only and do not represent the views of Epicor Software (UK) Limited or any other company within its group. This message has been scanned for malware by Websense. www.websense.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] The math just doesn't work.
Can anybody please help? For some reason A + B does not equal C in the comparison below. Is there any trick to get the comparisons to work properly? Unidata 7.2 on Hp Unix 11+ Top of "TEST.COMP" in "RMH.MAIN", 13 lines, 263 characters. *--: P 001: A = 3176.79 002: B = 106.19 003: C = 3282.98 004: D = 920.11 005: A = A + D 006: C = C + D 007: IF (A+B) # C THEN 008: CRT '(A+B) # C? YOU LIE' 009: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C 010: END ELSE 011: CRT '(A+B) = C? YOU ROCK' 012: CRT 'A = ':A:', B = ':B:', (A+B) = ':(A+B):', C = ':C 013: END Bottom. *--: FIBR Filed "TEST.COMP" in file "RMH.MAIN" unchanged. Compiling Unibasic: /db1/ud1/PGM/RMH.MAIN/TEST.COMP in mode 'u'. compilation finished (A+B) # C? YOU LIE A = 4096.9, B = 106.19, (A+B) = 4203.09, C = 4203.09 George Hammerle Programming Dude Hubert Company LLC. 9555 Dry Fork Road Harrison, Ohio 45030 513-367-8974 zhammerle@hubertREMOVE_THIS.com This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or company to whom they are addressed. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail including all attachments from your system. Thank you ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
