Re: Cobol Linear search Vs Perfrom Until
docdwarf_at_panix.com
Date: 07/17/04
- Next message: LX-i: "Re: Cobol Linear search Vs Perfrom Until"
- Previous message: LX-i: "Re: Cobol Linear search Vs Perfrom Until"
- In reply to: Glenn Someone: "Re: Cobol Linear search Vs Perfrom Until"
- Next in thread: LX-i: "Re: Cobol Linear search Vs Perfrom Until"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 17 Jul 2004 17:46:55 -0400
In article <gfpif0dqvhebfioqekqfupfcsmu21ada6s@4ax.com>,
Glenn Someone <dontspamme@whydoyouneedmyaddressspammers.com> wrote:
>On 17 Jul 2004 09:53:48 -0400, docdwarf@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
- Next message: LX-i: "Re: Cobol Linear search Vs Perfrom Until"
- Previous message: LX-i: "Re: Cobol Linear search Vs Perfrom Until"
- In reply to: Glenn Someone: "Re: Cobol Linear search Vs Perfrom Until"
- Next in thread: LX-i: "Re: Cobol Linear search Vs Perfrom Until"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
