jw@pan.UUCP (Jamie Watson) (09/04/88)
I have just discovered, the hard way, that in Informix 4gl the following
statement, which contains only integer values, yields a most surprising
result:
main
define
i integer
let i = 630 / 100 * 60
display i
end main
Running this program produces a result of 378!!!
The 4gl manual states that all arithmetic is done in type 'decimal', which
might explain what is going on here, but then it goes on to explain that
for integer values, the specific type used is 'decimal(10,0)', which would
imply that the integer nature of the operations should be preserved. It
obviously is not. The only solution I have been able to find is to use
an intermediate variable whenever integer division is performed:
main
define
i, botch integer
let botch = 630 / 100
let i = botch * 60
display i
end main
Has anyone found a better work-around?
jwaland@infmx.UUCP (Dr. Scump) (09/07/88)
In article <466@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: > > I have just discovered, the hard way, that in Informix 4gl the following > statement, which contains only integer values, yields a most surprising > result: > > main > define > i integer > let i = 630 / 100 * 60 > display i > end main > > Running this program produces a result of 378!!! > > The 4gl manual states that all arithmetic is done in type 'decimal', which > might explain what is going on here, but then it goes on to explain that > for integer values, the specific type used is 'decimal(10,0)', which would Um, that's for the *operands*, not necessarily the *result*. See below... > imply that the integer nature of the operations should be preserved. It > jw This is consistent with the documentation. The type used for the integer *operands* is (10,0); since none of the operands had scale, no precision is lost. The scale of the operands is *not necessarily* the scale used by the result (see page 1-13R of the manual, second note). The scale used in the *result* of an equation depends on the equation; in this case, maximum scale is *22*, not 0, due to the use of division (scale is 32 - 10 + 0 - 0, using the formula on page 1-14R of the manual). Therefore, the result of the right side of the equation is 378.00000000..., which converts to integer +378 when converting the value to integer at the end. This is similar to C's promotion of types. For example, try main() { int intvar; printf ("In C, we get %d\n", intvar = (630.0 / 100 * 60)); } and you will get the exact same result (378). Informix-4GL differs from C only in that C will not promote beyond integer if no floats / doubles are used; 4GL will promote scale depending on the type of operation in an effort to retain accuracy according to the rules on page 1-14R. -- Alan S. Denney | Informix Software, Inc. | {pyramid|uunet}!infmx!aland Disclaimer: These opinions are mine alone. If I am caught or killed, the secretary will disavow any knowledge of my actions. Santos' 4th Law: "Anything worth fighting for is worth fighting *dirty* for"
jw@pan.UUCP (Jamie Watson) (09/09/88)
In article <410@infmx.UUCP> aland@infmx.UUCP (Dr. Scump) writes: >In article <466@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: >> >> let i = 630 / 100 * 60 >> >> Running this program produces a result of 378!!! > >This is similar to C's promotion of types. For example, try > > printf ("In C, we get %d\n", intvar = (630.0 / 100 * 60)); WHAT?!? Does anyone, anywhere, other than the author of this piece of filth, think that this C statement is the same as the 4gl statement above it? This simply proves my original statement - INFORMIX 4GL HAS NO INTEGER ARITHMETIC. Anyone who has any experience with any real programming language needs to be made aware of this, or they are in for the same nasty surprise that I got. I don't believe that the way to make them aware of it is to hide this fact somewhere in the bowels of a thousand or so pages of *very* poorly written and *incredibly* poorly organized documentation. >This is consistent with the documentation. Big deal. jw
andy@garfield (Andy Lowry) (09/13/88)
In article <468@pan.UUCP> jw@pan.UUCP (Jamie Watson) writes: >In article <410@infmx.UUCP> aland@infmx.UUCP (Dr. Scump) writes: >>In article <466@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: >>> >>> let i = 630 / 100 * 60 >>> >>> Running this program produces a result of 378!!! >> >>This is similar to C's promotion of types. For example, try >> >> printf ("In C, we get %d\n", intvar = (630.0 / 100 * 60)); > >WHAT?!? Does anyone, anywhere, other than the author of this piece of filth, >think that this C statement is the same as the 4gl statement above it? >... >>This is consistent with the documentation. >Big deal. >jw Is there anybody else out there who shares my sense of outrage at Jamie Watson's message here? As I see it, here's what happened: 1. Watson posted a message to the net describing some Informix 4gl behavior that he (my apologies, Jamie, if you're a woman...) found confusing and inconsistent with the documentation. 2. Dr. Scump from Informix posted a detailed explanation of what was going on along with specific references to the documentation where the arithmetic rules are defined. 3. Watson blasted Scump! I don't get it, and I sent a personal message to Watson suggesting that an apology to Scump is in order. The result: even if net etiquette did not prevent me from quoting Watson's response to my message, common rules of decency certainly do. The reason this is upsetting enough for me to post to the net is that there has been a concerted effort in past postings to get vendors to participate in this forum. One advantage of such participation is that people like Jamie Watson can often have problems with products or documentation quickly resolved, as was the case here. I haven't seen the Informix documentation and cannot comment on Watson's contention that it is poorly organized and very difficult to use. Their rules of arithmetic may also be very poorly designed. But I doubt that Dr. Scump is personally responsible in either case. His net response was, however, quick, and more than adequate in that it clearly explained the observed behavior and enabled Watson (or any other reader) to avoid similar problems in the future. I would hope that Dr. Scump also notified the people responsible for documentation at Informix that this particular item had caused confusion and should be more carefully explained (or redesigned) in future releases. In any case, I certainly hope that Jamie Watson never again is confused over anything he encounters, because I doubt that many on this net would be quick to offer him help after this episode. And I hope that Dr. Scump, his colleagues at Informix, and his peers working for other vendors will continue to participate in comp.databases and not be put off by Watson's absurd ravings. -Andy Lowry
locke@pdn.UUCP (Richard Locke) (09/13/88)
In article <5876@columbia.edu> andy@garfield.UUCP (Andy Lowry) writes: >In article <468@pan.UUCP> jw@pan.UUCP (Jamie Watson) writes: >>In article <410@infmx.UUCP> aland@infmx.UUCP (Dr. Scump) writes: >>>In article <466@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: ...[Watson asks question] ...[Dr. Scump answers Watson's question] ...[Watson posts nasty response] >Is there anybody else out there who shares my sense of outrage at >Jamie Watson's message here? Yes. The gentleman from Informix also sent me a detailed response to a question I had a few months ago. I greatly appreciated the time he took to do so. I can't fathom Watson's response. I also hope vendors are not put off by the likes of Watson. In my opinion, Watson owes all the readers of this newsgroup an apology. -- Dick Locke Paradyne Corporation {uunet,peora}!pdn!locke Mail stop LF-207 Phone: (813) 530-8241 P.O. Box 2826 Largo, FL 34649-2826
jw@pan.UUCP (Jamie Watson) (09/16/88)
My original posting on this topic was intended to point out to present and prospective users of Informix 4GL that there is no integer arithmetic in this "programming language". The followup from "Dr. Scump" at Informix did not offer a solution to my posting; it made a lame attempt to justify what they have done, and it included an extremely misleading example that was supposed to show that C does the same thing. The example specifically included a floating point number, which of course caused the entire expression to be evaluated in floating point. The reply further claimed the C is the "only major language" that does not promote integers to floats in arithmetic evaluations. Well, I can name a few "minor" languages that don't, such as Pascal, Fortran, Modula-2, and Basic. There are plenty more. If anyone is going to apologize, I think it should be "Dr. Scump", for trying to intentionally mislead the readers of this group. jw
aland@infmx.UUCP (Dr. Scump) (09/24/88)
In article <474@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: > > My original posting on this topic was intended to point out to present and > prospective users of Informix 4GL that there is no integer arithmetic in > this "programming language". The followup from "Dr. Scump" at Informix did Wrong. There is integer arithmetic. What s/he is talking about is integer *division* given the operator "/". [E3] I4GL retains remainder accuracy within an expression, just like COBOL (More on this later). (The above statement should not be taken as an endorsement of COBOL, which can prove fatal in vnews :-] :-]). > not offer a solution to my posting; it made a lame attempt to justify what > they have done, and it included an extremely misleading example that was > supposed to show that C does the same thing. The example specifically > included a floating point number, which of course caused the entire > expression to be evaluated in floating point. Wrong. [E3.5] Not floating point, *decimal*. As I pointed out in an earlier posting, this evaluation is clearly documented. > The reply further claimed the C is the "only major language" that does > not promote integers to floats in arithmetic evaluations. Well, I can Huh? > name a few "minor" languages that don't, such as Pascal, Fortran, Modula-2, > and Basic. There are plenty more. ^^^^^^ Wrong-o. [E4] Pascal has a separate "div" operator which does this. This is not the same as the "/" operator, which s/he used in the example. > If anyone is going to apologize, I think it should be "Dr. Scump", for > trying to intentionally mislead the readers of this group. > jw Is the opinion that I am "intentionally misleading the readers of this group" shared by *anyone* else? If so, I'll stop posting rather than be a detriment to the newsgroup. -- Alan S. Denney | Informix Software, Inc. | {pyramid|uunet}!infmx!aland Disclaimer: These opinions are mine alone. If I am caught or killed, the secretary will disavow any knowledge of my actions. Santos' 4th Law: "Anything worth fighting for is worth fighting *dirty* for"
aland@infmx.UUCP (Dr. Scump) (09/25/88)
In article <474@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: > ... > The reply further claimed the C is the "only major language" that does > not promote integers to floats in arithmetic evaluations. Well, I can > name a few "minor" languages that don't, such as Pascal, Fortran, Modula-2, > and Basic. There are plenty more. ^^^^^^ I just tried this in BASIC, and Mr./Ms. Watson is wrong [E6], unless Microsoft QuickBasic 4.0 differs greatly from other BASICs. The following program prints "A = 9", not "A = 5" like Jamie claims. 5 DEFINT A 10 LET A = (9 / 5) * 5 15 PRINT "A = "; A 20 END Like in Pascal, there is a *different* operator for integer division. -- Alan S. Denney | Informix Software, Inc. | {pyramid|uunet}!infmx!aland Disclaimer: These opinions are mine alone. If I am caught or killed, the secretary will disavow any knowledge of my actions. Santos' 4th Law: "Anything worth fighting for is worth fighting *dirty* for"
jw@pan.UUCP (Jamie Watson) (09/30/88)
In article <463@infmx.UUCP> aland@infmx.UUCP (Dr. Scump) writes: >In article <474@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: >> > Wrong. There is integer arithmetic. What s/he is talking about is integer > *division* given the operator "/". [E3] I4GL retains remainder accuracy > within an expression, just like COBOL (More on this later). The single most important factor that sets apart integer arithmetic is truncation in division. Other differences are a consequence of difference in precision, not of the type of variables involved. >> The example specifically >> included a floating point number, which of course caused the entire >> expression to be evaluated in floating point. > > Wrong. [E3.5] Not floating point, *decimal*. As I pointed out in an > earlier posting, this evaluation is clearly documented. My reference to "The example" was to the example in *his* followup, which was a C program, and therefore contained exactly what I said - a floating point number. If "Dr. Scump" doesn't understand the difference, it is not my problem. > Wrong-o. [E4] Pascal has a separate "div" operator which does this. > This is not the same as the "/" operator, which s/he used in the example. The point is still valid. Pascal has a means of obtaining integer division. So does Basic, C, Modula-2, and any number of other programming languages. Informix 4gl does not. I don't care what operator is used. If Informix will give me a different operator that will yield integer division, I will very happily use it. > Is the opinion that I am "intentionally misleading the readers of this > group" shared by *anyone* else? If so, I'll stop posting rather than > be a detriment to the newsgroup. Ah, now we come to the heart of the matter. I have been attacked, both publicly and privately, for being rude, inconsiderate, and unfair to both Informix in general and "Dr. Scump" in particular. I am guilty, at least in regards to "Dr. Scump"; there is some (small) chance that he was/is making a sincere effort to be helpful in his original response to my posting about integer arithmetic, and was not simply trying to cover up a serious deficiency in the Informix product. If that is the case, then I apoplogize. However, given that it is now very well established that there is in fact no integer arithmetic (or integer division, if you really feel it necessary to say it this way), and that Cobol is the only example he has been able to come up with of another language that doesn't (by the way, I'm taking his word on this, which is probably foolish, but I have judiciously avoided cobol for the past 18 years, so I don't know if it does or does not have a special operator for integer division), it looks pretty clear to me that my point is proven, and his past and present comments are excuses and attempted cover-up. Also, "Dr. Scump" now seems to be getting his jollies by numbering what he perceives as errors in my postings. As of this followup, he is up to 4, none of which have in fact been errors. Posting edited copies of my originals, in such a way as to obscure the meaning of the oringal, or claiming that something is "fixed in the current version", when in fact I have the same version and it is obviously not fixed, doesn't cut it. I didn't mean to start a war by posting about Informix problems. I have said before that I would be very happy to see that I am wrong, in any or all of these postings, because I have to use Informix 4gl in developing an application, and these are all real problems that I am finding as I go. Solutions to them would make my life a lot easier, and my work a lot better. So far, only one of my postings has been proven wrong, based on my misreading of the 4gl manual. I have already gone back and changed the programs in which that was used, and have benefitted from it. If there are others, I'm ready. jw
jw@pan.UUCP (Jamie Watson) (09/30/88)
In article <466@infmx.UUCP> aland@infmx.UUCP (Dr. Scump) writes:
<I just tried this in BASIC, and Mr./Ms. Watson is wrong [E6], unless
<Microsoft QuickBasic 4.0 differs greatly from other BASICs.
<The following program prints "A = 9", not "A = 5" like Jamie claims.
<
<10 LET A = (9 / 5) * 5
<
<Like in Pascal, there is a *different* operator for integer division.
I didn't say that it used the same operator. I said it was possible,
and it is. If you are going to insist on this assenine exercise of
numbering what you think are my errors, please stop editing my original
postings, and please make sure that they are in fact errors.
jwaland@infmx.UUCP (Dr. Scump) (10/06/88)
In article <488@pan.UUCP>, jw@pan.UUCP (Jamie Watson) writes: > > My reference to "The example" was to the example in *his* followup, which > was a C program, and therefore contained exactly what I said - a floating > point number. If "Dr. Scump" doesn't understand the difference, it is > not my problem. Sure, I "understand the difference." I took your reference to "the example" to mean *your* (4GL) example in your posting. This was a mutual misunderstanding. > > Wrong-o. [E4] Pascal has a separate "div" operator which does this. > > This is not the same as the "/" operator, which s/he used in the example. > > The point is still valid. Pascal has a means of obtaining integer division. > So does Basic, C, Modula-2, and any number of other programming languages. > Informix 4gl does not. I don't care what operator is used. If Informix > will give me a different operator that will yield integer division, I will > very happily use it. But this wasn't the point, was it? What started this whole mess was that you expressed extreme surprise that the '/' operator did precise division in your posting of September 4. You called it a "most surprising result", remember? Here it is again... >> From jw@pan.UUCP@munnari.oz Sun Sep 4 03:47:48 1988 #936 >> From: jw@pan.UUCP (Jamie Watson) >> Newsgroups: comp.databases >> Subject: Informix 4gl - no integer arithmetic??? >> >> I have just discovered, the hard way, that in Informix 4gl the following >> statement, which contains only integer values, yields a most surprising >> result: >> >> main >> define i integer >> let i = 630 / 100 * 60 >> display i >> end main >> >> Running this program produces a result of 378!!! >> (proper example of simulating integer division omitted) >> >> Has anyone found a better work-around? >> jw Then, in response to my followup, you again referred to this as a "nasty surprise": >> From jw@pan.UUCP@munnari.oz Fri Sep 9 00:37:53 1988 >> Subject: Re: Informix 4gl - no integer arithmetic??? >> Summary: Baloney >> Reply-To: jw@pan.UUCP (Jamie Watson) >> Organization: Adasoft AG, Solothurn, Switzerland ... >> Anyone who has any experience with any real programming language needs to be >> made aware of this, or they are in for the same nasty surprise that I got. >> I don't believe that the way to make them aware of it is to hide this fact >> somewhere in the bowels of a thousand or so pages of *very* poorly written >> and *incredibly* poorly organized documentation. If you want to make the case that I4GL should have a "div" operator, that's fine. But that's not at all what you said. You decried that your example did not do integer division. C and FORTRAN are the only languages that I know that do, using your syntax example. You claimed that "real" languages (specifying Pascal and BASIC) would do the same; this wasn't true for these two, and I gave examples that refuted this claim. That's all. > Also, "Dr. Scump" now seems to be getting his jollies by numbering what > he perceives as errors in my postings. As of this followup, he is up > to 4, none of which have in fact been errors. Posting edited copies of > my originals, in such a way as to obscure the meaning of the oringal, or > claiming that something is "fixed in the current version", when in fact > I have the same version and it is obviously not fixed, doesn't cut it. ***FLAME ON *** No, I am not "getting my jollies"; I am just trying to defend against your reckless disregard of the facts. You yourself admitted that the "formonly broken" problem WAS your error. Also, the DBDATE "problem" which you right here claim to be "obviously not fixed", appears to work for everybody except you (more on this in another post). As for the division precision issue, this was due to your own failure to read the appropriate section of the documentation. Finally, as for timing problems in function keys: this is most likely due to keystroke timeouts in your UNIX system. This normally doesn't happen if you are using locally attached terminals unless your system has severe i/o bottlenecks. It won't happen at all on terminals which use control sequences (rather than ESC sequences) for arrow keys. If the same timeout problem occurs with vi, how does that make 4GL "broken"? (the simple fact that it adversely affects users *does* make it a problem, but not worthy of your criticisms of 4GL). No, I get no joy from these flame exchanges. I'm sick of it. But as long as you insist on calling everything "broken" (and as long as you attack me directly and make snide remarks) when the real story is that you don't understand something or don't like the design methodology, postings like this will result. ***FLAME OFF *** My apologies to other net.users. I hope this B.S. ends soon. -- Alan S. Denney | Informix Software, Inc. | {pyramid|uunet}!infmx!aland Disclaimer: These opinions are mine alone. If I am caught or killed, the secretary will disavow any knowledge of my actions. Santos' 4th Law: "Anything worth fighting for is worth fighting *dirty* for"