Cobol Linear search Vs Perfrom Until
Aru
Until
My isssue is -
I have a cobol program which was changed from Binary search to to
Perform Until to handle and process muliple occurances of search key.
This is a requirement that I will have multiple occurances for the
search key.
After the change my program performance deteriorate, which is, very
well expected, but the magnitude is 12 to 13 times more. Earlier, I
had my data processed in 10 CPU minutes and now it takes about 130 CPU
minutes.
Any suggestion. Please help
Thanks
Aru
Glenn Someone
there likely for a very good reason. Is this data sorted now? I
assume it was before this programming change? If so, you would likely
find all your other occurrences in close proximity to the one that the
binary search finds. I would use that in writing this instead of
going to an infinitely worse algorithm. Unfortunately, it's not too
hard to find cases where people make poor logical choices in changing
programs - nothing surprising really since most people hired by
business in my experience seems to not have the proper training in
program design.
COBOL linear search is no different than PERFORM UNTIL performance
wise. The same thing basically happens. My suggestion is to undo the
damage of this change and then write something that will find all your
occurrences.
Frederico Fonseca
I don't know which is faster, but I think it will depend on the
compiler vendor/version.
So for a suggestion
For the times I had duplicate keys on a table what I have done is a
combination of binary search as a first step, and then a perform
varying by -1 to get the first occurrence.
e.g.
(I had the binary search coded manually, but I think the search all
will also work).
search all
when blabla
set found to true.
end search
if found
perform varying index from index by -1
until index < 1
or var(index) not = search-key
continue
end-perform
index now contains the first occurrence of search-key
end-if
In some cases I would also do a perform varying +1 to get the last
occurrence.
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
docd...@panix.com
Aru <aru...@mailcity.com> wrote:
>Does Cobol linear search provides better performance against Perform
>Until
Not in my experience, no; from what I have seen their performances (on an
IBM mainframe platform) are about the same.
>My isssue is -
>I have a cobol program which was changed from Binary search to to
>Perform Until to handle and process muliple occurances of search key.
>This is a requirement that I will have multiple occurances for the
>search key.
Gah... this sounds like a classic 'all ya gotta do it' solution, something
that someone tossed off without any idea of what is going on during
processing.
>
>After the change my program performance deteriorate, which is, very
>well expected, but the magnitude is 12 to 13 times more. Earlier, I
>had my data processed in 10 CPU minutes and now it takes about 130 CPU
>minutes.
>
>Any suggestion. Please help
First suggestion... take up a hoby to keep you occupied during the
now-longer run times... knitting or painting, perhaps.
Second suggestion... when you have multiple occurrences of a key in the
table there has to be something to tell you whether to take the first or
the second or the third; restructure the table to include this unique
identified in the index and go back to a SEARCH ALL.
Third suggestion... break up the table. The first version of it will
contain all the unique keys, the second will contain only the duplicate
key entries. SEARCH ALL against the first, SEARCH/PERFORM UNTIL against
the second. (This method is based on the assumption that there will be an
overwhelmingly larger number of unique entries in the first table; for
example, the first table has 40,000 unique entries, out of which 3,000 or
so have, say, five duplicates each. SEARCH ALL will satisfy 37,000
possibilities and the remainder will have to go against the second table;
you'll need to add a flag to the first to tell the code whether a SEARCH
against the second is needed.)
DD
docd...@panix.com
Frederico Fonseca <real-email-...@email.com> wrote:
[snip]
>search all
>when blabla
> set found to true.
>end search
>
>if found
> perform varying index from index by -1
> until index < 1
> or var(index) not = search-key
> continue
> end-perform
> index now contains the first occurrence of search-key
>end-if
>
>In some cases I would also do a perform varying +1 to get the last
>occurrence.
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. 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.
But hey... what's a programmer's comfort when compared to the simplicity
of an 'all ya gotta do is' solution?
DD
Chuck Stevens
<docd...@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
Frederico Fonseca
DD,
as I mentioned on my post
-----
(I had the binary search coded manually, but I think the search all
will also work).
----
I start using this on tables that had over 30000 entries, and as they
had duplicates I was using a binary search (manually coded), and then
two performs afterwards to get the lower and upper range.
Never tried the Search All on this case so I'm not sure if it does.
And the real code catters for change of key, and holds the correct
index.
I have also use the same construct on some VB programs on arrays with
100000+ entries. Works very well.
>
>But hey... what's a programmer's comfort when compared to the simplicity
>of an 'all ya gotta do is' solution?
>
>DD
Frederico Fonseca
JerryMouse
How big is the table you're searching, how many times are you searching it?
Unless the table is HUGE (tens of thousands of entries) or you're searching
it millions of times, it could be there's another flaw in the program. To
increment an index and do a compare takes nanoseconds; millions of them is
measured in a few seconds, not a hundred minutes.
A SEARCH on a 1000-item table does about 10 compares plus attendant
computations. A SEARCH ALL (or PERFORM UNTIL) does, on average, 500. The
time difference between 10 and 500 is negligible.
Glenn Someone
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.
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. 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.
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). 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".
Unfortunately for their students, though, it enables them to not learn
everything they need to know and closes off their minds to learning
more.
Yes the position you arrive upon is unpredictable, but that doesn't
make the algorithm unpredictable. It also doesn't justify throwing
out the baby with the bath water and scrapping a superior algorithm
for one that is not.
Frederico Fonseca
wrote:
I think you meant
A SEARCH ALL on a 1000-item table does about 10 compares plus
attendant computations. A SEARCH (or PERFORM UNTIL) does, on average,
500. The time difference between 10 and 500 is negligible.
>
Frederico Fonseca
William M. Klein
news:rkhgf01hkvc8amala...@4ax.com...
> Why should it? <snip>
> Yes the position you arrive upon is unpredictable, but that doesn't
> make the algorithm unpredictable. It also doesn't justify throwing
> out the baby with the bath water and scrapping a superior algorithm
> for one that is not.
>
Glenn,
Maybe I am misunderstanding you, but ...
If one codes a SEARCH ALL against a table that may or may not find the table
enttry that you want (i.e. it might be the first of duplicates, the second of
duplicates, or a random entry that doesn't even match any of the duplicate
entries), then I can't imagine what USE that would be.
A Standard conforming compiler *need not* even find one of the "duplicate"
entries when a SEARCH ALL is done - against a table with multiple entries with
the same key. The Standard (current and past) is pretty clear (as stated by
Chuck earlier) that if there are multiple table entries with the same key value,
then "results are unpredictable".
I don't think this is a case of throwing the baby out with the bathwater - but
rather is a case of avoiding throwing a baby into the middle of an olympic size
pool <G>.
--
Bill Klein
wmklein <at> ix.netcom.com
Glenn Someone
ALL is the binary one.
In Big O notation (algorithms are almost always measured by their
worst case, never their average or best), the serial search is O(n),
while binary search is O(log n) (log base 2).
Big O of the serial search of 1000 table elements = 1000
Big O of the binary search of 1000 table elements = 10
Essentially the moment we reach the 11th element (21st if I am
generous on calculating midpoints) on a serial search, the binary
search does it. If we go into multiple searches, the choice is
obvious.
"It seems that the excuse that the CPU is fast enough, or the problem
will be upgraded out of seems all too common." There's no purpose or
logical point to using a markedly inferior algorithm because of fears
of not heeding the truisms heard in the classroom.
On Fri, 16 Jul 2004 16:28:08 -0500, "JerryMouse" <nos...@bisusa.com>
wrote:
>A SEARCH on a 1000-item table does about 10 compares plus attendant
Chuck Stevens
out-of-pocket for the next week.
What I was addressing was SEARCH ALL. SEARCH ALL does whatever the
applicable COBOL standard says it's supposed to do and, like it or not, the
applicable COBOL standards require that the data that's the target of SEARCH
ALL be in order and that it contain no duplicates, and additionally state
that the results are undefined if these rules aren't followed.
I know of implementations that give you an arbitrary duplicate, others that
give you the first, but the COBOL standard doesn't require any
implementation to do either one, or to do anything particular in the event
of an ordering problem.
I do know what a "binary search" does. My point is that SEARCH ALL is not a
synonym for that, the rules for SEARCH ALL are strict, and the results of
SEARCH ALL are undefined in standard COBOL if the rules about how the data
must be ordered aren't followed.
-Chuck Stevens.
"Glenn Someone" <donts...@whydoyouneedmyaddressspammers.com> wrote in
message news:rkhgf01hkvc8amala...@4ax.com...
Glenn Someone
If the SEARCH ALL doesn't perform as expected, then that isn't the
fault of the programmer who expects a binary search and does not get
one. One of the many failures of the "COBOL standard" if the
hard-wired verbs defined in the standard do not perform in a
consistent manner across all platforms. If I notice a verb is
inconsistent, I stop using it and code its equivalent.
I tend to ignore using SEARCH and INSPECT for this very reason.
Examples of failures out of many failures of the standard.
Educate yourselves and know what is going on for yourself and don't
listen to this regurgitated stuff.
On Fri, 16 Jul 2004 22:03:00 GMT, "William M. Klein"
<wmk...@nospam.netcom.com> wrote:
>Glenn,
> Maybe I am misunderstanding you, but ...
>
Michael Mattias
A real simple way to speed up a linear search.....
Sort the table to bve serached
When table-value(sub) > target
exit linear search with notfound
-
Michael Mattias
Tal Systems, Inc.
Racine WI
mmat...@talsystems.com
"JerryMouse" <nos...@bisusa.com> wrote in message
news:DpKdnaTDdY3...@giganews.com...
Michael Mattias
A real simple way to speed up a linear search.....
Sort the table to bve serached
When table-value(sub) > target
exit linear search with notfound
(No you don't want to use the SEARCH verb to do this, because that will look
at all the entries even when there is no longer a possibility the item will
be found)
Alternately in your case...
Do your binary search (SEARCH ALL) on your sorted table... when you get a
hit, decrease your index in a loop to find where "target" values start in
table, then scan though them in forward direction until you find the one you
want or the key changes; that is, let SEARCH ALL get you "on the correct
block" and then walk from house to house.
-
Michael Mattias
Tal Systems, Inc.
Racine WI
mmat...@talsystems.com
"JerryMouse" <nos...@bisusa.com> wrote in message
news:DpKdnaTDdY3...@giganews.com...
Don Leahy
key to make it unique. Then you can go back to using SEARCH ALL.
HTH
William M. Klein
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), it is documented as
"non-sequential" - and I have never (personally) heard of an implementation
where it is not as fast or faster than a linear search - especially for "large"
tables (where "large" means that for the compilers algorithm, the "expected
hit" is at or before where it would be on a linear search).
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).
--
Bill Klein
wmklein <at> ix.netcom.com
"Glenn Someone" <donts...@whydoyouneedmyaddressspammers.com> wrote in message
news:h2mgf09ve2b9rgk3h...@4ax.com...
Richard
> so have, say, five duplicates each. SEARCH ALL will satisfy 37,000
> possibilities and the remainder will have to go against the second table;
> you'll need to add a flag to the first to tell the code whether a SEARCH
> against the second is needed.)
A 'flag' such as a number that is zero or the subscript of the chained
entries in the second table perhaps ?
Warren Simmons
>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), it is documented as
>"non-sequential" - and I have never (personally) heard of an implementation
>where it is not as fast or faster than a linear search - especially for "large"
>tables (where "large" means that for the compilers algorithm, the "expected
>hit" is at or before where it would be on a linear search).
>
>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).
>
>
>
When I was a pup, one of the things I was charged with was conducting
the scheduling of purchased training aids for COBOL. Among those
I recall, way back then, that the vendor of the aids had made a case
for each type of search, and gave the plus and minus of each.
At that time, our COBOL programmers, had not begun to use the various
methods of sorting in COBOL. Their hardware, file sizes, and other
opportunities were such little time was disputing what they had been
taught, or debating how best. Management was most interested in
getting the job done with the tools at hand, and with the best knowhow
we could by and use. We did. The only difference between then and now,
as I see it, is the size of files, the speed of computers, and the
uneven training
provided.
If what I have learned reading this newsgroup for the last several years is
any measure, Mr. Klein is right 99/100 of the time, and when he is not
he admits it.
However, this thread has introduced to me some methods that I had
not been aware of, and it has been a refreshing thread.
Thank you , all.
Warren Simmons
Glenn Someone
uncomfortable" with it.
But one important caveat. It's never a good thing performance wise to
sort a table just to be able to perform a binary search, unless the
payback for doing it is significant. While the binary search beats
the pants off the sequential search, sorting the data can and will
negate that benefit and then some, unless you do perform 1000's of
searches.
And incidentally, we did have tables when I was working which were
searched once for every transaction record. While the tables were 150
units in size, it still benefitted us greatly to use binary searching.
On Fri, 16 Jul 2004 22:46:40 GMT, "Michael Mattias"
<michael...@gte.net> wrote:
>Sort the table to bve serached
>Do your binary search (SEARCH ALL) on your sorted table... when you get a
Glenn Someone
1) On both suggestions, it would have been a hard sell in my
experience to change any table, but very hard to change the tables in
these manners. One must remember sometimes that in changing a table
it requires recompilation and retesting of not just that program but
every program that uses that table, and that management can often be
hard pressed to agree to changes that can often be deemed unjustified
(in an economic - time sense). The main point I'm thinking is that it
would be very hard to justify these changes if they were presented -
I've had two bosses that would reject both of these suggestions as
"waste of labour resources" (or whatever nifty manager speak you want
to attach to them).
2) The third suggestion is pretty convoluted, IMO. Would this be
really possible or reasonable in all cases? Personally, I know I
would flunk this option as a code reviewer (for about three different
reasons I can think of off the top of my head).
JerryMouse
> I think you confused the two. SEARCH is a serial search, while SEARCH
> ALL is the binary one.
I had it right - my fingers screwed up. Your rendition is closer to the
truth:
SEARCH = serial search
SEARCH ALL = non-serial search (but not necessarily binary)
>
> In Big O notation (algorithms are almost always measured by their
> worst case, never their average or best), the serial search is O(n),
> while binary search is O(log n) (log base 2).
>
> Big O of the serial search of 1000 table elements = 1000
> Big O of the binary search of 1000 table elements = 10
>
> Essentially the moment we reach the 11th element (21st if I am
> generous on calculating midpoints) on a serial search, the binary
> search does it. If we go into multiple searches, the choice is
> obvious.
>
> "It seems that the excuse that the CPU is fast enough, or the problem
> will be upgraded out of seems all too common." There's no purpose or
> logical point to using a markedly inferior algorithm because of fears
> of not heeding the truisms heard in the classroom.
>
No, it's not obvious. The original poster said they converted a binary
search to a PERFORM ... UNTIL. My position is that, in most applications, it
doesn't matter whether it's a SEARCH, SEARCH ALL, PERFORM ... UNTIL, or a
banana. The time difference is almost immeasurably small.
Observations on this thread have wandered all over the SEARCH terrain. Some
observations on the observations:
1. "A SEARCH ALL on a table with duplicate fields generates unpredictable
results." Well, how unpredictable? 2 + 2 = 7 is closer to the truth than 2 +
2 = purple. Will the verb always return one of the duplicates? Or will it
sometimes return change for a dollar? If the verb always returns one of the
duplicates, that might be good enough (Do I have ANYBODY named "Jones" in
the database?).
2. "Sort the table then you can use SEARCH ALL" If I were going to sort
the data why couldn't I be looking for what I wanted in the first place?
Unless I sort the table once and use the sorted, resulting table over and
over.
And one new observation:
For a humongous table, write the table as an ISAM file and check the file.
This, in many cases, will be faster. Here's why: For a HUGE table that won't
fit in memory, the OS will do bags and bags of memory paging, especially for
a binary sort. For an ISAM file the OS will probably do ONE I/O operation
(because the OS cleverly kept the key file in memory).
Anyway, I still suggest the original problem (10 minutes of CPU time vs. 140
minutes) is probably not the result of changing the lookup method.
Glenn Someone
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"
<wmk...@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
William M. Klein
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" <donts...@whydoyouneedmyaddressspammers.com> wrote in message
news:v66hf09jf5f6c4q8u...@4ax.com...
Arnold Trembley
Michael Mattias
> But one important caveat. It's never a good thing performance wise to
> sort a table just to be able to perform a binary search, unless the
> payback for doing it is significant. While the binary search beats
> the pants off the sequential search, sorting the data can and will
> negate that benefit and then some, unless you do perform 1000's of
> searches.
In this particular case, it certainly appears worth the effort..
The OP said his change from SEARCH ALL to SEARCH had resulted in a
twelvefold increase in run time (a number which, frankly, causes me to doubt
the quality of either the change in implementation or the measurement
technique... although asked, I can't find the number of table items
involved, so it's possible).
I have often said, and published the same thoughts, that performance tuning
is ALWAYS about specific cases... there is no "silver bullet" which solves
all performance problems...
Except... there is one technique which ALWAYS produces the best results:
applied imagination.
--
docd...@panix.com
Glenn Someone <donts...@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
docd...@panix.com
Now that might be interesting, Mr Plinston... I was thinking of a simple
indicator, at the end of the table-entry, along the lines of
...
05 OTHER-TBL-DATA PIC (X).
88 U-GOTTA-CHECK-OTHER-TBL VALUE 'Y'.
... so that when a key matched an IF U-GOTTA-CHECK-OTHER-TBL (SUB1) would
send you on your merry way. What you suggest is along the lines of
...
05 OTHER-TBL-SUB PIC 9(4) COMP.
... (or whatever numeric representation would have the best combination of
size and machine-speed for the platform in question) and the first time a
duplicate key was encountered the position in the second table of this
entry would be MOVEd to this in the first table and subsequent entries
into the second table would generate an ADD.
(Actually... now, to think of it, depending on the complexity of the table
entry it might be best to define an INIT-ROW, with appropriate space and
zero values and types, so that the first thing one does when adding a row
to the base table would be MOVE INIT-ROW TO TBL-ENTRY (SUB1) so that
everything could be accomplished by ADDs, no FIRST-TIME code necessary...)
Then, when trundling through the first table, a check for IF OTHER-TBL-SUB
> 0 would allow for the quickest way to bypass the unnecessary rows.
DD
docd...@panix.com
Glenn Someone <donts...@whydoyouneedmyaddressspammers.com> wrote:
>Just some general thoughts:
>
>1) On both suggestions, it would have been a hard sell in my
>experience to change any table, but very hard to change the tables in
>these manners.
Of *course* it would be a 'hard sell'; the design of the system is
changing to a point where it is being expected to do what it was not
originally spec'd to do. This is *never* an sign-post reading 'EASY TIMES
AHEAD'.
>One must remember sometimes that in changing a table
>it requires recompilation and retesting of not just that program but
>every program that uses that table, and that management can often be
>hard pressed to agree to changes that can often be deemed unjustified
>(in an economic - time sense).
As noted above - the system was designed to handle a certain amount of
data meeting certain conditions, just as an automobile is designed to
handle a certain number of passengers under certain conditions. Once the
amount of data, or number of passengers, increases to a point where the
original design is no longer appropriate then the design must change... or
what comes out will make as much sense as a gang of clowns.
>The main point I'm thinking is that it
>would be very hard to justify these changes if they were presented -
>I've had two bosses that would reject both of these suggestions as
>"waste of labour resources" (or whatever nifty manager speak you want
>to attach to them).
I, too have had bosses whose parents seem to have violated the f\various
ordinanaces against consanginaceous relations; in such cases I make my
points and await the consequences. Having lead the horse to water and
seeing that it still chooses to remain thirsty... I clean out my desk and
find another contract. What can I tell you... when faced with the pain of
doing something which makes me feel so uncomfortable I vacate the
situation; I'm just lazy or weak, perhaps.
>
>2) The third suggestion is pretty convoluted, IMO. Would this be
>really possible or reasonable in all cases? Personally, I know I
>would flunk this option as a code reviewer (for about three different
>reasons I can think of off the top of my head).
How many times must it be repeated... the whole situation which causes
these suggestions is pretty convoluted, the solutions which result just
might possibly reflect this. Do you mean to say that you would flunk a
solution which includes an adjunct table but you would pass a solution
where a SEARCH ALL returns what you have labelled 'an unpredictable
result' and the code then pokes and peeks at the above-and-below rows to
find the right one?
DD
docd...@panix.com
Michael Mattias <michael...@gte.net> wrote:
[snip]
>Do your binary search (SEARCH ALL) on your sorted table... when you get a
>hit, decrease your index in a loop to find where "target" values start in
>table, then scan though them in forward direction until you find the one you
>want or the key changes; that is, let SEARCH ALL get you "on the correct
>block" and then walk from house to house.
This is the 'peeking and poking, above and below' which makes me...
uncomfortable.
DD
docd...@panix.com
Glenn Someone <donts...@whydoyouneedmyaddressspammers.com> wrote:
>Mr. Mattias gets it. Unfortunately most here would be "very
>uncomfortable" with it.
I cannot speak for 'most here'; I can say that, for myself, I would rather
see a redesign than an attempt to apply a construct in a manner which the
Standard clearly and unambiguously states will give unpredictable results.
This is because, in my experience, the data themselves have a tendency to
introduce sufficient unpredictability that I have found it undesireable to
add to this.
DD
Michael Mattias
No sense of adventure? You've been doing what you've been doing too long.
MCM
docd...@panix.com
Michael Mattias <michael...@gte.net> wrote:
><docd...@panix.com> wrote in message news:cdbd70$38j$1...@panix5.panix.com...
>> In article <kVYJc.1717$4L7....@newssvr33.news.prodigy.com>,
>> Michael Mattias <michael...@gte.net> wrote:
>>
>> [snip]
>>
>> >Do your binary search (SEARCH ALL) on your sorted table... when you get a
>> >hit, decrease your index in a loop to find where "target" values start in
>> >table, then scan though them in forward direction until you find the one
>you
>> >want or the key changes; that is, let SEARCH ALL get you "on the correct
>> >block" and then walk from house to house.
>>
>> This is the 'peeking and poking, above and below' which makes me...
>> uncomfortable.
>
>No sense of adventure?
Not when it comes to code that's to be implemented into Prod, no.
>You've been doing what you've been doing too long.
... and my particular parts of systems have been... boringly stable for a
goodly bit of time, as well. Wonderful world that has such coincidences
in it, neh?
DD
Robert Wagner
>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.'
My goal is programs that DON'T blow up and require debugging at 2 am .. programs
that detect exceptions and handle them gracefully. I do it by _raising_ the bar
of programmer skill rather than lowering it.
Glenn Someone
> and all this peeking and poking about,
>above and below, makes me... uncomfortable.'
It really shouldn't. The way I see it is that a program design is
getting introduced that is making you uncomfortable because it's
something different than what you've already encountered. If everyone
had this attitude, computer science wouldn't be developing and moving
its way forward and we'd still be in the Grace Murray Hopper days of
punch cards.
>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.
Is that the assumption? Because it's something you've never seen, you
assume it would blow up and not work. Have you ever heard of good
sound testing? Like I said study what the binary search does (if
SEARCH ALL doesn't cut it, provide a binary search, it's not that hard
to code yourself!), and then you might get a little bit of ease out of
it.
>I don't understand this... my suggestions, in a previous posting, did not
>include changing a binary search into a sequential one.
Let me add to that..."Or add unnecessary data or variables.".
>> 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.
No. This is showing you don't have a conception of what a binary
search is. Searching for BBB will return row 4 from a properly coded
binary search, AAA row 2, CCC row 6. Then finding the first entry
involves your sequential search option (using PERFORM UNTIL). I
wouldn't personally go up and down from the spot discovered, because
of that simplicity argument (I'd go find the first one and then
process all records accordingly).
>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.
I can't help that. As said in another post, that is one of my pet
peeves of SEARCH and INSPECT. The behavior is hard wired and both
verbs are useless if 1) they do not perform consistent actions across
platforms. and 2) you have to do something that is not consistent with
those hard-wired actions.
>'Do not implement into Prod any code which cannot be debugged by a typical
>2-year programmer at 2:am.'
I find most people can understand the concept of a binary search if
they see one. In fact, most people use that concept when they play a
number guessing game when they've thought about it ("I'm thinking of a
number between 1 and 100. What is it?"). Let's just say in my
experience, INSPECT fits this category of "can not be debugged by a
typical 2 year programmer at 2 am" much more better than a fully coded
out binary search. You might rethink using INSPECT statements in your
code if you're so inclined about this process.
>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?
That's the point we're trying to agree upon. The binary search <>
SEARCH ALL, evidently, so that's not what is being advocated
necessarily. Binary search doesn't return the first occurrence in
the table of a duplicate value, but it will return A value quite
predictably. That is all that is being asked of it, and it will do
that job perfectly.
>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.
It's not. But yes, a good example of poor program design if I ever
seen one - someone just going off of what was heard in class "don't
use binary search on a table with duplicates", and the rest is
history. The not-understanding programmer changes the SEARCH ALL to
SEARCH and we get the corresponding speed decrease as noted by the OP.
Glenn Someone
more for devising a direct index access relationship to the key
itself, and not a searching method? As a quick & simple example for
those that may not know, ordering the months from 1 to 12 in a table
is a simple example of hashing. How is this used to perform a search
in a table that might, in other situations, need a hash key calculated
for a direct access? I have my guess (program calculates hash keys
for all items in table into a hash table correlating to the main
table, program calcuates hash key for search entry, program looks at
hash table for key entry - convoluted, but it would do the job), but I
wouldn't mind hearing your take on it. Is that what the "hashing
routines" are doing?
William M. Klein
>
> That's the point we're trying to agree upon. The binary search <>
> SEARCH ALL, evidently, so that's not what is being advocated
> necessarily. Binary search doesn't return the first occurrence in
> the table of a duplicate value, but it will return A value quite
> predictably. That is all that is being asked of it, and it will do
> that job perfectly.
>
Glenn,
What you say may (or may not) be true of a "well designed and implemented"
hand-coded binary search. It is *NOT* true of the STANDARD conforming SEARCH
ALL.
A "SEARCH ALL" against a table with duplicate keys is TOTALLY UNDEFINED; it is
specified so any of the following are fully conforming:
A) It returns the last/first/middle occurrence that matches (possibly randomly
between the 3)
B) It returns a random entry where the key doesn't even match
C) It branches to the AT END condition
SEARCH ALL is an incredibly valuable and PRECICTABLE *AND* PORTABLE tool when
used against a table whose keys are all in the correct "ascending" (or
"descending") order and for which there are no duplicates. To avoid using it
for such cases is (in my opinion) silly. (Which does NOT mean that one should
use SEARCH ALL for a small table where a simple SEARCH may be faster.)
SEARCH ALL should be "avoided like the plague" for tables where one cannot
"predict" whether the keys are unique and in correct order. (It may or may not
get "close" to the desired entry.)
If you have a programer who can't understand this relatively SIMPLE distinction,
then you are right they should not be using SEARCH ALL - but I certainly
wouldn't trust any "hand-coded" search they created either.
docd...@panix.com
Robert Wagner <robert.d...@wagner.net> wrote:
>docd...@panix.com wrote:
>
>>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.'
>
>My goal is programs that DON'T blow up and require debugging at 2 am ..
>programs that detect exceptions and handle them gracefully.
That goal seems in no wise contradicted by the foregoing ''truism' to make
things easier'.
>I do it by
>_raising_ the bar of programmer skill rather than lowering it.
Dear me, Mr Wagner... do you believe that there's only one way to skin a
cat, as well?
DD
Michael Mattias
> Dear me, Mr Wagner... do you believe that there's only one way to skin a
> cat, as well?
Considering your post earlier this very day...
">Do your binary search (SEARCH ALL) on your sorted table... when you get a
>hit, decrease your index in a loop to find where "target" values start in
>table, then scan though them in forward direction until you find the one
you
>want or the key changes; that is, let SEARCH ALL get you "on the correct
>block" and then walk from house to house.
This is the 'peeking and poking, above and below' which makes me...
uncomfortable."
....isn't this the pot calling the kettle black?
MCM
LX-i
Man, your top-posting is killing me... but more to the point...
> 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'd be interested to see that quiz posted here. Folks who care enough
to take the time to educate themselves about the behavior of certain
verbs shouldn't be penalized for their increased knowledge. In fact,
isn't that why oftentimes "experience" is preferable to excessive
amounts of "education"?
Personally, I think INSPECT's hands are tied because the REPLACING
targets have to be of the same size (at least that's how it is on the
compiler I use daily). I'd like it to behave more like the VB "Replace"
verb, where I could replace x"31" by "" and shrink up the rest of the
data, or replace ">" with ">" and have the data expand. Instead, I
had to write my own looping algorithm for that - no big deal. Once it
was written, it was done. :)
> I think all programs should be simple, elegant, and fast.
At time, only two of those may be available...
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi...@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
docd...@panix.com
Glenn Someone <donts...@whydoyouneedmyaddressspammers.com> wrote:
>On 17 Jul 2004 09:53:48 -0400, docd...@panix.com wrote:
>
>> and all this peeking and poking about,
>>above and below, makes me... uncomfortable.'
>
>It really shouldn't.
No, it really should... see how easy it is to counter an unsupported
assertion with another unsupported assertion?
>The way I see it is that a program design is
>getting introduced that is making you uncomfortable because it's
>something different than what you've already encountered.
How interesting... the way I 'feel' it is that the program design that is
attempting to be introduced is said, clearly and unambiguously, by the
Standard to have a result which is 'unpredictable'. I find that there's
enough unpredictability which gets encountered as is, without implementing
that against which the Standard warns.
>If everyone
>had this attitude, computer science wouldn't be developing and moving
>its way forward and we'd still be in the Grace Murray Hopper days of
>punch cards.
If everyone had the attitude that it is a Good Thing to use the language
in a way which the Standard declares to be unpredictable then there might
be more 2:am suppoprt calls. See what happens when one plays 'what if'
instead of 'what is'?
'What is' appears to be that you desire to implement code which, by the
Standard, returns results which are unpredictable while doing that (and
the subsequent peeking and poking about to enhance predictability) is
something which 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.
>
>Is that the assumption? Because it's something you've never seen, you
>assume it would blow up and not work.
No. The Standard which states the results returned by using SEARCH ALL in
this manner are 'unpredictable'. I would not like to inflict a usage
which the Standard says is unpredictable in a situation which might be
encountered by another programmer - no matter *what* level of experience -
at 2:am.
>Have you ever heard of good
>sound testing?
I have... and I've heard of bugs that have remained hidden in code for
years... and I've not only heard of them, I've been called upon to fix
them, as well; it seems that our experiences are different.
>Like I said study what the binary search does (if
>SEARCH ALL doesn't cut it, provide a binary search, it's not that hard
>to code yourself!), and then you might get a little bit of ease out of
>it.
I've studied a small bit... enough to learn that the Standard clearly
calls the results returned from this use of SEARCH ALL to be
unpredictable.
>
>>I don't understand this... my suggestions, in a previous posting, did not
>>include changing a binary search into a sequential one.
>
>Let me add to that..."Or add unnecessary data or variables.".
Let me respond to that: 'Necessity is in the mind of the beholder'. If
data or variable added preclude the use of a construct in a manner which
the Standard warns as being 'unpredictable' then they might be, by a
definition, necessary.
>
>>> 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.
>
>No. This is showing you don't have a conception of what a binary
>search is. Searching for BBB will return row 4 from a properly coded
>binary search, AAA row 2, CCC row 6.
Leaving my conceptions and your knowledge of them aside... I find it
interesting that you see the need to change the grounds of your argument
from a SEARCH ALL to 'a properly coded binary search'. Please be so kind
as to post the code, compiler and OS which you used to generate this
assertion so that it might be independently verified.
[snip]
>
>>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.
>
>I can't help that.
You can't help using a torque-wrench to drive nails? I find it is rather
easy; I simply pick up a hammer instead of a torque-wrench.
>As said in another post, that is one of my pet
>peeves of SEARCH and INSPECT. The behavior is hard wired and both
>verbs are useless if 1) they do not perform consistent actions across
>platforms. and 2) you have to do something that is not consistent with
>those hard-wired actions.
I've worked in shops where SEARCH was prohibited... not because of
cross-platform inconsistencies but because of the inability of a manager
to understand how it works. I've worked in shops where INSPECT and
STRING/UNSTRING were prohibited... but that was because the manager was
afraid a batch subroutine would be suddenly appropriated for use in an
online (CICS) region.
Please be so kind as to document use, compiler and platforms where you
have encountered results which were inconsistent across platforms; if it
occurred more than two decades back you might be indulging in the behavior
of 'old truisms' for which you deride others.
>
>>'Do not implement into Prod any code which cannot be debugged by a typical
>>2-year programmer at 2:am.'
>
>I find most people can understand the concept of a binary search if
>they see one. In fact, most people use that concept when they play a
>number guessing game when they've thought about it ("I'm thinking of a
>number between 1 and 100. What is it?"). Let's just say in my
>experience, INSPECT fits this category of "can not be debugged by a
>typical 2 year programmer at 2 am" much more better than a fully coded
>out binary search. You might rethink using INSPECT statements in your
>code if you're so inclined about this process.
Our experiences, once again, seem to be different... but if I wanted only
agreement I would talk only with my mirror.
>
>>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?
>
>That's the point we're trying to agree upon. The binary search <>
>SEARCH ALL, evidently, so that's not what is being advocated
>necessarily. Binary search doesn't return the first occurrence in
>the table of a duplicate value, but it will return A value quite
>predictably. That is all that is being asked of it, and it will do
>that job perfectly.
Now I think I am starting to get the point... are you suggesting, then,
that the coder change the SEARCH ALL to a roll-your-own binary search?
>
>>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.
>
>It's not. But yes, a good example of poor program design if I ever
>seen one - someone just going off of what was heard in class "don't
>use binary search on a table with duplicates", and the rest is
>history. The not-understanding programmer changes the SEARCH ALL to
>SEARCH and we get the corresponding speed decrease as noted by the OP.
I have never heard in any class 'don't use binary search on a table with
duplicates'; I *have* been taught 'SEARCH ALL will return unpredictable
results when used against a table which contains duplicate keys'... so
perhaps, once again, our experiences are different.
DD
LX-i
> On 17 Jul 2004 09:53:48 -0400, docd...@panix.com wrote:
>
>
>>and all this peeking and poking about,
>>above and below, makes me... uncomfortable.'
>
>
> It really shouldn't. The way I see it is that a program design is
> getting introduced that is making you uncomfortable because it's
> something different than what you've already encountered. If everyone
> had this attitude, computer science wouldn't be developing and moving
> its way forward and we'd still be in the Grace Murray Hopper days of
> punch cards.
Both Mr. Stevens and Mr. Klein have stated that the results are
undefined when you do a binary search on a table with duplicate keys.
Do you understand what "undefined" means, in the context of the COBOL
standard? With one vendor, they may code it to find the first in
sequence that matches. Another may choose to look at blocks, and if
they happen to find one that matches, they'll return it, even if it's 3
of 7 with the same key. It's entirely possible that a third vendor
could interpret the same condition as "I can't uniquely satisfy this
search, so I'm going to throw "at end"." What does that do to your
peek-and-poke strategy?
You claim to want the most stable, portable code, but in this case,
you're relying on undefined functionality to give you an acceptable
solution. THAT is what makes some folks here "uncomfortable" with it.
docd...@panix.com
Mr Mattias, I believe what you quoted is a statement about what makes me
comfortable... no more, no less. I do not understand how that can be
interpreted as a statement of the number of methods available or the
superiority of one method over another... just what makes me
uncomfortable.
Might you how you see another possibility than this?
DD
docd...@panix.com
LX-i <lxi...@netscape.net> wrote:
>Glenn Someone wrote:
>
>> On 17 Jul 2004 09:53:48 -0400, docd...@panix.com wrote:
>>
>>
>>>and all this peeking and poking about,
>>>above and below, makes me... uncomfortable.'
>>
>>
>> It really shouldn't. The way I see it is that a program design is
>> getting introduced that is making you uncomfortable because it's
>> something different than what you've already encountered. If everyone
>> had this attitude, computer science wouldn't be developing and moving
>> its way forward and we'd still be in the Grace Murray Hopper days of
>> punch cards.
>
>Both Mr. Stevens and Mr. Klein have stated that the results are
>undefined when you do a binary search on a table with duplicate keys.
A correction, Mr Summers: Mr Stevens and Mr Klein have pointed out that
the Standard reports the results of a SEARCH ALL against a table with
duplicate keys is unpredictable. While a SEARCH ALL *may* be implemented
by a vendor as a binary search... what I think is trying to be pointed out
is that there are other binary searches (hand-rolled ones) which are not
SEARCH ALL and which, therefore, might have... less unpredictability.
DD
LX-i
My mistake - thanks for the correction. :) (My point remains the same,
although it seems to be an echo of earlier messages... Maybe repetition
will aid in understanding.)
Richard
> My goal is programs that DON'T blow up and require debugging at 2 am .. programs
> that detect exceptions and handle them gracefully. I do it by _raising_ the bar
> of programmer skill rather than lowering it.
Then don't use undocumented and unsupported features, or in ways that
are disallowed by the documentation.
Richard
> Is that the assumption? Because it's something you've never seen, you
> assume it would blow up and not work.
The problem is not that it will 'blow up and not work', the problem is
that the results are not defined and may be different in the next
version, or from some other change.
> Have you ever heard of good sound testing?
Testing only provides results in the environments tested. If the
environment changes then undefined results may change.
> Like I said study what the binary search does (if
> SEARCH ALL doesn't cut it, provide a binary search, it's not that hard
> to code yourself!), and then you might get a little bit of ease out of
> it.
But that is not necessary. Adding a sequence is trivial, either at the
time the table is created or by a single serial pass to do this.
> >(row 1) AAA 0
> >(row 2) AAA 1
> >(row 3) BBB 0
> >(row 4) BBB 1
> >(row 5) BBB 2
> >(row 6) CCC 0
> >(row 7) CCC 1
> No. This is showing you don't have a conception of what a binary
> search is. Searching for BBB will return row 4 from a properly coded
> binary search, AAA row 2, CCC row 6. Then finding the first entry
> involves your sequential search option (using PERFORM UNTIL). I
> wouldn't personally go up and down from the spot discovered, because
> of that simplicity argument (I'd go find the first one and then
> process all records accordingly).
Adding the sequence and then SEARCH ALL '<key> 0' gives a reliable,
portable, _defined_ result of the first entry for <key> without having
to do your own search coding, or grubby -1, +1 shuffling.
docd...@panix.com
LX-i <lxi...@netscape.net> wrote:
[snip]
>(... Maybe repetition
>will aid in understanding.)
Oh, I *cannot* resist...
... I'm not sure that made sense, might you said it again?
DD
Robert Wagner
>Personally, I think INSPECT's hands are tied because the REPLACING
>targets have to be of the same size (at least that's how it is on the
>compiler I use daily). I'd like it to behave more like the VB "Replace"
>verb, where I could replace x"31" by "" and shrink up the rest of the
>data, or replace ">" with ">" and have the data expand. Instead, I
>had to write my own looping algorithm for that - no big deal. Once it
>was written, it was done. :)
You coulda done it with one line of code by thinking outside the box:
EXEC SQL SELECT REPLACE (:my-string, '>', '>') INTO :my-string FROM DUAL
END-EXEC.
Robert Wagner
Robert Wagner
The machine is agnostic about standards and documentation. People worry about
such things.
I've worked in traditional shops, where programmers had carte blanche, and I've
worked in shops HEAVILY CONTROLLED with methodologies such as CMM Level 5 and
ISO-9000, which require LOTS of QA testing, lock-downs, oversight, code review,
Change Management, etc. The latter are designed to protect us from human
fallibility. Does it work? Are there fewer program bugs when formal
development/testing methodologies are employed? In my observation, the number of
bugs is about the same. The millions of dollars big companies spend to overcome
human nature is wasted. My beauty-oriented approach, on the other hand, DOES
reduce program bugs .. to nearly zero. My supporting evidence is the experience
of companies where it was deployed.
A notable exception is the aviation industry .. computers that fly airplanes,
where 'certification' methodologies were first developed and from which copied
by other industries. It really works in that domain, but at expense so huge that
other industries are unwilling to pay the price.
There are glitches even there. A 747 flying Australian day-tourists over
Antarctica flew into a mountain due to a reported 'program bug'. It was actually
pilot misunderstanding correction of a data error -- the pilot was flying the
plane VFR at the time -- but 'the system' failed.
Glenn Someone
nature issues and not coding, performance, or reliability issues.
Frederico Fonseca
Pretty, but not portable. This implies that the compiler used allows
for ESQL. Not all do.
There is at lease one that does not support without third party tools,
and even like that it needs a preprocessor from whatever DB they have
available (which at this stage are Oracle, SYBASE, DB2 and ADABAS. SQL
server does not have it, neither does MySQL.).
The above code also implies a connection to a DB, which may not be
required throughout the application, so the overhead of adding just
for a "conversion" would void any speed/functionality gained by this.
Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com
Robert Wagner
>Exactly. IMO, what I've seen expressed in this thread are human
>nature issues and not coding, performance, or reliability issues.
Bad programmers think they are addressing the machine, telling it to do this and
that. Good programmers picture their readership as humans who will have to
understand the code.
docd...@panix.com
Robert Wagner <robert.d...@wagner.net> wrote:
>docd...@panix.com wrote:
>
>>In article <40f963cb....@news.optonline.net>,
>>Robert Wagner <robert.d...@wagner.net> wrote:
>
>>>I do it by
>>>_raising_ the bar of programmer skill rather than lowering it.
>>
>>Dear me, Mr Wagner... do you believe that there's only one way to skin a
>>cat, as well?
>
>There are artful ways and a plethora of clumsy ways.
So more than one way exists, Mr Wagner. Now... these terms, 'artful' and
'clumsy', seem to modified or affected by personal views, experiences or
backgrounds; after all, one cannot say 'this contains (n) units of art' in
the same manner as 'this contains (n) degrees Fahrenheit'.
Might it be, then, Mr Wagner, that these ways contain not as much 'art' as
much as 'what I like and the rules I have coded into the program which I
call The Beautifier'?
DD
docd...@panix.com
Mr Wagner, in that a computer is *not* human what you are saying here is
that 'good programmers generate a Noble Lie'... how very Platonic of you!
DD
Joe Zitzelberger
Somehow, maintenance and/or enhancements to the system had started
generating tables with a non-unique key.
Two equal keys should, in an sane and normal world, be equal. The act
of being a key allows us to know that it does not matter which
associated data one finds when using said key. If this is not the case,
then some field that provides uniqueness has been left out of the key.
It is possible that this field is not part of the actual data, but part
of the runtime situtation -- e.g. that the missing data item is a
sequence appended to the key representing the instance of a specific
'unique' key.
Glenn Someone
translates into fast too. The machine knows nothing, you always
address human factors. Even performance is based on a desire for
speed (i.e. not waiting around for my work to get done), or money
(when billed for CPU hours).
Usually my most paramount concern is the next person that comes along
in understanding the code. Simple and elegant helps again. This
means doing the work with the best algorithm and the shortest path,
and the fewest variables. Less code, and less variables means it is
easier to understand, and means less of those 2am callouts people are
fretting about (hey I don't like it either!). In my experience,
however, most people just get the job done and move on (and I have
stories about that one). And yes, my programming methodology creates
friction - as no doubt seen in this thread.
Unfortunately, I will admit I've produced two programs that completely
fall into the "not understandable" path. While still simple and
elegant, it seems the learning curve for the required algorithm (and
there were no alternatives) in these two programs was high enough that
subsequent maintenance programmers could not understand it.
Unfortunately it couldn't be helped. I really couldn't think of a
solution to get past this particular human factor.
Robert Wagner
>Unfortunately, I will admit I've produced two programs that completely
>fall into the "not understandable" path. While still simple and
>elegant, it seems the learning curve for the required algorithm (and
>there were no alternatives) in these two programs was high enough that
>subsequent maintenance programmers could not understand it.
>Unfortunately it couldn't be helped. I really couldn't think of a
>solution to get past this particular human factor.
When in situation, I've used two approaches, alone or in combination:
1. Decompose the algorithm into simpler callable functions.
2. Include a document several pages long explaining the algorithm in detail.
Perhaps use 'footnote references' that refer back to the document.
The Sorts and Trees demos I posted here a month ago are examples of both.
Robert Wagner
>In article <40f9ecb9....@news.optonline.net>,
>Robert Wagner <robert.d...@wagner.net> wrote:
>>There are artful ways and a plethora of clumsy ways.
>
>So more than one way exists, Mr Wagner. Now... these terms, 'artful' and
>'clumsy', seem to modified or affected by personal views, experiences or
>backgrounds; after all, one cannot say 'this contains (n) units of art' in
>the same manner as 'this contains (n) degrees Fahrenheit'.
Tell movie and restaurant critics that their star systems are meaningless.
Tell professors of art, music, etc. that their grades are self-indulgence.
Tell auditioners that their judgment is just personal preference.
Tell award committees such as Oscar, Pulitzer, Grammy, etc. that their prizes
mean little to the consumer community.
>Might it be, then, Mr Wagner, that these ways contain not as much 'art' as
>much as 'what I like and the rules I have coded into the program which I
>call The Beautifier'?
"Great innovators and original thinkers and artists attract the wrath of
mediocrities as lightning rods draw the flashes." -- Theodor Reik
"People who are unable to motivate themselves must be content with mediocrity,
no matter how impressive their other talents." -- Andrew Carnegie
Robert Wagner
>In article <40f9ebb7....@news.optonline.net>,
>Robert Wagner <robert.d...@wagner.net> wrote:
>>You coulda done it with one line of code by thinking outside the box:
>>
>>EXEC SQL SELECT REPLACE (:my-string, '>', '>') INTO :my-string FROM DUAL
>>END-EXEC.
>
>Mr Wagner, and how might this have been done at a site where Oracle (or a
>similar database) is not installed?
file section.
fd string-file.
01 string-record pic x(80).
fd byte-file.
01 byte-record pic x(1).
working-storage section.
01 p pic 9(2).
linkage section.
01 my-string pic x(80).
procedure division using my-string.
open output string-file
write string-record from my-string
close string-file
open input byte-file
move 1 to p
perform until p > length(my-string)
read byte-file
if byte-record = '>'
string '>' into my-string with pointer p
else
string byte-record into my-string with pointer p
end-if
end-perform
close byte-file
goback.
JerryMouse
Richard
> There are glitches even there. A 747 flying Australian day-tourists over
> Antarctica flew into a mountain due to a reported 'program bug'.
It wasn't a 747.
It wasn't Australian.
> It was actually
> pilot misunderstanding correction of a data error -- the pilot was flying the
> plane VFR at the time -- but 'the system' failed.
It wasn't a 'pilot misunderstanding', it was a data entry error:
""Unknown to them two of the coordinates had been changed earlier that
morning, and when entered into the computer, changed the flight path
of the aircraft 45 kilometres to the east.""
My sister was actually booked on that flight, but cancelled when she
couldn't afford the extra to get a local flight to the departure
point.
docd...@panix.com
Hmmmm... looks like a bit more than one line of code. Curious how
'thinking outside the box' to a one-line solution required an entirely
different product to be installed, neh?
DD
docd...@panix.com
JerryMouse <nos...@bisusa.com> wrote:
>docd...@panix.com wrote:
>>
>> Mr Wagner, and how might this have been done at a site where Oracle
>> (or a similar database) is not installed?
>
>Here's another way - shamelessly copied from, um, somewhere:
>
A bit more than one line of code, as well... gosh-darn those boxes you
have to think outside that don't have Oracle installed there, I guess.
DD
docd...@panix.com
Robert Wagner <robert.d...@wagner.net> wrote:
>docd...@panix.com wrote:
>
>>In article <40f9ecb9....@news.optonline.net>,
>>Robert Wagner <robert.d...@wagner.net> wrote:
>
>>>There are artful ways and a plethora of clumsy ways.
>>
>>So more than one way exists, Mr Wagner. Now... these terms, 'artful' and
>>'clumsy', seem to modified or affected by personal views, experiences or
>>backgrounds; after all, one cannot say 'this contains (n) units of art' in
>>the same manner as 'this contains (n) degrees Fahrenheit'.
>
>Tell movie and restaurant critics that their star systems are meaningless.
When they start posting to comp.lang.cobol about 'this contains (n) units
of art' I just might, Mr Wagner; until then your citing their behavior in
justification of your own seems to be yet another Brooklyn Bridge defense.
>
>Tell professors of art, music, etc. that their grades are self-indulgence.
See abov and re-read the bit about a 'Brooklyn Bridge defense'.
>
>Tell auditioners that their judgment is just personal preference.
See above etc.
>
>Tell award committees such as Oscar, Pulitzer, Grammy, etc. that their prizes
>mean little to the consumer community.
See above etc.
>
>>Might it be, then, Mr Wagner, that these ways contain not as much 'art' as
>>much as 'what I like and the rules I have coded into the program which I
>>call The Beautifier'?
>
>"Great innovators and original thinkers and artists attract the wrath of
>mediocrities as lightning rods draw the flashes." -- Theodor Reik
Mr Wagner, I am not trying to address the work of 'great innovators and
original thinkers and artists', I am attempting to address the assertions
that you have made in this forum. Lightning is attracted by hilltops,
trees and other items which do not have what many would call 'any
measurable intelligence.'
>
>"People who are unable to motivate themselves must be content with mediocrity,
>no matter how impressive their other talents." -- Andrew Carnegie
'The fine line between genius and insanity is more often cited by those
closer to the latter than the former.' - Anonymous (author of *many*
profound quotes)
DD
LX-i
Interesting - I may have to give that a shot. :)
LX-i
> Tell award committees such as Oscar, Pulitzer, Grammy, etc. that their prizes
> mean little to the consumer community.
I'd agree with that one... :) (at least for this consumer)
Richard
> >>There are artful ways and a plethora of clumsy ways.
> Tell movie and restaurant critics that their star systems are meaningless.
> Tell professors of art, music, etc. that their grades are self-indulgence.
> Tell auditioners that their judgment is just personal preference.
> Tell award committees such as Oscar, Pulitzer, Grammy, etc. that their prizes
> mean little to the consumer community.
But this isn't about restaurants, art, drama or awards, it is about
Cobol.
It may well be that your 'personal preferences' are just 'meaningless'
'self-indulgences' that mean little to the actual quality.
> "Great innovators and original thinkers and artists attract the wrath of
> mediocrities as lightning rods draw the flashes." -- Theodor Reik
Yes, but so do idiots. You seem to take that 'attracting the wrath'
indicates that therefore you must be a 'great innovator' and 'original
thinker'.
Robert Wagner
My reply was a joke. Yours was too, right? The function can be performed with
three statements:
string link-string (1: link-loc - 1), link-insert,
link-string (link-loc: link-slen - link-loc + 1) into temp-string
add link-ilen to link-slen
move temp-string to link-string
Robert Wagner
>In article <40faa81f....@news.optonline.net>,
>Robert Wagner <robert.d...@wagner.net> wrote:
>>"Great innovators and original thinkers and artists attract the wrath of
>>mediocrities as lightning rods draw the flashes." -- Theodor Reik
>
>Mr Wagner, I am not trying to address the work of 'great innovators and
>original thinkers and artists', I am attempting to address the assertions
>that you have made in this forum. Lightning is attracted by hilltops,
>trees and other items which do not have what many would call 'any
>measurable intelligence.'
It was a quote. I don't claim to be a great innovator. My enemies have all come
from Operations, Hardware Techies and mediocre applications programmers.
Robert Wagner
>robert.d...@wagner.net (Robert Wagner) wrote
>
>> There are glitches even there. A 747 flying Australian day-tourists over
>> Antarctica flew into a mountain due to a reported 'program bug'.
>
>It wasn't a 747.
>It wasn't Australian.
My apologies to Kiwis.
>> It was actually
>> pilot misunderstanding correction of a data error -- the pilot was flying the
>> plane VFR at the time -- but 'the system' failed.
>
>It wasn't a 'pilot misunderstanding', it was a data entry error:
>
>""Unknown to them two of the coordinates had been changed earlier that
>morning, and when entered into the computer, changed the flight path
>of the aircraft 45 kilometres to the east.""
The change corrected an error that had been present for some time. The incorrect
route took them over a bay; the corrected route headed them toward a mountain.
When the pilot switched to VFR (manual control), he thought based on experience
and optical delusion that he was over a bay, so he did not climb.
What aircraft lacks radar to detect a mountain ahead? Even corporate turbo-props
have it. An A10 would have overridden the pilot and taken the plane over.
>My sister was actually booked on that flight, but cancelled when she
>couldn't afford the extra to get a local flight to the departure
>point.
Sorry to hear of her close call.
docd...@panix.com
Robert Wagner <robert.d...@wagner.net> wrote:
>docd...@panix.com wrote:
>
>>In article <40faa81f....@news.optonline.net>,
>>Robert Wagner <robert.d...@wagner.net> wrote:
>
>>>"Great innovators and original thinkers and artists attract the wrath of
>>>mediocrities as lightning rods draw the flashes." -- Theodor Reik
>>
>>Mr Wagner, I am not trying to address the work of 'great innovators and
>>original thinkers and artists', I am attempting to address the assertions
>>that you have made in this forum. Lightning is attracted by hilltops,
>>trees and other items which do not have what many would call 'any
>>measurable intelligence.'
>
>It was a quote.
This was apparent - at least to me, Mr Wagner - by your enclosing the
sentence in quotation marks and following it with a couple o' dashes and
someone's name.
>I don't claim to be a great innovator.
I did not say you claimed such, Mr Wagner, I said I was not trying to
address the words of such.
>My enemies have all come
>from Operations, Hardware Techies and mediocre applications programmers.
Perhaps this might change were you to get out more.
DD
JerryMouse
>
> My reply was a joke. Yours was too, right? The function can be
> performed with three statements:
>
> string link-string (1: link-loc - 1), link-insert,
> link-string (link-loc: link-slen - link-loc + 1) into
> temp-string add link-ilen to link-slen
> move temp-string to link-string
Not a joke.
While yours is simple, elegant, and probably fast, ours has one teeny
advantage: it does the insert in place without the need for a temporary work
area.
JerryMouse
>
> What aircraft lacks radar to detect a mountain ahead? Even corporate
> turbo-props have it. An A10 would have overridden the pilot and taken
> the plane over.
The Fairchild Republic A10 "Warthog" would have blown the moutain out of the
way.
Tom Morrison
news:ogYJc.5511$Qu5....@newsread2.news.pas.earthlink.net...
[snip]
> A Standard conforming compiler *need not* even find one of the "duplicate"
> entries when a SEARCH ALL is done - against a table with multiple entries
with
> the same key. The Standard (current and past) is pretty clear (as stated
by
> Chuck earlier) that if there are multiple table entries with the same key
value,
> then "results are unpredictable".
Bill, I hesitate to get into a disagreement regarding interpretation of the
COBOL standards, but I think you are being a bit too pessimistic in your
reading of the semantics for SEARCH ALL.
Using the 1985 standard, looking at 6.22.4 (3), we find the wording upon
which you make the above-quoted assertion. Also, the standard uses the term
"predictable only when" rather than "unpredictable" which I take to be
slightly, (but only slightly) less hostile.
But if one goes on to the next section, 6.22.4 (4), one finds the following
(about two-thirds of the way into the section):
If all the conditions [in the WHEN phrase] can be
satisfied, the index indicates an occurrence that
allows the conditions to be satisfied, and
control passes...
Note the use of the indefinite article 'an' rather than 'the' which
indicates, at least to this implementor, that the standards committee
anticipated the possibility of having multiple occurrences which satisfy the
WHEN phrase. This would still be 'unpredicatable' only in the sense that
one could not assume, without some further programming steps, or some other
meta-knowledge, which particular occurrence will be chosen by the algorithm.
This having been said, if Aru, the Original Poster, can change the table
structure slightly, he should:
(1) add a 'uniqueness guarantee' numeric field as the least
significant portion of the key which is reset to 0 upon each new key value,
and
(2) test for this value = 0 in the WHEN clause of the SEARCH ALL.
By doing so, he will avoid:
(1) potential COBOL implementor differences,
(2) some pretty obscure backtracking code in the WHEN clause, and
(3) know he is pointed at the first key and need only search forward
(higher index values) to examine for potential duplicate key values.
Best regards,
Tom Morrison
Liant Software Corporation
Richard
> >""Unknown to them two of the coordinates had been changed earlier that
> >morning, and when entered into the computer, changed the flight path
> >of the aircraft 45 kilometres to the east.""
>
> The change corrected an error that had been present for some time. The incorrect
> route took them over a bay; the corrected route headed them toward a mountain.
No. That is not true. The _correct_ route was over the bay. A small
adjustment was made but the wrong numbers were input which made the
route _incorrectly_ over the mountain.
> When the pilot switched to VFR (manual control), he thought based on experience
> and optical delusion that he was over a bay, so he did not climb.
He _was_ over _a_ bay, just a different one. The white mountain did
not show against the white background, it wasn't an 'optical delusion'
it was just not visible.
> What aircraft lacks radar to detect a mountain ahead? Even corporate turbo-props
> have it. An A10 would have overridden the pilot and taken the plane over.
Most small aircraft only have weather radar, not ground mapping radar.
Just because it is radar does not mean that it will 'aquire targets'
or 'detect mountains' or anything else it is not designed to do.
The aircraft did have terrain avoidance radar which did alert the
pilots but the ground slope was greater than the climb rate
achievable.
William M. Klein
I do NOT personally know of any existing commercial compiler that does anything
OTHER than a "binary search" for SEARCH ALL. This doesn't mean there aren't
any - only that I don't know of any. (I do know that some USED to do other
types of searches - and I am not at all certain what the "open-source" COBOLs do
with it.)
Related to Tom's reference below, I would point him (and others) looking at the
'85 Standard to page XVII-96, item 10. Although most of the wording is as he
quotes it from the body of the Standard, the preface to that list DOES make it
explicitly undefined (at least as I read such things).
--
Bill Klein
wmklein <at> ix.netcom.com
"Tom Morrison" <t.mor...@liant.com> wrote in message
news:oiSKc.16239$hj5....@newssvr24.news.prodigy.com...
Robert Wagner
>The Fairchild Republic A10 "Warthog" would have blown the mountain out of the
>way.
<laughing> I meant Airbus A310.
Robert Wagner
Here's a three-statement solution that doesn't make you define a work area:
add link-ilen to link-slen
move function reverse
(function reverse (link-string(link-insert:link-slen - link-loc + 1))
to link-string (link-loc + link-ilen)
move link-insert to link-string (link-loc:link-ilen)
Lueko Willms
schrieb charles...@unisys.com (Chuck Stevens)
auf /COMP/LANG/COBOL
in cd98b2$27c0$1...@si05.rsvl.unisys.com
ueber Re: Cobol Linear search Vs Perfrom Until
>> 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.
CS> The results of a SEARCH ALL are preictable *only when* the data
CS> matches the KEY clause and there are no duplicates.
That means, in my understanding, that there is no way to predict
which of, say, 5 duplicate items in the sorted key are being found by
the WHEN clause.
But:
CS> If either of these criteria is not met, *all bets are off* in
CS> terms of where you land in the table when you get a WHEN hit, and
CS> whether or not you get a WHEN hit on a table entry that is present
CS> (whether the particular key is a duplicate or not).
is something I don't believe.
I am quite convinced that a SEARCH ALL on a table with a sorted KEY
will find a matching item in the table, even if there are duplicates.
It is just not predictable at all, which one of those duplicates is
being matched.
Another question is for the design of that table and that
application -- what sense does it make to search a sorted table with
duplicate keys, unless you want just to ascertain the presence or its
negation of a search item in the table; and if there is a
discriminator among those duplicate key items which the program is
supposed to find out, why not include those discriminators in the
sorting key in the first place?
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WI...@jpberlin.de -- Alle Rechte vorbehalten --
"Es sind nicht die Generäle und Könige, die die Geschichte machen,
sondern die breiten Massen des Volkes" - Nelson Mandela
Richard
> >> What aircraft lacks radar to detect a mountain ahead? Even corporate
> >> turbo-props have it. An A10 would have overridden the pilot and taken
> >> the plane over.
>
> <laughing> I meant Airbus A310.
The DC-10 did 'override the pilot' and put the plane into a power
climb.
Whether the A310 could have 'taken the plane over' is an entirely
geometric problem related to achievable climb angle and the ground
angle.
Richard
> >> What aircraft lacks radar to detect a mountain ahead? Even corporate
> >> turbo-props have it. An A10 would have overridden the pilot and taken
> >> the plane over.
>
> <laughing> I meant Airbus A310.
The DC-10 did 'override the pilot' and put the plane into a power
Robert Wagner
>robert.d...@wagner.net (Robert Wagner) wrote
>The DC-10 did 'override the pilot' and put the plane into a power
>climb.
>
>Whether the A310 could have 'taken the plane over' is an entirely
>geometric problem related to achievable climb angle and the ground
>angle.
The Airbus computer wouldn't need to 'assume control' because it was already in
control. It's always in control. Pilot inputs are taken as 'suggestions' that
can be followed or not, much like Oracle treats 'hints'.
If an Airbus couldn't take the plane over the mountain, it would have executed a
turn to bypass it. Worst case, it would have done a 180.
Pilots hate having a computer that can override them. They want to flip a switch
to turn it off. They're reluctant to fly Airbus machines for that reason.
US Navy planes have automated systems for landing on aircraft carriers. Pilots
prefer to turn it off and land manually. The accident record shows that manual
landings have three times more accidents than computer landings. Why do they
want to land manually? Because of machismo, testosterone and hubris.
Richard
> Worst case, it would have done a 180.
No. The A310 is still limited by the same physics as any other plane.
A quarter century after the Erebus crash one would hope that the
systems have improved, and also learnt from accidents and errors.
Suggesting that it would have been better to have used an A310 instead
of a DC-10 is rather pointless, if Amelia Earhart had used an A310 she
wouldn't have been lost in the Pacific.
> They're reluctant to fly Airbus machines for that reason.
Locally we have just got a fleet of A320s, I went on one a couple of
weeks ago. Reports show the pilots to be enthusiastic with no
reluctance at all.
JerryMouse
>
> Locally we have just got a fleet of A320s, I went on one a couple of
> weeks ago. Reports show the pilots to be enthusiastic with no
> reluctance at all.
Is it true the A320 comes factory-equipped with a dog?
Computer flies the plane, pilot monitors the computer, dog bites pilot if he
tries to jack with the controls?
Of course the biggest problem with the A-series is they are (mostly) French
and have an inherent inclination to return to their home field.
Richard
> Is it true the A320 comes factory-equipped with a dog?
>
> Computer flies the plane, pilot monitors the computer, dog bites pilot if he
> tries to jack with the controls?
The Europeans may put one on board, but local border protection would
have it taken away and shot on arrival, we don't want no rabid euro
dogs here.*
> Of course the biggest problem with the A-series is they are (mostly) French
> and have an inherent inclination to return to their home field.
As long as the wings are designed and made by the british I know they
will stay in the air.
*(NZ is free of rabies, but as shown by the Rainbow Warrior, is not
free of the French).
jerry
thing. All my keys were numeric and I knew there were less than 10
duplicates. When I built the lookup table I appended a zero to the right of
all key values. For the duplicates I appended a 1 to 9 to them. I appended
a zero to the search argument going into a binary search . Thus it always
found either the only entry or the first one of consecutive dups.
Chuck Stevens
> A correction, Mr Summers: Mr Stevens and Mr Klein have pointed out that
> the Standard reports the results of a SEARCH ALL against a table with
> duplicate keys is unpredictable. While a SEARCH ALL *may* be implemented
> by a vendor as a binary search... what I think is trying to be pointed out
> is that there are other binary searches (hand-rolled ones) which are not
> SEARCH ALL and which, therefore, might have... less unpredictability.
In fact, I know of one implementation of SEARCH ALL that actually does a
*sequential* search in every case, and in that implementation the return of
the first matching key is guaranteed. These are *implementor-defined*
results.
The '85 standard simply describes the results of SEARCH ALL as predictable
*ONLY WHEN* 1) the table is ordered according to the KEY IS clause *AND* 2)
there aren't any duplicates. If *both* of these criteria are met, fine; if
one of them isn't, you might get the first matching entry, you might get AT
END, you might get *some* matching entry, you might get the Codex
Alexandrinus, or you might get November.
The 2002 standard limits the possibilites, I think. If there's a single
matching key in the table and the keys are out of order, you might get an AT
END or no-match exception, or you might get the matching entry; which you
get is undefined by the standard. If there are duplicate matching keys in
the table, you might get an AT END or no-match exception, or you might get a
match (but which matching entry you get is undefined by the standard), and
whether you get a match or not is also undefined by the standard. The
possibilities no longer include either the Codex Alexandrinus or November.
A Format 2 SEARCH statement is required to be "portable" only when the keys
in the table are in the specified order without duplicates. What
*individual* implementations may do when either of these rules are violated
is up to them; there's no guarantee that any two will do the same thing, and
a reasonable likelihood that they won't.
It's a really, really bad idea to depend on the behavior of SEARCH ALL when
the rules for the data being searched aren't being followed. I know our
implementations of SEARCH ALL impose these two execution-time requirements
in the documentation, and I would be surprised to hear that there are
implementations that don't document the restrictions.
And if indeed the vendor's documentation *does* document this restriction
for SEARCH ALL, deciding "well, yeah, I see what the manual says, but the
manual's full of it. It's *really* supposed to work the way I think it
ought to work, and so I'm going to code it that way" is an even *worse*
idea.
-Chuck Stevens
Chuck Stevens
news:9DAk-...@jpberlin-l.willms.jpberlin.de...
> CS> The results of a SEARCH ALL are preictable *only when* the data
> CS> matches the KEY clause and there are no duplicates.
>
> That means, in my understanding, that there is no way to predict
> which of, say, 5 duplicate items in the sorted key are being found by
> the WHEN clause.
No, it means there is no way to predict what you'll get from a generic
standards-compliant compiler. There is no requirement that you will get
one of the duplicate entries. In '85 COBOL, you might get AT END, an entry
that satisfies the search criteria, an entry that does not satisfiy the
search criteria, a rutabaga, or Catholicism; in '02 COBOL, the possibility
of getting a non-matching entry, a rutabaga or Catholicism is precluded, but
it is *explicitly* stated that you'll either get AT END, a search failure
exception, or an entry that matches.
> CS> If either of these criteria is not met, *all bets are off* in
> CS> terms of where you land in the table when you get a WHEN hit, and
> CS> whether or not you get a WHEN hit on a table entry that is present
> CS> (whether the particular key is a duplicate or not).
> is something I don't believe.
Sorry, it's in black and white *in the standards*. Whether individual
implementations restrict the possible results isn't germane to that point.
The results are undefined *unless* the entries are in order *and* there are
no duplicates.
> I am quite convinced that a SEARCH ALL on a table with a sorted KEY
> will find a matching item in the table, even if there are duplicates.
Dunno how to say this; be convinced to the contrary all you like, but that
doesn't make it so. No implementation is required by the standard to do
that. Some may, as implementor extensions, but such definitions, making
behavior predictable that is defined as unpredictable in the standard, are
implementor extensions, not standard COBOL, and therefore not defined as
producing the same results in all implementations.
> It is just not predictable at all, which one of those duplicates is
> being matched.
In '02 standard COBOL, *if* you get a match on a duplicate key, it will
match. But it isn't predictable *that* you'll get a match on a key if there
are duplicates for that key in the table. Likewise, if the keys are out of
order, you might get a match, or you might not, and which of those results
you encounter is undefined by the standard.
'02 standard COBOL is, I think, a big improvement in this area -- at least
you'll either get a match or you won't; in '85 standard COBOL there's no
telling what will happen when these rules aren't followed.
-Chuck Stevens
Chuck Stevens
"Glenn Someone" <donts...@whydoyouneedmyaddressspammers.com> wrote in
message news:9cjgf09ts9d5eo7te...@4ax.com...
> I think you confused the two. SEARCH is a serial search, while SEARCH
> ALL is the binary one.
Precisely stated, SEARCH ALL is *permitted by the standard* to be a
non-serial search based on the restrictions imposed on the data ordering.
SEARCH ALL is not *required* by the standard to be a binary search, nor is
it required by the standard to be a non-serial search. I daresay most
modern implementations likely do (or at least begin with) some sort of
binary search of the table, but that's an implementor-defined enhancement.
-Chuck Stevens
Chuck Stevens
> Although SEARCH ALL is definitely NOT defined as a "binary search" (and is
not
> implemented as such in all current or past COBOL compilers), it is
documented as
> "non-sequential"
No, not exactly, Bill. " ... a nonserial type of search operation may take
place ..." (ANSI X3.23-1974 page III-9, 3.3, SEARCH statement, GR3; ANSI
X3.23-1985 page VI-124, 6.22, The SEARCH Statement, GR4; ISO/IEC 1989:2002
page 515, 14.8.34, The SEARCH statement, GR9). The word "may" is of critical
importance here.
-Chuck stevens
William M. Klein
(i.e. informative) section of the 2002 Standard makes the same "assumption"
(always dangerous) that I did.
Page 717 states,
"The SEARCH statement provides facilities for producing serial and nonserial
(for example, binary) searches."
For others (than Chuck), the following description of the "implentor defined"
status of SEARCH ALL from page 686 of the 2002 Standard might be of interest,
"137) SEARCH ALL statement (varying of the search index during the search
operation). This item is required. The internal procedure employed by the
implementor does not have to be documented in the implementor's user
documentation. (14.8.34, SEARCH statement, general rule 9)"
--
Bill Klein
wmklein <at> ix.netcom.com
"Chuck Stevens" <charles...@unisys.com> wrote in message
news:ce3k6j$13aq$1...@si05.rsvl.unisys.com...
Chuck Stevens
> One of the many failures of the "COBOL standard" if the
> hard-wired verbs defined in the standard do not perform in a
> consistent manner across all platforms. If I notice a verb is
> inconsistent, I stop using it and code its equivalent.
I am not at all convinced the standards for the SEARCH ALL verb is
inconsistent. There's a long history here.
The earliest documentation I have for SEARCH ALL is the manual for the
COBOL-61 implementation on the Burroughs B6500. It says nothing about the
ordering of the data, the presence of duplicates, or the form of SEARCH to
be performed.
The Burroughs B6700 COBOL(68) manual explicitly states that a *serial*
search is performed.
The IBM DOS COBOL ANSI-68 reference manual states that a *binary* search is
performed, but doesn't say what happens if there are duplicates or
out-of-order entries.
Note that these did *not* produce portable results, and I am reasonably
certain that the earliest standards didn't say antying about the ordering of
data, duplicates, or what sort of search algorithm should, or might, be
used.
Implementors of ANSI-74 COBOL were permitted to continue to do whatever it
is that they do in earlier compielrs, but the context of "defined results"
was restricted to those cases in which the results would be the same either
way. If those rules were followed, the results are *portable*.
Best I can see, the '74 and '85 designs are the same; in '02, the possible
consequences of violating the restrictions were further limited.
If the implementor chooses to define the behavior outside of that restricted
context in which the *standard* provides predictable results, they're free
to do so. But if you've got duplicates or misorderings in your table and
you are expecting the results you got on your Burroughs B5500 (DOD COBOL) ,
or in ANSI-68 COBOL on your B6700, or in ANSI-74 COBOL on your Libra 185
(all of which do *serial* searches, in compliance with their respective
standards), you won't get the same answer as you'd get under IBM DOS ANSI-68
COBOL, or, for that matter, as you'd get using COBOL85 on the same Libra 185
(both of which do *binary* searches, also in compliance with their
respective standards).
The behavior is compliant with the standard either way. ISTM the standard
folks *deliberately* avoided picking one approach at the expense of the
other, choosing instead to document the context in which the results were
the same, and describing everything outside that context as unpredictable
*for standards-compliant COBOL on an unspecified platform*.
> Examples of failures out of many failures of the standard.
I don't think it's a *failure* of the standard; rather, I think it's a
rather effective way to provide predictable behavior/ It provides a
description of the execution-time context in which the behavior is indeed
predictable, and at the same time allows preexisting code that may be
executing outside of that context to continue to do whatever it is that the
implementor has provided be done in those other contexts. If there are
duplicates in the table, a serial search will always provide the first
match, a binary search may provide a different one. Both results fall under
the description "unpredictable". The implementor *may* choose to describe
which users will get, but is under no obligation to do so, according to the
standards.
Assuming that you will *always* get a matching entry on a SEARCH ALL even if
there are duplicates or out-of-order entries in the table may be valid in
some implementations, but it's not a "portable" assumption. Both a serial
search and a binary search meet the criteria of SEARCH ALL, and produce
*different* results for both duplicate and misordered entries. The standard
ain't broken; it's the user's job to Read The Manual.
-Chuck Stevens
Michael Mattias
. [ and many others]
> [serial/non-serial/binary SEARCH/SEARCH ALL Sorted/Not sorted
Hit/Miss/FirstHit/SomeHit]
The whole point of any high-level language with an accepted standard (e.g.,
COBOL) is to provide the "what" whilst removing the "how"...
... so doesn't that make it just kind of plumb dopey to continue this
discussion in a 'mainstream' news group? Seems to me the rules is the rules,
and attempts to 'beat the standard' or 'trick the compiler' belong in a
newsgroup with a name like 'alt.hacks.cobol'
Or have I simply overestimated the overall skill & knowledge levels of the
typical comp.lang.cobol user?
Five bucks sez anyone who thinks they need to 'beat the standard' would
benefit far more from 'rethink the design.'
MCM
docd...@panix.com
Michael Mattias <michael...@gte.net> wrote:
>"Chuck Stevens" <charles...@unisys.com> wrote in message
>news:ce3oj5$17qr$1...@si05.rsvl.unisys.com...
>. [ and many others]
>
>> [serial/non-serial/binary SEARCH/SEARCH ALL Sorted/Not sorted
>Hit/Miss/FirstHit/SomeHit]
>
>The whole point of any high-level language with an accepted standard (e.g.,
>COBOL) is to provide the "what" whilst removing the "how"...
>
>... so doesn't that make it just kind of plumb dopey to continue this
>discussion in a 'mainstream' news group? Seems to me the rules is the rules,
>and attempts to 'beat the standard' or 'trick the compiler' belong in a
>newsgroup with a name like 'alt.hacks.cobol'
Mr Mattias, according to my memory - which is, admittedly, porous - and
http://info.astrian.net/jargon/terms/h.html#hack one of the definitions of
'hack' is 'An incredibly good, and perhaps very time-consuming, piece of
work that produces exactly what is needed' (as opposed to, of course, 'a
quick job that produces what is needed, but not well'... but this is no
more unusual than, say 'cleave' being its own antonym). As some folks
here may recall from the Oldene Dayse it was... rather handy, if not
necessary, to 'trick the compiler' when it came to limited table-size.
(But... I must admit that my first response to 'alt.hacks.cobol' was a
mental image of the night-before-go-live crew staring at 3270s through a
haze of Camel-straight and Lucky smoke, interspersing obscenities with
various coughs and wheezes.)
>
>Or have I simply overestimated the overall skill & knowledge levels of the
>typical comp.lang.cobol user?
I've no idea... what survey did you use as a baseline?
>
>Five bucks sez anyone who thinks they need to 'beat the standard' would
>benefit far more from 'rethink the design.'
A few of the original suggestions pointed towards that - I especially
liked the one which expanded the original table to include the location in
a new table of associated 'overflow rows', similar to Oracle's handling of
such things - but one might need to consider the possibility of working in
a shop where a corner-office stinkwad's 'Do it *this* way' must be
adhered to on penalty of dismissal... not everyone's managerial techniques
are of the caliber that Mr Wagner's seem to be.
DD
Ubiquitous
aru...@mailcity.com wrote:
>Does Cobol linear search provides better performance against Perform Until
Binary searches are ALWAYS much better than sequential ones.
When I say "always", I mean 99.9999% of the time.
--
======================================================================
ISLAM: Winning the hearts and minds of the world, one bomb at a time.
Robert Wagner
wrote:
>In article <9c9fdae5.04071...@posting.google.com>,
>aru...@mailcity.com wrote:
>
>>Does Cobol linear search provides better performance against Perform Until
Not when you include sort time.
docd...@panix.com
Mr Wagner, that is a curious response... I always thought that only a
binary search required sorted input; assuming that 'linear' allows for a
brute-force search of the entire table what kind of 'sort time' do you see
this as requiring?
DD