Re: Cobol Linear search Vs Perfrom Until

From: William M. Klein (wmklein_at_nospam.netcom.com)
Date: 07/17/04 

Date: Sat, 17 Jul 2004 03:39:46 GMT

I don't know of anyone (whom I necessarily believe) who has stated in this
thread that the results are unpredictable for a table with sorted, non-duplicate
keys, in a CURRENTLY supported compiler. There may (or may not) have been some
in the past with problems. There may be people who haven't tried it recently -
because they ONCE heard there was a problem.

As far as the definition of SEARCH ALL, any implementor's definition may well
use the term "binary search" and for that implementation, it probably
(certainly?) is.

However, there have been vendors (and I think - but am not certain - that there
still are) who use "random sampling" and hashing routines for SEARCH ALL. Given
some information (that may or may not be provided by external or internal
information), such a routine might well be significantly FASTER than a binary
search - again for some tables.

As far as,

" With INSPECT I would go to reason 3) The results of the statement are not
100% predictable in any event. By this I mean if I were to produce a number of
questions listing INSPECT statements and data types, and asking for results of
the INSPECT statement, most people could not answer all of them correctly."

goes, it certainly sounds like you have worked where insufficient training was
available. If you are a contractor, this may be WHY those sites need
contractors.

I will certainly be happy to admit that when I have tried doing a VERY complex
INSPECT statement, I have (on occasion) needed to run some tests to make certain
that it was doing what I wanted it to do. However, I (personally) have never
seen an INSPECT statement that worked correctly on one currently supported
compiler NOT work correctly on another - unless one of the two had a compiler
bug - that the vendor was willing to fix. 

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Glenn Someone" <dontspamme@whydoyouneedmyaddressspammers.com> wrote in message
news:v66hf09jf5f6c4q8u5li7hnnolfh3i05c5@4ax.com...
> IF...that's the point.  The rules are not set out clearly by the
> standard and are inconsistent across compilers and platforms.  That
> much has been stated within this thread.
>
> And that's funny.  Every book and instructor I've heard and read has
> stated that SEARCH ALL = binary search.  Care to enlighten us on what
> the exact method is used if it is not the binary search?  If it is the
> binary search, then the standard is flawed because the binary search
> does NOT require all table keys to be unique.
>
> And I'm the type of programmer to avoid as any headaches as possible.
> In my experience, SEARCH and INSPECT are both pure headache generators
> for two reasons: 1) They are not well defined and consistent across
> platforms. and 2) They are hard-wired procedures and one must accept
> and program around the actions one interprets them to perform, no
> matter how cryptic they are, if one chooses to use them.
>
> With INSPECT I would go to reason 3) The results of the statement are
> not 100% predictable in any event.  By this I mean if I were to
> produce a number of questions listing INSPECT statements and data
> types, and asking for results of the INSPECT statement, most people
> could not answer all of them correctly.  In fact, I've found when I've
> used rudimentary INSPECT statements, I've had to educate every person
> that came in contact with that program about it.
>
> I think all programs should be simple, elegant, and fast.
>
> On Fri, 16 Jul 2004 23:14:02 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
> >SEARCH ALL is *well defined* and portable and predictable *IF* you follow the
> >well documented rules.
> >
> >If you have a table that has "unique" key values, then using SEARCH ALL will
> >*find* the expected entry and branch to AT END if there is no match.
> >
> >Although SEARCH ALL is definitely NOT defined as a "binary search" (and is
not
> >implemented as such in all current or past COBOL compilers)
>
> >You can avoid using SEARCH ALL (or even SEARCH) and INSPECT if you don't have
> >the time to learn and understand the WELL documented rules, but I certainly
> >would not recommend that to others.
> >
> >Learn when the Standard COBOL statements are and are not well-defined, then
use
> >the "best statement" for the programming task ahead of you (is my personal
> >suggestion).

Relevant Pages

  • Re: Performance in perform loops
    ... We work on a IBM mainframe system, ... The COBOL Compiler is the LE370 from IBM. ... a binary search or such intelligent algorithms. ...
    (comp.lang.cobol)
  • Re: code optimization in embedded systems
    ... use binary search to jump to the destination associated with the ... optimizations are done (in a retargetable compiler, ... without knowing the details of the target. ... have 20+ non-dense cases it is pretty obvious that linear search ...
    (comp.arch.embedded)
  • Re: Handling 5000 different functionalities - Optimised way in C
    ... the jump table that's typically used to implement a switch statement. ... Perhaps that's not technically a jump table, but AFAIK it's the closest thing* one can implement in C, therefore the name is descriptive enough. ... I agree that the compiler _could_ generate something faster, by jumping to code inside the same function instead of calling another function, but that shouldn't be a noticeable difference. ... that assumes the table is sorted, which may not always be true, my first attempt was obviously wrong and I decided getting the point across was more important than figuring out how to code a binary search on a non-power-of-two-sized array, and a binary search may have a larger I-cache footprint, bomb the branch predictor, and/or confuse the data prefetcher.) ...
    (comp.lang.c)
  • Re: Dictionary Implementation
    ... If you don't expect to have more than ten keys, ... deletion for an array is very small with that few keys. ... keys in order for binary search; ... A bounded sequential search loop unrolls nicely in the ...
    (comp.programming)
  • Re: Cobol Linear search Vs Perfrom Until
    ... SEARCH ALL doesn't cut it, provide a binary search, it's not that hard ... >keys; what it is being asked to do, here, is return... ... >point where the original design is no longer applicable. ... a good example of poor program design if I ever ...
    (comp.lang.cobol)