Re: Cobol Linear search Vs Perfrom Until

docdwarf_at_panix.com
Date: 07/17/04 

Date: 17 Jul 2004 09:53:48 -0400

In article <rkhgf01hkvc8amalakdl0p1ba7o2u878eq@4ax.com>,
Glenn Someone <dontspamme@whydoyouneedmyaddressspammers.com> wrote:
>Why should it? It's breaking some mold you were taught is it not?

Mr Stevens states that the Standard requires 'no particular result' and
that is what might make him uncomfortable; what makes me uncomfortable was
stated as 'If your search returned the first occurrence of the key then -1
would bring you into another key's data and if the search returned the
last a +1 would do the same; it seems to me that you'd have to do both -1
and +1 to get the full range... and all this peeking and poking about,
above and below, makes me... uncomfortable.'

This is not a mold, this is not a truism, this is, I would say, something
that I would not like to inflict on another programmer - no matter *what*
level of experience - at a 2:am fix.

>Unfortunately, people that have heard stuff like this are people that
>will take this binary search and then recode it into a sequential one
>when more understanding and thought is required than just reciting a
>rote statement heard once upon a time in a classroom.

I don't understand this... my suggestions, in a previous posting, did not
include changing a binary search into a sequential one.

>
>If it helps to put your mind at ease, please study what a binary
>search does. The only requirement of a binary search to make it
>perform successfully is that the data are sorted. Only requirement.
>If you have duplicate data, it will locate the first key item
>encountered by the algorithm.

I am not sure I understand this. If you have a table with keys:

(row 1) AAA
(row 2) AAA
(row 3) BBB
(row 4) BBB
(row 5) BBB
(row 6) CCC
(row 7) CCC

... are you saying that given a key of AAA a binary search will always
return the (row 1) occurrence of AAA, that given a key of CCC you will
always return (row 6) CCC? This would seem to contradict Mr Steven's
assertion about the Standard.

>Yes the particular ordered key item you
>arrive upon is unpredictable, but that doesn't make the algorithm
>unusable. This is all that is being asked of the search in this case.
>The only expectation out of the binary search is to locate A key item.
>Nothing more. Then it is the programmer's job to locate all the
>entries, which should be a very simple task.

As mentioned earlier in my reply to Mr Fonesca, this locating of all
entries requires, by my understanding of his method, peeking about, higher
and lower, in a fashion which makes me... uncomfortable.

>
>It is unfortunate that people carry these silly "truisms" around that
>were only devised to make the lives of programming instructors easier
>(I could catalog a ton of them).

I would say that it is less fortunate when one takes a tool designed for a
particular task and attempts to use it for a different task. A SEARCH ALL
is designed to return an unique entry from a range of uniquely ordered
keys; what it is being asked to do, here, is return... an entry, in no
predictable sequence, from a series of possibly duplicated keys. That it
can be done is not being argued... just like it is not argued that one can
use a torque-wrench as a hammer to drive nails.

>In fact, I've heard the arguments in
>the quote dozens of times. However, it is a wiser venture to learn
>the mechanics of all these things. Unfortunately for instructors,
>though, it doesn't make their job easier so they use these "truisms".

How about this for a 'truism' to make things easier:

'Do not implement into Prod any code which cannot be debugged by a typical
2-year programmer at 2:am.'

>Unfortunately for their students, though, it enables them to not learn
>everything they need to know and closes off their minds to learning
>more.

Unfortunately for the next programmer there are coders who try to use
constructs in fashions for which they were not designed; just because one
can refer to an entire input record in terms of reference modification is
no reason to do so instead of coding an intelligible FD.

>
>Yes the position you arrive upon is unpredictable, but that doesn't
>make the algorithm unpredictable.

This does not appear to make sense. If the algorithm is designed to
return a particular row in a series of ordered and unique keys and the
algorithm now returns an unpredictable row in a series of ordered and
non-unique keys then how is it predictable?

>It also doesn't justify throwing
>out the baby with the bath water and scrapping a superior algorithm
>for one that is not.

It justifies careful design... and re-design when the system changes to a
point where the original design is no longer applicable. In the original
instance the system was designed to use a binary search against a large
table of ordered and unique keys; my guess is that some corner-office
idiot said 'All ya gotta do is make duplicate entries in the table, that
can't be too hard'... and the rest is as is seen here.

DD

>
>On Fri, 16 Jul 2004 11:55:29 -0700, "Chuck Stevens"
><charles.stevens@unisys.com> wrote:
>
>><docdwarf@panix.com> wrote in message news:cd95fu$8vk$1@panix5.panix.com...
>>
>>> Hmmmmm... Mr Fonesca, this approach makes me... uncomfortable. As I
>>> recall it - and my memory is, admittedly, porous - a SEARCH ALL against a
>>> table with duplicate entries will return a result for a duplicate key
>>> whose position is unpredictable; if you have five duplicate entries the
>>> position returned could be for any of them.
>>
>>It makes me even more uncomfortable. It may be true in some implementations
>>that a SEARCH ALL will give you one of the duplicates in the table, but the
>>COBOL standard goes to some pains not to require *any* particular result,
>>and I would certainly argue against expecting such a result in general.
>>
>>The results of a SEARCH ALL are preictable *only when* the data matches the
>>KEY clause and there are no duplicates. If either of these criteria is not
>>met, *all bets are off* in terms of where you land in the table when you get
>>a WHEN hit, and whether or not you get a WHEN hit on a table entry that is
>>present (whether the particular key is a duplicate or not).
>>
>> -Chuck Stevens

Relevant Pages