Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!apple!claris!ames!lll-tis!lll-ncis!lll-lcc!pyramid!infmx!aland From: aland@infmx.UUCP (Dr. Scump) Newsgroups: comp.databases Subject: Re: Informix 4gl - no integer arithmetic??? Summary: get your story straight mostly rebuttal and flame, others may want to hit 'n' now... Message-ID: <494@infmx.UUCP> Date: 6 Oct 88 09:34:10 GMT References: <466@pan.UUCP> <410@infmx.UUCP> <468@pan.UUCP> <5876@columbia.edu> <488@pan.UUCP> Organization: Informix Software Inc., Menlo Park, CA. Lines: 109 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"