Re: Regarding EVALUATE TRUE



<klshafer@xxxxxxx> wrote in message
news:1187723493.834715.99700@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Aug 17, 9:32 pm, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
<klsha...@xxxxxxx> wrote in message

Hmmmmm... I think I Reply'd To Author yesterday, so the post did not
go "public"; I will attempt to repeat the substance for the benefit,
if you will, of all :-)

OK. I didn't receive the post...maybe forgot to edit the reply email
address?

I was a little disappointed that, in response to your request, and having
taken the (admittedly short, and for amusement only) time to apply
Boolean
simplification to:
<< difficult-to-understand code snipped >>
and obtained...
<< easier-to-understand code snipped >>
... you then chose to ignore this result completely and snipped it from
your
response.

I am sorry to disappoint you. The original post of the condensed
version suffered from the same kind of defect as my Working-Storage
entry earlier, some kind of word wraparound and extra CR/LF's. This
made it difficult to read. Now that you have presented a well-
formatted version, I'll spend time on it...

Ah, I was interested to see what would happen with that. I'm sorry, the
original post didn't format well because I copied it from a word document,
where I built the Boolean truth table and simplification.

It was only after it was posted that I saw how awful it looked and
reformatted it.

The interesting point is that when we encounter things that don't look
familiar, we tend to ignore them. If the posted (badly formatted) code had
been cut and pasted into a COBOL editor, it would have resolved into the
same format as the second post.

This tends to confirm something that Richard has been saying here for years;
what we are used to is what we feel is good.

I appreciate your honesty. Thanks.


I think this is pretty amazing. Especially when you think it was
postulated
by two people who lived more than 100 years before the first electronic
computer was ever assembled.

Yes, sometimes simple tools are powerful.

Given that you claimed in an earlier post to be "cleaning up" the mess, I
would have thought this would be of some relevance.

Yes, it is relevant.

OK, that's good :-)



Instead, it seems you were distracted by the shiny bauble of a coding
technique you hadn't seen before :-)

Well, I picked the "low hanging fruit" first from your help. The part
about how the "flag" wasn't really a flag was significant, it was
easier, it helped, and it was consistent with the effort of
understanding the outer EVALUATE first.

I understand. Obviously, for me, my time was devoted to a Boolean
simplification of the original convoluted code, so I was interested to see
your (and possibly others) response to that. I don't think people realise
how much can be gained by investing a little time in understanding the rules
of Boolean Algebra (not just De Morgan's, but the whole thing.) Anyone who
enjoys logic problems (and that is most programmers, in my experience)
should take to it, like ducks to water.

It is actually a lot of fun :-).

For example, here's a problem I formulated 30 years ago for a quick seminar
on Boolean Algebra and propositional calculus:

Four men are accused of a crime.

Abe said: "Bert did it".
Bert said "Dan did it".
Charlie said: "I didn't do it".
Dan said: " Bert's lying when he says I did it."

Unfortunately, only one of them is telling the truth. :-)

Who is the honest man, and who is the culprit?

At first glance, it looks complex, yet in fact, it is remarkably simple.

And the same laws that can cut a three page nested IF in COBOL down to less
than 30 lines (actual case...on a site in Spain), can also reveal who is
honest and who isn't.

Perhaps optimization of convoluted code might be on the agenda some time
in
the future?

Yes, perhaps it might be. After sufficient understanding is reached.
Please let me explain. Let's review some context of what I said -

"And under what circumstances is the WHEN OTHER satisfied?
Will Mr. Dashwood please step forward to apply his De Morgan's
Laws? :-)"

Some of the defects are manifesting when this code segment doese
program does the "drop through", i.e., executes the "do nothing" WHEN
OTHER ... CONTINUE in the original, or simply "executes nothing
gracefully", as in your amended version. This is what I had in mind
when I also said earler, "It is left as an exercise for all the
Students reading this forum to determine the conditions under which
the WHEN OTHER is executed :-)."

Mr. Dashwood, I do believe that it will be easier for me to obtain
this answer by negating the AND's in your condensed version than it
would be for me to operate on the original EVALUATE. GThis is helpful
to me.

Good. :-)

Or, you could substitute it as written and use CONTINUE :-) (That was NOT
serious...:-))


The problem here is that the program is sometimes (improperly)
dropping through, doing nothing, and not doing something that it
should. This is equivalent to "all the other decision criteria" not
being entirely correct. The spec doesn't say (there isn't any), and
the users can't tell me what those conditions are. We are definitely
pulling ourselves up by our bootstraps here.


You have my sympathy. Been there... :-)

On the other hand, I think what I learned is yet another way that a
programmer "can be too clever for his own good", or more accurately, a
programmer "can be too clever for the good of the maintainers that
follow...".

So much for style.

Now, how about a programmer actually cleaning up bad code? Your thoughts
on
a postage stamp, by return, please :-)


I do not understand your comments, or why you would write them.


Well the comment was intended as a jest at you being sidetracked. It wasn't
meant to wound, and to be fair, you weren't sidetracked from what was of
interest to YOU. I was slightly miffed at my time being wasted :-)

Just a note in passing...

As I never attended an American College, I find the use of the formal "Mr"
to be unfriendly and cold. (It brings out the worst in me and leads to a
cold response, or none at all.). A bit like being addressed as "Sir" when
you are an NCO... I think the technical term is "exalting".

If people wish to communicate with me here, please, use my name. Adopting
the formal, indicates displeasure or hostility as far as I am concerned.

The only exception is Doc Dwarf and I cut him slack because he is the King
of England, and because we both go back around a decade in this group.
(Besides, his posts to me are cold and unfriendly no matter what form of
address he chooses... :-))

BOTTOM LINE: If you want my feedback or thoughts, address me as Pete. If you
are pissed off with something I wrote, and don't want a friendly discussion
about it, address me as Mr. (and you may or may not get a response). If I am
really pissed off with something you wrote, you'll know...:-)


<snip>

The result would be less lines of code (in keeping
with your preference for parsimony, Mr. Dashwood), and a more direct
approach (in keeping with my preference for understandability over
cleverness.)

I have found in my (admittedly still ongoing) experience that parsimony
often helps understandability.


Yes, parsimony helps me too. Thoroughness, completeness, and
exhaustive coverage helps me more.

The two are not mutually exclusive and, in fact, one may be very conducive
to the other. It is easier to completely cover a small amount of code than
it is a large amount.

Thanks for taking time to help, Mr. Dashwood... I appreciate it.

If something was gained, it is time well spent.

Pete.
--
"I used to write COBOL...now I can do anything."


.

Relevant Pages

  • Re: Regarding EVALUATE TRUE
    ... After sufficient understanding is reached. ... Will Mr. Dashwood please step forward to apply his De Morgan's ... programmer "can be too clever for his own good", or more accurately, a ... I have found in my experience that parsimony ...
    (comp.lang.cobol)
  • Re: [OT] One for the iPhone/iTouch users
    ... This is something that is so far beyond my understanding it's ... he's a 'born programmer'. ... IDE button pusher for the X du jour is the ideal way of making making ... with those infinitely powerful machines we have these ...
    (uk.rec.motorcycles)
  • Re: [Lit.] Buffer overruns
    ... >> I (in my understanding) don't see any direct relevance ... If there are such textbooks, then I would think it's o.k. ... programmer, which a PL standard should avoid. ...
    (sci.crypt)
  • Re: question to Roedy and others about boolean testing
    ... six explicit tests against true isn't many (assuming that the programmer ... conditionals are symptoms of / contributors to unclean code (meaning ... The boolean expression doesn't ... shows the meaning more clearly. ...
    (comp.lang.java.programmer)
  • Re: Negation of boolean
    ... Subject: Negation of boolean ... > ^= is the code most likely to baffle an average programmer. ... you can't consider yourself a profession Java ... negating using!, is that always the case and if so, why doesn't the ...
    (comp.lang.java.help)