RE: [U2] Why does the IF statement think these values are different?
Hi All, I thought I would send out the solution to this problem. The IF statement took these values to be different although they appear equal. We used string math as was suggested to us and that worked. Our Vendor (Columbia Ultimate) escalated to IBM, and the suggestion was to use $OPTIONS COMP.PRECISION. We inserted this at the start of the subroutine, and the IF statement handled the comparison as one would expect. CUSTOMCALC: 451: PRINT INTREC:' ':PRNREC:' # ':INTPAY:' ':PRNPAY :: S 24016.35 978.56 # 24016.35 978.56 IBM's response was: IBM response This is a case of 'what you see' isn't what you get. UniVerse is applying a PRECISION to the values on display. Hence, UniVerse might display for example 1. but the actual value stored could be 1.01. In the example (in the case), the values are stored internally as 'float' data types. The comparison using equals or non-equals (=/#) is based upon what UniVerse considers a zero. That is determined by the setting for WIDE0 in the uvconfig. For example would .0001 (+ or -) be considered a zero? While UniVerse includes several features (WIDE0, $options STRING.MATH, VEC.MATH, COMP.PRECISION) the reason the routines fail in the relational test is not due to UniVerse but do to how floating values are stored by the hardware. A failure in a UniVerse basic program can be reproduced within a c-program as well. One simply needs to do the same arithmatic operations in the same order and the comparison test should be the same. You can change WIDE0 which will for the entire system alter how comparisons (=, , =, , =, #, etc) are handled. Or, alter the logic for a specific program by adding '$OPTIONS' to the program. Can this problem be worked down to a smaller program, ie. retrieve the fields indicated and do the math, rather than having all of the other program logic included? End IBM response Regards, Steve --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Why does the IF statement think these values are different?
From: Steve Ferries I thought I would send out the solution to this problem...[snip] I, for one, truly appreciate it when people post back their Real World solution to a problem posed to the list. This list has great gurus, and I am so grateful for their explanations, suggestions, advice for best practice, workarounds, etc.. But after the pontification, I like to know which bits ended up working out pragmatically in the field. Thanks, Steve! Chuck Stevenson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Why does the IF statement think these values are different?
Hi, Don't know if you have already checked but what is your wide zero set to in uvconfig? It is a hex number. This is used by universe to decide when two number are close enough to be regarded as the same. You can make the difference bigger so that your IF statement works how you would expect. Another solution is to use string maths...look at SADD,SDIV,SMUL SSUB.. Hopes this helps Les Sherlock Hewkin Senior Developer Core Systems - 9951 01604 592289 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Baker Hughes Sent: 07 November 2006 22:17 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Why does the IF statement think these values are different? Steve, a couple suggestions: a) It shouldn't make a lick of difference, but enclose the math in parans, just to insure the precedence you desire in the operation.. IF (INTREC+PRNREC) # (INTPAY+PRNPAY) THEN b) if that doesn't change things, try something like: WHATSUP = ABS((INTREC+PRNREC) - (INTPAY+PRNPAY)) IF WHATSUP 0 THEN ERRMSG='ACCT/CALCULATOR MISMATCH' HTH, -Baker HI All, I don't understand why the IF statement THEN clause is executed in the following code: CUSTOMCALC: 447: IF INTREC+PRNREC#INTPAY+PRNPAY THEN :: S CUSTOMCALC: 448: ERRMSG='ACCT/CALCULATOR MISMATCH: ':(INTREC+PRNREC)'R2':'/':(INTPAY+PRNPAY)'R2' :: INTREC/ NUMBER: 24016.35 :: PRNREC/ NUMBER: 978.56 :: INTPAY/ NUMBER: 24016.35 :: PRNPAY/ NUMBER: 978.56 :: ERRMSG/ STRING: T r L=42 `ACCT/CALCULATOR MISMATCH: 24994.91/24994.91' --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ html head meta http-equiv=Content-type content=text/html; charset=UTF-8 /head body P style=MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0ptSPAN style=FONT-SIZE: 8.2pt; FONT-FAMILY: 'MS Sans Serif'This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message. /SPAN/P P style=MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0ptSPAN style=FONT-SIZE: 8.2pt; FONT-FAMILY: 'MS Sans Serif'This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins plc or its subsidiaries (Travis Perkins). Agreements binding Travis Perkins may not be concluded by means of e-mail communication. /SPAN/P P style=MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0ptSPAN style=FONT-SIZE: 8.2pt; FONT-FAMILY: 'MS Sans Serif'E-mail transmissions are not secure and Travis Perkins accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins accepts no liability for infection and recommends that you scan this e-mail and any attachments. /SPAN/P P style=MARGIN-TOP: 0pt; MARGIN-BOTTOM: 0ptSPAN style=FONT-SIZE: 8.2pt; FONT-FAMILY: 'MS Sans Serif'Part of Travis Perkins plc. Registered Office: Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG. /SPAN/P /BODY /HTML --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Why does the IF statement think these values are different?
HI All, Try the ABS() function No, this had no effect. Don't know if you have already checked but what is your wide zero set to in uvconfig? It is a hex number. WIDE0 0x3dc0 I have called our vendor for support on this, but their recommendation is leave it alone, but grudgingly they will find out what it could be set to. Another solution is to use string maths...look at SADD,SDIV,SMUL SSUB.. I tried this: CUSTOMCALC: 451: PRINT INTREC:' ':PRNREC:' # ':INTPAY:' ':PRNPAY :: S 24016.35 978.56 # 24016.35 978.56 CUSTOMCALC: 452: IF SADD(INTREC,PRNREC)# SADD(INTPAY,PRNPAY) THEN :: S CUSTOMCALC: 458: IF PFLAG THEN The above worked. I would still like to 'see' what the system thinks is the difference when performing INTREC+PRNREC#INTPAY+PRNPAY, and why I can't make it work with type NUMBERS instead of type STRING. This code has been in production for 15 years, and this is the first time I have had to look at this. I will wait to see what the vendor says about WIDE0. Thanks for all the help and suggestions. Steve --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Why does the IF statement think these values are different?
I haven't been following this so someone may have suggested this already. Try adding zero to both sides of the comparison to force both to numbers. Ross -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ferries Sent: Wednesday, November 08, 2006 7:17 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Why does the IF statement think these values are different? HI All, Try the ABS() function No, this had no effect. Don't know if you have already checked but what is your wide zero set to in uvconfig? It is a hex number. WIDE0 0x3dc0 I have called our vendor for support on this, but their recommendation is leave it alone, but grudgingly they will find out what it could be set to. Another solution is to use string maths...look at SADD,SDIV,SMUL SSUB.. I tried this: CUSTOMCALC: 451: PRINT INTREC:' ':PRNREC:' # ':INTPAY:' ':PRNPAY :: S 24016.35 978.56 # 24016.35 978.56 CUSTOMCALC: 452: IF SADD(INTREC,PRNREC)# SADD(INTPAY,PRNPAY) THEN :: S CUSTOMCALC: 458: IF PFLAG THEN The above worked. I would still like to 'see' what the system thinks is the difference when performing INTREC+PRNREC#INTPAY+PRNPAY, and why I can't make it work with type NUMBERS instead of type STRING. This code has been in production for 15 years, and this is the first time I have had to look at this. I will wait to see what the vendor says about WIDE0. Thanks for all the help and suggestions. Steve --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Why does the IF statement think these values are different?
We hit the same problem a couple of years back. We had code that had worked for 15+ years on various versions of Pick and appeared to be working for a couple of years in UniData. Nothing fancy, no division or multiplication, just a report in dollars and cents that we had an if statement to suppress lines if a couple of the columns added to 0. Someone noticed that there were 0 lines showing on the report. No matter how we looked at the numbers we couldn't tell what was wrong with them. It had to do with the way UniData stored the numbers internally. There wasn't a way we could see the difference. It did something like stored 3.41 internally as 3.40 so that this program: A=103.40 B=0.01 C=100 D=3.41 IF (A+B)=(C+D) THEN PRINT (A+B):=:(C+D) IF (A+B)(C+D) THEN PRINT (A+B)::(C+D) IF (A+B)(C+D) THEN PRINT (A+B)::(C+D) Showed 103.41103.41. IBM told us to change the FLOAT.PRECISION to whatever worked for us. Good question. The default appears to have been working - what might break if we change it? It always seemed to me to be way too similar to the Pentium bug that caused Intel to recall thousands of processors Since we had no control over the data we started to change our calculations so that we were always working with integers. That seems to have solved the problem. Hth Colin Alfke Calgary Canada -Original Message- From: Steve Ferries HI All, The above worked. I would still like to 'see' what the system thinks is the difference when performing INTREC+PRNREC#INTPAY+PRNPAY, and why I can't make it work with type NUMBERS instead of type STRING. This code has been in production for 15 years, and this is the first time I have had to look at this. I will wait to see what the vendor says about WIDE0. Thanks for all the help and suggestions. Steve --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Why does the IF statement think these values are different?
Goo'day, At 10:16 08/11/06 -0500, you wrote: Don't know if you have already checked but what is your wide zero set to in uvconfig? It is a hex number. WIDE0 0x3dc0 I have called our vendor for support on this, but their recommendation is leave it alone, but grudgingly they will find out what it could be set to. We had inordinate problems with x not being equal to x within our software from about UV 9.4.something on Winblows NT... Got to the stage where we changed WideZero to 0x3eb0 on every NT that went out the door.. No more problems. Actually, I vaguely remember a UV discourse (Appendix C comes to mind) in UV documentation somewhere... so it's not going against the grain.. T'was pointed out to me much later, as far as WideZero was concerned, that ICONV/OCONV was much more preferable to multiplying and dividing by 100 (Just a thought...) Regards, Bruce Nichol Talon Computer Services ALBURYNSW 2640 Australia http://www.taloncs.com.au Tel: +61 (0)411149636 Fax: +61 (0)260232119 If it ain't broke, fix it till it is! -- No virus found in this outgoing message. Checked by AVG. Version: 7.5.431 / Virus Database: 268.14.0/524 - Release Date: 08/11/06 13:40 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Why does the IF statement think these values are different?
Steve, a couple suggestions: a) It shouldn't make a lick of difference, but enclose the math in parans, just to insure the precedence you desire in the operation.. IF (INTREC+PRNREC) # (INTPAY+PRNPAY) THEN b) if that doesn't change things, try something like: WHATSUP = ABS((INTREC+PRNREC) - (INTPAY+PRNPAY)) IF WHATSUP 0 THEN ERRMSG='ACCT/CALCULATOR MISMATCH' HTH, -Baker HI All, I don't understand why the IF statement THEN clause is executed in the following code: CUSTOMCALC: 447: IF INTREC+PRNREC#INTPAY+PRNPAY THEN :: S CUSTOMCALC: 448: ERRMSG='ACCT/CALCULATOR MISMATCH: ':(INTREC+PRNREC)'R2':'/':(INTPAY+PRNPAY)'R2' :: INTREC/ NUMBER: 24016.35 :: PRNREC/ NUMBER: 978.56 :: INTPAY/ NUMBER: 24016.35 :: PRNPAY/ NUMBER: 978.56 :: ERRMSG/ STRING: T r L=42 `ACCT/CALCULATOR MISMATCH: 24994.91/24994.91' --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Why does the IF statement think these values are different?
Hi I've copied your code as you've provided, and used the same numbers that you have provided, and my IF statement behaves properly and does not create an ERRMSG string. Is there perhaps some system setting that could be causing this? I certainly do not see any errors in your logic... Pete -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ferries Sent: Monday, November 06, 2006 10:14 AM To: u2-users@listserver.u2ug.org Subject: [U2] Why does the IF statement think these values are different? HI All, I don't understand why the IF statement THEN clause is executed in the following code: CUSTOMCALC: 447: IF INTREC+PRNREC#INTPAY+PRNPAY THEN :: S CUSTOMCALC: 448: ERRMSG='ACCT/CALCULATOR MISMATCH: ':(INTREC+PRNREC)'R2':'/':(INTPAY+PRNPAY)'R2' :: INTREC/ NUMBER: 24016.35 :: PRNREC/ NUMBER: 978.56 :: INTPAY/ NUMBER: 24016.35 :: PRNPAY/ NUMBER: 978.56 :: ERRMSG/ STRING: T r L=42 `ACCT/CALCULATOR MISMATCH: 24994.91/24994.91' To my tired eyes, they are equal and we should not take the THEN. What am I missing here? Thanks for your help! Steve Steve Ferries Vice President, Information Technologies Total Credit Recovery Limited 416 774 4250 [EMAIL PROTECTED] Note: This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier ilectronique est confidentiel et protigi. L'expiditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) disigni(s) est interdite. Si vous recevez ce courrier ilectronique par erreur, veuillez m'en aviser immidiatement, par retour de courrier ilectronique ou par un autre moyen. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Why does the IF statement think these values are different?
I would remove the 'R2' from the err display so you can see the complete values. Tom Dodds [EMAIL PROTECTED] 708-234-9608 Office 630-235-2975 Cell -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ferries Sent: Monday, November 06, 2006 9:14 AM To: u2-users@listserver.u2ug.org Subject: [U2] Why does the IF statement think these values are different? HI All, I don't understand why the IF statement THEN clause is executed in the following code: CUSTOMCALC: 447: IF INTREC+PRNREC#INTPAY+PRNPAY THEN :: S CUSTOMCALC: 448: ERRMSG='ACCT/CALCULATOR MISMATCH: ':(INTREC+PRNREC)'R2':'/':(INTPAY+PRNPAY)'R2' :: INTREC/ NUMBER: 24016.35 :: PRNREC/ NUMBER: 978.56 :: INTPAY/ NUMBER: 24016.35 :: PRNPAY/ NUMBER: 978.56 :: ERRMSG/ STRING: T r L=42 `ACCT/CALCULATOR MISMATCH: 24994.91/24994.91' To my tired eyes, they are equal and we should not take the THEN. What am I missing here? Thanks for your help! Steve Steve Ferries Vice President, Information Technologies Total Credit Recovery Limited 416 774 4250 [EMAIL PROTECTED] Note: This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier ilectronique est confidentiel et protigi. L'expiditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) disigni(s) est interdite. Si vous recevez ce courrier ilectronique par erreur, veuillez m'en aviser immidiatement, par retour de courrier ilectronique ou par un autre moyen. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Why does the IF statement think these values are different?
Welcome to the wonderful world of floating point mathematics (or is it maths?). If you're using UD you can look at FLOAT.PRECISION; However, your best bet is to compare remove the decimals from the comparison (note *100 won't work). Basically what happens is the number is being represented internally with a lot of decimals that I've never been able to find a way to see that change the EQ comparison. These appear to be dollar values - you have to work in cents for it to make sense (Sorry couldn't resist). Hth Colin Alfke Calgary Canada -Original Message- From: Steve Ferries HI All, I don't understand why the IF statement THEN clause is executed in the following code: CUSTOMCALC: 447: IF INTREC+PRNREC#INTPAY+PRNPAY THEN :: S CUSTOMCALC: 448: ERRMSG='ACCT/CALCULATOR MISMATCH: ':(INTREC+PRNREC)'R2':'/':(INTPAY+PRNPAY)'R2' :: INTREC/ NUMBER: 24016.35 :: PRNREC/ NUMBER: 978.56 :: INTPAY/ NUMBER: 24016.35 :: PRNPAY/ NUMBER: 978.56 :: ERRMSG/ STRING: T r L=42 `ACCT/CALCULATOR MISMATCH: 24994.91/24994.91' To my tired eyes, they are equal and we should not take the THEN. What am I missing here? Thanks for your help! Steve --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Why does the IF statement think these values are different?
Steve, Proposing that the difference is in the number of digits stored verses the number of digits displayed. Maybe the number of digits store is 5 after the decimal verses the 2 you are rounding to. The difference displayed may be due to the rounding that is occurring on each number BEFORE the divide occurs. Intrigued, Steve Stephen M. O'Neal Lab Services Sales for U2 IBM SWG Information Management Lab Services Steve Ferries [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/06/2006 08:14 AM Please respond to u2-users@listserver.u2ug.org To u2-users@listserver.u2ug.org cc Subject [U2] Why does the IF statement think these values are different? HI All, I don't understand why the IF statement THEN clause is executed in the following code: CUSTOMCALC: 447: IF INTREC+PRNREC#INTPAY+PRNPAY THEN :: S CUSTOMCALC: 448: ERRMSG='ACCT/CALCULATOR MISMATCH: ':(INTREC+PRNREC)'R2':'/':(INTPAY+PRNPAY)'R2' :: INTREC/ NUMBER: 24016.35 :: PRNREC/ NUMBER: 978.56 :: INTPAY/ NUMBER: 24016.35 :: PRNPAY/ NUMBER: 978.56 :: ERRMSG/ STRING: T r L=42 `ACCT/CALCULATOR MISMATCH: 24994.91/24994.91' To my tired eyes, they are equal and we should not take the THEN. What am I missing here? Thanks for your help! Steve Steve Ferries Vice President, Information Technologies Total Credit Recovery Limited 416 774 4250 [EMAIL PROTECTED] Note: This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier ilectronique est confidentiel et protigi. L'expiditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) disigni(s) est interdite. Si vous recevez ce courrier ilectronique par erreur, veuillez m'en aviser immidiatement, par retour de courrier ilectronique ou par un autre moyen. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Why does the IF statement think these values are different?
You don't indicate whether this is Unidata or Universe or the flavor you are running in. However one suggestion I can make is to enclose your calculations in parenthesis to insure that operator precedence is not your problem. IF (INTREC+PRNREC) # (INTPAY+PRNPAY) THEN Rich Taylor | Senior Programmer/Analyst| VERTIS COMMUNICATIONS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.454.8392 [EMAIL PROTECTED] | http://www.vertisinc.com Vertis Communications - Partnering with clients to solve the most complex, time-sensitive marketing challenges through consulting, creative, research, direct, media, technology, and production services. The more they complicate the plumbing the easier it is to stop up the drain - Montgomery Scott NCC-1701 __ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Ferries [EMAIL PROTECTED] Sent: Monday, November 06, 2006 10:14 AM To: u2-users@listserver.u2ug.org Subject: [U2] Why does the IF statement think these values are different? HI All, I don't understand why the IF statement THEN clause is executed in the following code: CUSTOMCALC: 447: IF INTREC+PRNREC#INTPAY+PRNPAY THEN :: S CUSTOMCALC: 448: ERRMSG='ACCT/CALCULATOR MISMATCH: ':(INTREC+PRNREC)'R2':'/':(INTPAY+PRNPAY)'R2' :: INTREC/ NUMBER: 24016.35 :: PRNREC/ NUMBER: 978.56 :: INTPAY/ NUMBER: 24016.35 :: PRNPAY/ NUMBER: 978.56 :: ERRMSG/ STRING: T r L=42 `ACCT/CALCULATOR MISMATCH: 24994.91/24994.91' To my tired eyes, they are equal and we should not take the THEN. What am I missing here? Thanks for your help! Steve Steve Ferries Vice President, Information Technologies Total Credit Recovery Limited 416 774 4250 [EMAIL PROTECTED] Note: This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier ilectronique est confidentiel et protigi. L'expiditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) disigni(s) est interdite. Si vous recevez ce courrier ilectronique par erreur, veuillez m'en aviser immidiatement, par retour de courrier ilectronique ou par un autre moyen. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
