From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,FREEMAIL_FROM, INVALID_MSGID,PDS_OTHER_BAD_TLD autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public From: Joe Gamache Subject: Re: Software landmines (loops) Date: 1998/09/03 Message-ID: <35EED7D3.3CFDA8A4@iname.com>#1/1 X-Deja-AN: 387556203 Content-Transfer-Encoding: 7bit References: <902934874.2099.0.nnrp-10.c246a717@news.demon.co.uk> <6r1glm$bvh$1@nnrp1.dejanews.com> <6r9f8h$jtm$1@nnrp1.dejanews.com> <6renh8$ga7$1@nnrp1.dejanews.com> <6rf59b$2ud$1@nnrp1.dejanews.com> <6rfra4$rul$1@nnrp1.dejanews.com> <35DBDD24.D003404D@calfp.co.uk> <6sbuod$fra$1@hirame.wwa.com> <35f51e53.48044143@ <904556531.666222@miso.it.uq.edu.au> <35EAEC47.164424A7@s054.aone.net.au> <35EBBFAF.DE38C061@s054.aone.net.au> <35EC28BD.351F33DF@s054.aone.net.au> Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@mirkwood.fmr.com X-Trace: news-srv1.fmr.com 904845382 155.1.8.14 (Thu, 03 Sep 1998 13:56:22 EDT) Organization: Fidelity Investments MIME-Version: 1.0 NNTP-Posting-Date: Thu, 03 Sep 1998 13:56:22 EDT Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-03T00:00:00+00:00 List-Id: Matthew Heaney wrote: > Loryn Jenkins writes: > > > Now, someone else was kind enough to show me an even simpler way of > > doing this ... albeit marginally less efficient (and again, I don't care > > about this criteria, unless my application beforms below specification > > and my profiler shows me that this is a hot spot). > > > > equal (l,r: LIST): BOOLEAN is > > require > > l /= Void and r /= Void > > do > > from > > Result := (l.count = r.count) > > l.start; r.start > > until > > not Result or l.off > > loop > > Result := (l.item = r.item) > > l.forth; r.forth > > end > > end > > > > This, at least, loses your nesting objection. In fact, it has less > > nesting than your original example. However, it might mislead unless the > > reader was aware of this sort of idiom. (It does simplify things though; > > so I think I'll be using this style, where appropriate.) > > I like that there's less nesting, but still have a couple of issues with > it: > > 1) The decision table for the predicate still has 4 rules instead of 2. > If I follow your logic here it seems seriously flawed to me. You ignore the contribution of the 'if" statement bailout in your orginal example as two additional cases for the decision table. Otherwise, we can carry your arguement to its logical extreme and "improve" your code by ALWAYS making infinite loops and "bailing out" in the middle: function "=" (L, R : Stack_Type) return Boolean is begin if L.Top /= R.Top then return False; end if; Index : Positive := 1; while (True) loop ! is 'loop' supposed to be 'do' ?? can't recall if L.Items (Index) /= R.Items (Index) then return False; end if; if Index = L.Top then return True; ! bail out as soon as I know I can end if; Index := Index + 1; end loop; end "="; Please excuse any syntax errors. I think the above is a nightmare. Do people actually think it is an improvement? But your logic seems to say there are zero cases to consider in the decision tree for the loop predicate. Otherwise there is 4 in your original example and this example. You can not mathematically have it both ways. > 2) It still bothers me a little that once you calculate the value of > Result (the second time, when comparing items), you still do some work > after (to increment the iterators), even though the result may already > be False. > > The latter point is only a nit. It's the first point that puts a bee in > my bonnet. It may not seem like much in this example, because we're > "only" going from 2 rules to 4. But things get scary really fast when > going 4 to 8. > > This was my experience trying to decipher someone else's post, in which > a flag was added to a decision table with 4 rules, doubling the size to > 8. I wouldn't have been able to figure things out without using a > decision table. (I haven't caught on to K-maps yet, but decision tables > are my best friend.) > > BTW: Treat minimizing nesting levels seriously. Whereas Miller's limit > was 7 plus or minus 2, for a linear sequence of items, the limit is even > lower (around 3) for nested relationships. (This info I read in > Structured Design, by Constantine & Yourdon.) This bothers me also. Dr. Miller's work is often quoted in our business. Yet theproject I'm currently working on is distributed on 27 ultrasparc computers and I understand it! Am I some aberration, some wierd freak of nature capable of feats of cognition heretofore undreamed of? As further evidence, my last project consisted over well over 100 classes. I knew and understood not only each class, but their interaction with one another as well. Boy, my ego is really going now. Wait! Everyone else here understands the system on the 27 computers as well. Either this is a rare group of genius individuals or something else is going on. Perhaps it is that Miller's work regarding the "magic" number of 7 +/- 2 was on short term memory. Thus, if you are giving a pitch you don't want too many bullets, classes, boxes, or anything else on it - if you NEED your audience to remember something meaningful. But, for more intensive study the human brain's cognitive limits are often go well beyond 9. Oh no! This means I'm only normal (okay this may now be debateable....)