RE: short-circuit control forms

RE: short-circuit control forms

[Beard, Frank]

-----Original Message-----
From: James A. Krzyzanowski [mailto:James_A_Krzyzanowski@raytheon.com]

> Our software engineers believe that using short-circuit control forms
> will make our software more efficient (speed-wise).  So, they have been
> replacing every "and" with "and then" and every "or" with "or else".

I've heard this before, as well.  And it makes sense, unless there is
some problem or inefficiency with generating the underlying branch
statements.

It seems to me that the "and" and "or" should have been implemented
in the short circuit form to begin with, instead of requiring 
"and then" and "or else".  As soon as one of the conditions is FALSE
for "and" or TRUE for "or", there is no need to check the remaining
arguments.

Frank Beard

Re: RE: short-circuit control forms

[Ted Dennison]

In article <mailman.993066684.13202.comp.lang.ada@ada.eu.org>, Beard, Frank
says...
>"and then" and "or else".  As soon as one of the conditions is FALSE
>for "and" or TRUE for "or", there is no need to check the remaining
>arguments.

That's assuming the conditional expressions have no side-efects. Questions of
the wisdom of making boolean ops with side effects aside (and much of the Win32
API is implemented this way), it would be a very Bad Thing to go blindly
converting conditionals to the short circuit form in existing Ada code, without
first carefully analyzing the conditions to verify that things will still work
properly if the later condition doesn't get executed. 

I can't find anything in the LRM that says that compilers *can't* optimize away
unneeded conditions in the way you describe (any language lawyers in the
house?), but it wouldn't shock me to find loads of code that assumes it won't
happen. I'm not sure what the LRM's silence on a subject means in this case. But
assuming it means "all bets are off", then it looks to me like compilers are
perfectly free to short-circuit, or even reorder and short-circuit normal
conditional expressions.

--
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: short-circuit control forms

[Jeffrey Carter]

Ted Dennison wrote:
> 
> I can't find anything in the LRM that says that compilers *can't* optimize away
> unneeded conditions in the way you describe (any language lawyers in the
> house?), but it wouldn't shock me to find loads of code that assumes it won't
> happen. I'm not sure what the LRM's silence on a subject means in this case. But
> assuming it means "all bets are off", then it looks to me like compilers are
> perfectly free to short-circuit, or even reorder and short-circuit normal
> conditional expressions.

IANAL, nor do I play one on TV. However, "and" and "or" are normal
subprograms (you can overload them), and the semantics for subprograms
state that all actual parameters are evaluated, and the order of
evaluation is not specified by the language (ARM 6.4). Thus, it is
illegal for a compiler to convert them to short-circuit forms.

-- 
Jeffrey Carter

Re: short-circuit control forms

[Mark Lundquist]

"Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
news:3B312495.15258B18@boeing.com...
>
> IANAL, nor do I play one on TV. However, "and" and "or" are normal
> subprograms (you can overload them), and the semantics for subprograms
> state that all actual parameters are evaluated, and the order of
> evaluation is not specified by the language (ARM 6.4). Thus, it is
> illegal for a compiler to convert them to short-circuit forms.

I don't think that's correct...

The compiler can do whatever it wants, as long as it's equivalent [RM
1.1.3].

-- mark

Re: short-circuit control forms

[Jeffrey Carter]

Mark Lundquist wrote:
> 
> "Jeffrey Carter" <jeffrey.carter@boeing.com> wrote in message
> news:3B312495.15258B18@boeing.com...
> >
> > IANAL, nor do I play one on TV. However, "and" and "or" are normal
> > subprograms (you can overload them), and the semantics for subprograms
> > state that all actual parameters are evaluated, and the order of
> > evaluation is not specified by the language (ARM 6.4). Thus, it is
> > illegal for a compiler to convert them to short-circuit forms.
> 
> I don't think that's correct...
> 
> The compiler can do whatever it wants, as long as it's equivalent [RM
> 1.1.3].

Since preserving side effects is part of "equivalent", and deciding if
functions have side effects is "hard" (I'm not aware of any compilers
that do this), this is true in theory but irrelevant in practice. If a
function with a side effect is (part of) an operand of "and" or "or", a
compiler must generate code that calls the function. In real compilers,
that seems to mean that both operands are always evaluated. Is anyone
aware of a compiler that optimizes away evaluation of an operand to
"and" or "or" when neither operand has a function call? In cases where
one of the operands has a function call? Both operands?

As I said, IANAL. It would be nice to hear from Robert Duff, Tucker
Taft, or Robert Dewar about this.

-- 
Jeffrey Carter

Re: short-circuit control forms

[Wes Groleau]

> IANAL, nor do I play one on TV. However, "and" and "or" are normal
> subprograms (you can overload them), and the semantics for subprograms
> state that all actual parameters are evaluated, and the order of
> evaluation is not specified by the language (ARM 6.4). Thus, it is
> illegal for a compiler to convert them to short-circuit forms.

However, the RM discussion of 'and' and 'or' implies that
redefined (overloaded) versions have different rules
than the "originals"

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: short-circuit control forms

[Dale Stanbrough]

Ted Dennison wrote:

>  I'm not sure what the LRM's silence on a subject means in this case. But
> assuming it means "all bets are off", then it looks to me like compilers 
> are
> perfectly free to short-circuit, or even reorder and short-circuit normal
> conditional expressions.


The LRM guarentees order of execution for short circuit form, which is
from left to right.

Not all short circuit forms need be faster, this can depend on the 
architecture that is being compiled for. For example the following
code

   if x = 2 and y = 3 then

could have both comparisons scheduled on a modern processor with 
numerous integer units so that they occur simultaneously.

As always, measure before you optimise.

Dale

Re: short-circuit control forms

[Marin David Condic]

Consider the following:

if (Some_Boolean_Function (X) and then Another_Boolean_Function (Y)) then
    Do_Some_Stuff ;
end if ;

If the *first* function almost always evaluates to False, then you almost
never call the second function. This is efficient - a good thing sometimes.
However, if the second function sometimes generates a Constraint_Error
because of a programmer mistake, and it only sometimes gets called, you may
have an error condition that makes it out into the field - which is A Bad
Thing (tm).

Another consideration is timing. Nominally, you only call the first function
and not the second. In some corner cases, you call the second and this may
consume some excessive amount of time. It may blow the timing budget
altogether. Lots of hard realtime systems insist that you always execute the
worst-case path just to make sure this sort of thing doesn't happen. This is
the same reason why lots of realtime systems don't like cache on a chip - it
leads to non-deterministic behavior that you may not find until it is too
late.

Better to have the short-circuit things optional so you can manually enable
and disable the behavior as needed. Most of the time the extra efficiency is
likely to be a) too small to sweat and b) not an issue because it isn't a
hard realtime system.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Beard, Frank" <beardf@spawar.navy.mil> wrote in message
news:mailman.993066684.13202.comp.lang.ada@ada.eu.org...
> I've heard this before, as well.  And it makes sense, unless there is
> some problem or inefficiency with generating the underlying branch
> statements.
>
> It seems to me that the "and" and "or" should have been implemented
> in the short circuit form to begin with, instead of requiring
> "and then" and "or else".  As soon as one of the conditions is FALSE
> for "and" or TRUE for "or", there is no need to check the remaining
> arguments.

Re: short-circuit control forms

[Keith Thompson]

"Beard, Frank" <beardf@spawar.navy.mil> writes:
[...]
> It seems to me that the "and" and "or" should have been implemented
> in the short circuit form to begin with, instead of requiring 
> "and then" and "or else".  As soon as one of the conditions is FALSE
> for "and" or TRUE for "or", there is no need to check the remaining
> arguments.

If I were designing a language from scratch, I might do something
like the following:

For an "and" operation, it's unspecified whether the right operand is
evaluated if the left operand is false.  It's also unspecified whether
the left operand is specified if the right operand is false.  Order of
evaluation is unspecified.  Side effects in either operand are
strongly discouraged.  Compilers should do whatever results in the
most efficient generated code.  Most code should use "and" unless
there's a good reason not to.

For an "and then" operation, the left operand is always evaluated; the
right operand is evaluted only if the left operand is true (just like
Ada's "and then").

Finally a third form would specify that both operands are always
evaluated (subject to optimization rules).  Perhaps something like
and(lhs, rhs).

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Cxiuj via bazo apartenas ni.

RE: short-circuit control forms

[Beard, Frank]

-----Original Message-----
From: Marin David Condic [mailto:marin.condic.auntie.spam@pacemicro.com]

> Better to have the short-circuit things optional so you can manually
enable
> and disable the behavior as needed. Most of the time the extra efficiency
is
> likely to be a) too small to sweat and b) not an issue because it isn't a
> hard realtime system.

Well, the argument could be made that if your second condition raised an
exception then your unit testing was insufficient (and yes I know unit 
tests can't always catch everything).  And as a general rule, it's a bad
idea to write functions with side effects, unless you have some glaring 
necessity to do so.  Most, if not all, of the conditional statements that
I've written fall into the "and then" and "or else" category.

But as a point Marin has already made, I don't even worry about any of
these cases unless there is some runtime penalty.  In most cases, I
just use "and" and "or" because the code is cleaner looking.

I still would have preferred the short-circuit to be the default. 
"And then" could have meant, "if this part is true then check the
next part".  Or change "and then" to "and also".

  if A and also B then

"Or else" is confusing either way.

All that aside, I can live with the way it is currently.  It's not a
big deal.  I was just stating a preference.  And as I said, I don't
actually worry about it until it becomes a problem.

Frank Beard

Re: short-circuit control forms

[Marin David Condic]

As long as you have some method of specifying short circuit forms, I can
work with it. And as you observe, don't worry until you have to. In most
programs, you'll *never* notice the difference - so do something that looks
more comprehensible or fits within coding conventions rather than persue
optimizations that won't benefit you.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Beard, Frank" <beardf@spawar.navy.mil> wrote in message
news:mailman.993075744.15649.comp.lang.ada@ada.eu.org...
> All that aside, I can live with the way it is currently.  It's not a
> big deal.  I was just stating a preference.  And as I said, I don't
> actually worry about it until it becomes a problem.

Re: short-circuit control forms

[Warren W. Gay VE3WWG]

"Beard, Frank" wrote:
> -----Original Message-----
> From: Marin David Condic [mailto:marin.condic.auntie.spam@pacemicro.com]
> 
> > Better to have the short-circuit things optional so you can manually
> enable
> > and disable the behavior as needed. Most of the time the extra efficiency
> is
> > likely to be a) too small to sweat and b) not an issue because it isn't a
> > hard realtime system.
> 
> Well, the argument could be made that if your second condition raised an
> exception then your unit testing was insufficient (and yes I know unit
> tests can't always catch everything).

But Marin's point was that if you want to be closer to 100% sure that
this piece of code will not raise an exception or blow the CPU budget,
then you need to make sure that it is _always_ executed. Otherwise, you
have to create the right kind of conditions to test that 0.01% -- which,
might be near impossible without modifying the code (which itself
invalidates the test). If I were flying on that code, then I'd want 
the AND to be used, and not the AND THEN clause. The object is to have
greater confidence in the testing.

> And as a general rule, it's a bad
> idea to write functions with side effects, unless you have some glaring
> necessity to do so.

Nobody disagrees with this, but even functions without side-effects
can create exceptions. That was the point. Also, it is possible for
functions to have different CPU budgets, depending upon the inputs.
This should be tested thoroughly.

> Most, if not all, of the conditional statements that
> I've written fall into the "and then" and "or else" category.

I could see this in a non-critical piece of software. But where
rigorous testing is involved, you will simplify your life by using
the naked AND instead (where possible at least).

> But as a point Marin has already made, I don't even worry about any of
> these cases unless there is some runtime penalty.  In most cases, I
> just use "and" and "or" because the code is cleaner looking.

Coming from a C/C++ background, I tend to err on the side of
short circuiting, but realize that this is not always wise. Even if
you spend most of your life in business like, non-critical systems,
you could end up writing re-usable code that may be applied differently
than you imagined, by someone else.

For this reason, you _should_ probably assume the worst case, as
suggested by Marin, so that you don't inflict trouble on the next
user of your code. The other benefit, as been pointed out, it is
easier to test your code and gain greater confidence from your
tests (greater path coverage).

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: short-circuit control forms

[Marin David Condic]

Thanks for the support. You pretty well summed it up.

*If* the timing is critical enough to be concerned about the efficiency of
short-circuit vs regular forms, then you *probably* want to make sure you
always execute the worst case scenario because you have not got the CPU to
spare if it doesn't work in the worst case.

In my mind, the only situation where this sort of really low level
optimization matters is the situation where you wouldn't want to be doing
this anyway. If you can afford the worst case, what does it gain you to do
the best case? Can you put those handful of spare CPU cycles to work
somewhere else on an "as available" task? The context switch would likely
eat more than what you saved.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
news:3B322AC5.2B8DC7B1@home.com...
> "Beard, Frank" wrote:
> > -----Original Message-----
> > From: Marin David Condic [mailto:marin.condic.auntie.spam@pacemicro.com]
> >
> > > Better to have the short-circuit things optional so you can manually
> > enable
> > > and disable the behavior as needed. Most of the time the extra
efficiency
> > is
> > > likely to be a) too small to sweat and b) not an issue because it
isn't a
> > > hard realtime system.
> >
> > Well, the argument could be made that if your second condition raised an
> > exception then your unit testing was insufficient (and yes I know unit
> > tests can't always catch everything).
>
> But Marin's point was that if you want to be closer to 100% sure that
> this piece of code will not raise an exception or blow the CPU budget,
> then you need to make sure that it is _always_ executed. Otherwise, you
> have to create the right kind of conditions to test that 0.01% -- which,
> might be near impossible without modifying the code (which itself
> invalidates the test). If I were flying on that code, then I'd want
> the AND to be used, and not the AND THEN clause. The object is to have
> greater confidence in the testing.
>
> > And as a general rule, it's a bad
> > idea to write functions with side effects, unless you have some glaring
> > necessity to do so.
>
> Nobody disagrees with this, but even functions without side-effects
> can create exceptions. That was the point. Also, it is possible for
> functions to have different CPU budgets, depending upon the inputs.
> This should be tested thoroughly.
>
> > Most, if not all, of the conditional statements that
> > I've written fall into the "and then" and "or else" category.
>
> I could see this in a non-critical piece of software. But where
> rigorous testing is involved, you will simplify your life by using
> the naked AND instead (where possible at least).
>
> > But as a point Marin has already made, I don't even worry about any of
> > these cases unless there is some runtime penalty.  In most cases, I
> > just use "and" and "or" because the code is cleaner looking.
>
> Coming from a C/C++ background, I tend to err on the side of
> short circuiting, but realize that this is not always wise. Even if
> you spend most of your life in business like, non-critical systems,
> you could end up writing re-usable code that may be applied differently
> than you imagined, by someone else.
>
> For this reason, you _should_ probably assume the worst case, as
> suggested by Marin, so that you don't inflict trouble on the next
> user of your code. The other benefit, as been pointed out, it is
> easier to test your code and gain greater confidence from your
> tests (greater path coverage).
>
> --
> Warren W. Gay VE3WWG
> http://members.home.net/ve3wwg

RE: short-circuit control forms

[Wilhelm Spickermann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 759 bytes --]


On 20-Jun-01 Beard, Frank wrote:
...
> It seems to me that the "and" and "or" should have been implemented
> in the short circuit form to begin with, instead of requiring 
> "and then" and "or else".  As soon as one of the conditions is FALSE
> for "and" or TRUE for "or", there is no need to check the remaining
> arguments.
...
But this would lead to programs using "and" where "and then" is required now
and using "or" where "or else" is required now. If you want to prove certain
conditions at a point of a program, it�s much easier if you can use the
rules of mathematical logic. I prefer the way Ada is now and I think that
everyone using "and then" or "or else" for efficiency reasons should write a
comment stating the reasons clearly.

Wilhelm

short-circuit control forms

[James A. Krzyzanowski]

Looking for expert opinions...

We have a company standard which states:
"standard => Use short-circuit control forms to specify the order of
             conditions when the failure of one condition means that
             the other condition will raise an exception.
 guideline => Avoid short-circuit control forms otherwise."

Our software engineers believe that using short-circuit control forms
will make our software more efficient (speed-wise).  So, they have been
replacing every "and" with "and then" and every "or" with "or else".

We use Rational Apex and a Rational Representative sent correspondence
basically saying that their compiler will NOT optimize plain "and" and
"or" to behave as though the best "and then" and "or else" order has
been specified.

The reason for our standard on this topic is because we expected the
compiler to be smarter than the software engineer when it comes to
specifying an order of conditions.  This is also consistent with
Ada 95 Quality and Style: Guidelines for Professional Programmers.

If using "and then" and "or else" will make our software quicker, and
then the compiler doesn't optimize any better anyway, does anybody have
a good reason why we should NOT use short-circuit control forms?

-- 
---------------------------------------------------------------------------
         James A. Krzyzanowski - Staff Software Engineer - AFATDS       %c%
     Raytheon Systems Company * Fort Wayne, IN 46808 * (219) 429-6446   cus
                 mailto:James_A_Krzyzanowski@raytheon.com               %s%
---------------------------------------------------------------------------

Re: short-circuit control forms

[Ted Dennison]

In article <3B30F836.D700DAA3@raytheon.com>, James A. Krzyzanowski says...
>If using "and then" and "or else" will make our software quicker, and
>then the compiler doesn't optimize any better anyway, does anybody have
>a good reason why we should NOT use short-circuit control forms?

First off, its *not* assured that it will always be quicker. Since you are
replacing one branch with one branch for each condition, it will actually result
in *more* instructions being executed if it turns out that all the conditions
need to be applied. Depending on how many conditions there are and how much work
calculating them all is, in some cases the non-short-circuit form will execute
less code even when not all of the conditions are executed.

Another thing you have to consider is that most modern processors have a branch
prediction unit (BPU) that will do speculative execution to keep the instruction
pipeline filled when branches are encountered. If the "speculation" is
incorrect, the entire pipeline has to be flushed, which slows things down
greatly. Short-circuit forms generate more branch instructions, which can amount
to more chances for the BPU to guess wrong. Again, this may be trivial compared
to the chance of not executing a lot of extra code. But if the code in
calculating the conditions is small, or its usually all executed, then it can
matter.

Another important issue is maintanence. When someone unfamiliar with that code
first tries to read it, they are probably going to expect that there's some
*reason* that those short-circuit forms had to be used, and that there's some
reason that the conditionals are in the order they are in. As an example of a
problem that could cause, suppose one conditional needs to be split out for some
reason. That may lead to unnessecary complication of the code to preserve that
(presumed-important) ordering.

My last argument against this approach is philosophical, but relates directly to
all my previous points. As a general rule, you do *not* go about randomly
optimizing code, at the expense of complexity or readability. Programs generally
do not have their workload spread out evenly over the source, so this is an
incredibly bad use of man-hours (on both ends). The proper way to optimize is to
find a part that is running too slowly, find the slowest part of that, and see
what you can do to speed it up (then repeat until satisfied). Hand-optimization
should be done with tweezers and a microsope, not with a blindfold and a
sledgehammer. 

So unless there is some *verified* speed problem with a particular conditional,
write it the way in which it makes the most sense.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: short-circuit control forms

[Marin David Condic]

The first thing to ask is this: Are you *really* sure that whatever
inefficiency is introduced is going to matter? Many programmers have an
"efficiency fetish" (especially when they come out of a C programming mode)
that makes no sense in the target environment. I can't imagine a few extra
instructions in some condition checks are going to kill most programs. For
most apps it probably isn't even perceptable.

If that is the case, then the argument goes like this: "It isn't going to
hurt anything if you follow the written-down guidelines and the Ada95
Quality & Style guide. Future releases of the compiler may be able to do the
optimization for you (and do it better) and in the mean time, you will be
producing code that is remarkably like what our style guidelines dictate &
thus will make life easier for 'the other guy' when he has to read it. It
may also prevent hard to find errors in the code by forcing evaluation of
all conditions anyway. (Imagine a condition that *mostly* gets bypassed
because of an 'and then" and it isn't until some later point in the project
that the condition comes up - intermittently - causing some kind of runtime
error.)"

When you've got a situation where those few extra instructions are making a
difference in performance or threatening success of the project, then you go
ahead and pull every efficiency trick you can to get the code you need from
the compiler. That should be the *exception* to the style guide that is done
only where necessary.

Now if you want to debate the relative merits of what the style guide says -
that's another discussion. Someone might reasonably argue that this
guideline has no merit and should be abandoned. However that is a decision
that the development group as a whole should arrive at and not something
that should be violated by a lone wolf or two who just don't feel like
playing nice. The issue there is that if the style guide can just be
arbitrarily pitched by whoever wants to do so whenever they feel like it,
then what is the point of having one?

Managing programmers is like herding cats.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"James A. Krzyzanowski" <James_A_Krzyzanowski@raytheon.com> wrote in message
news:3B30F836.D700DAA3@raytheon.com...
> Looking for expert opinions...
>
> We have a company standard which states:
> "standard => Use short-circuit control forms to specify the order of
>              conditions when the failure of one condition means that
>              the other condition will raise an exception.
>  guideline => Avoid short-circuit control forms otherwise."
>
> Our software engineers believe that using short-circuit control forms
> will make our software more efficient (speed-wise).  So, they have been
> replacing every "and" with "and then" and every "or" with "or else".
>
> We use Rational Apex and a Rational Representative sent correspondence
> basically saying that their compiler will NOT optimize plain "and" and
> "or" to behave as though the best "and then" and "or else" order has
> been specified.
>
> The reason for our standard on this topic is because we expected the
> compiler to be smarter than the software engineer when it comes to
> specifying an order of conditions.  This is also consistent with
> Ada 95 Quality and Style: Guidelines for Professional Programmers.
>
> If using "and then" and "or else" will make our software quicker, and
> then the compiler doesn't optimize any better anyway, does anybody have
> a good reason why we should NOT use short-circuit control forms?
>
> --
> --------------------------------------------------------------------------
-
>          James A. Krzyzanowski - Staff Software Engineer - AFATDS
%c%
>      Raytheon Systems Company * Fort Wayne, IN 46808 * (219) 429-6446
cus
>                  mailto:James_A_Krzyzanowski@raytheon.com
%s%
> --------------------------------------------------------------------------
-

Re: short-circuit control forms

[Jeffrey Carter]

"James A. Krzyzanowski" wrote:
> 
> Looking for expert opinions...
> 
> We have a company standard which states:
> "standard => Use short-circuit control forms to specify the order of
>              conditions when the failure of one condition means that
>              the other condition will raise an exception.
>  guideline => Avoid short-circuit control forms otherwise."
> 
> Our software engineers believe that using short-circuit control forms
> will make our software more efficient (speed-wise).  So, they have been
> replacing every "and" with "and then" and every "or" with "or else".
> 
> If using "and then" and "or else" will make our software quicker, and
> then the compiler doesn't optimize any better anyway, does anybody have
> a good reason why we should NOT use short-circuit control forms?

Do you know that using short-circuit forms makes your software quicker?

If you have measured the speed with and without the short-circuit forms,
and found it to be statistically different at the p=0.1 level or better
AND the difference is necessary for the software to function correctly,
then your software engineers are justified in their actions.

If not, you do not have software engineers. You have coders who are
wasting their time and the company's money on ignorant FUD, and
introducing a new source of error into working software. At best you
should fire them and replace them with software engineers; at worst you
should require them to adhere to your company standard unless they have
justification for deviating.

-- 
Jeffrey Carter

Re: short-circuit control forms

[Al Christians]

Jeffrey Carter wrote:
> 
> If not, you do not have software engineers. You have coders who are
> wasting their time and the company's money on ignorant FUD, and
> introducing a new source of error into working software. 

I'll admit to most of that.  But, I find that it is a common
thinkographical error for me to not realize that the second condition
will be evaluated even when irrelevant, and that it often works 
out that an exception is raised when the second condition is
evaluated.   That probably comes from too much time coding in other
languages in which the short-circuitedness is controlled by a compiler
option that is typically set to short-circuit.   IOW, when programming
unconsciously, I am more likely to write a correct program if I
habitually use the short-circuit forms than if I don't.   Following
this style will also serve as a form of negative encouragement for 
functions with side effects, which is also good.  


Al

Re: short-circuit control forms

[Wes Groleau]

> > If not, you do not have software engineers. You have coders who are
> 
> I'll admit to most of that.  But, ..... when programming
> unconsciously, I am more likely to write a correct program if I
> habitually use the short-circuit forms than if I don't.   

If you are programming unconsciously, you are not
doing software engineering.  :-)

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: short-circuit control forms

[Al Christians]

Wes Groleau wrote:
> 
> 
> If you are programming unconsciously, you are not
> doing software engineering.  :-)
> 

Sure.  A software engineering project shouuld give explicit 
consideration to all four possibilities:  true & true, true & 
false, false & true, false & false.  But when someone is trying 
to write and think at the same time: 'if A and ...' their mind 
is focused by the form of the statement into thinking about what 
else  has to be true besides A for the action to be the right 
action.  You can't have too many things in mind at the same time, 
and what happens if A is not true is easily excluded from 
consideration as you write that statement. 

The argument against automatically including the safety mechanism of 
'and then' as the normal form is that it is misleading to someone 
trying to draw inferences about preconditions from the code.  If one 
is doing the 'software engineering' you mention, why is one trying 
to draw inferences about preconditions from the code? Don't 'software 
engineering' projects generate 5-20 pages of documentation and 
related paperwork per line of  code?  Isn't the information about 
the preconditions going to be properly recorded somewhere in those 
documents? If code is not documentation, why does 'software 
engineering' mean that we have to code like it is, even to the 
point of worrying about the possible but completely unjustified 
inferences that may be drawn by some future code reader? 

Wouldn't the best approach be to use 'and' most in testing, so that 
as many exceptions as possible are detected in testing, but use 
'and then' most in the delivered code, so that as few exceptions 
as possible are detected by the customer?


Al

Re: short-circuit control forms

[Wes Groleau]

> > If you are programming unconsciously, you are not
> > doing software engineering.  :-)

Just teasing--note the smiley.  On the other hand....

> Wouldn't the best approach be to use 'and' most in testing, so that
> as many exceptions as possible are detected in testing, but use
> 'and then' most in the delivered code, so that as few exceptions
> as possible are detected by the customer?

No.  If an exception is found in testing, handle it or fix it.
Don't obfuscate the code just to hide exceptions you didn't find
yet.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: short-circuit control forms

[Marin David Condic]

If you change the code, then you didn't test what you deliver. It is
generally considered to be A Bad Thing in the mission critical world to run
your tests, modify the code, then deliver it. If you aren't playing in this
field, then the whole efficiency argument goes up in smoke anyway - so you
don't want to waste time fooling with the and thens.

However, I can see your point about minimizing the exposure to possible
undetected errors. Still, I would prefer to fix the errors up front - or
never put them in to begin with. But that starts opening up the question of
what level of testing is good enough? And is it better for your reputation
to have an occasional flakey error cause a system crash and have enormous
difficulty reproducing the conditions for you to detect & correct it or is
it better to have more frequent crashes in early deliveries and have an
easier time of detecting the problems & fixing them?  (Presuming, of course,
that this isn't Mission Critical software we're discuissing.) I think it
might depend on your individual situation. (In house customer vs general
public, cost of failures, etc.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Al Christians" <achrist@easystreet.com> wrote in message
news:3B3216D9.113A612B@easystreet.com...
> Wouldn't the best approach be to use 'and' most in testing, so that
> as many exceptions as possible are detected in testing, but use
> 'and then' most in the delivered code, so that as few exceptions
> as possible are detected by the customer?
>

Re: short-circuit control forms

[Marc A. Criley]

Marin David Condic wrote:
> 
> However, I can see your point about minimizing the exposure to possible
> undetected errors. Still, I would prefer to fix the errors up front - or
> never put them in to begin with. But that starts opening up the question of
> what level of testing is good enough? And is it better for your reputation
> to have an occasional flakey error cause a system crash and have enormous
> difficulty reproducing the conditions for you to detect & correct it or is
> it better to have more frequent crashes in early deliveries and have an
> easier time of detecting the problems & fixing them?  (Presuming, of course,
> that this isn't Mission Critical software we're discuissing.) I think it
> might depend on your individual situation. (In house customer vs general
> public, cost of failures, etc.)

The original version of a shipboard weapon control system I worked on
had myriad exception handlers and checks for conditions that should not
have been able to occur, but did, and so were trapped and worked
around.  Needless to say, with the root causes left unaddressed, over
time the system's operation got more and more corrupt and degraded,
until it finally couldn't hold up any more, and would just lock up or
crash.

In the redesign of that system, exception handlers were permitted only
for those exceptions whose raising was anticipated as part of "normal"
failure operations.  And work-arounds to handle anomalous occurrences
were strictly barred.  As a result, the system under development crashed
more frequently than the extensively band-aided one it was going to
replace.

This caused consternation amongst program management, because they
thought the redesigned system was supposed to be better than the
original.  At the last presentation I made to the customer I explained
why we were getting the crashes:  We were finding the bugs _now_,
instead of following the previous practice of having the test group
uncover them and send problem reports back through a longer analyze and
fix cycle.  Our streamlined fix/test process was turning around bug
reports in a day.  And instead of patching and hoping it would hold
through test, we were getting close to having a twisted view of system
crashes--we almost liked them, because it flushed out another bug and we
had scads of log data available to quickly zero in on and fix the
problem.

When we delivered the system a few weeks later, there was only one
low-priority bug report open against the system, and it was an order of
magnitude better in performance, reliability, and understandability than
its predecessor.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: short-circuit control forms

[Marin David Condic]

Exception handlers can definitely be used to sweep problems under the rug.
When I was building a rocket engine control where failure was not an option,
we only had exception handling at the outer-most control loops because if an
exception got to that point, you were either going to reboot the box
(possibly in mid-burn and blow the mission) or you were going to try to
ignore whatever caused it and press on hoping that the control would do
something reasonable to keep the rocket going. Naturally, we logged any
occurence of any exception in memory and could monitor this via test
monitoring equipment and telemetry. I'm pleased to say it never came up as
an issue - we never had an exception - but it *could* have masked a real
problem during testing. (Of course, for efficiency, we had to turn off most
runtime checks, but that didn't mean you couldn't get any exceptions - or
that this was the best way to build software. I'd have liked to leave the
checks in so we'd know if there were problems in the code, rather than let
them get into the field, but compromises must be made sometimes.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Marc A. Criley" <mcqada@earthlink.net> wrote in message
news:3B332A96.64DDB78E@earthlink.net...
>
> The original version of a shipboard weapon control system I worked on
> had myriad exception handlers and checks for conditions that should not
> have been able to occur, but did, and so were trapped and worked
> around.  Needless to say, with the root causes left unaddressed, over
> time the system's operation got more and more corrupt and degraded,
> until it finally couldn't hold up any more, and would just lock up or
> crash.
>
> In the redesign of that system, exception handlers were permitted only
> for those exceptions whose raising was anticipated as part of "normal"
> failure operations.  And work-arounds to handle anomalous occurrences
> were strictly barred.  As a result, the system under development crashed
> more frequently than the extensively band-aided one it was going to
> replace.
>
> This caused consternation amongst program management, because they
> thought the redesigned system was supposed to be better than the
> original.  At the last presentation I made to the customer I explained
> why we were getting the crashes:  We were finding the bugs _now_,
> instead of following the previous practice of having the test group
> uncover them and send problem reports back through a longer analyze and
> fix cycle.  Our streamlined fix/test process was turning around bug
> reports in a day.  And instead of patching and hoping it would hold
> through test, we were getting close to having a twisted view of system
> crashes--we almost liked them, because it flushed out another bug and we
> had scads of log data available to quickly zero in on and fix the
> problem.
>
> When we delivered the system a few weeks later, there was only one
> low-priority bug report open against the system, and it was an order of
> magnitude better in performance, reliability, and understandability than
> its predecessor.
>
> Marc A. Criley
> Senior Staff Engineer
> Quadrus Corporation
> www.quadruscorp.com

Re: short-circuit control forms

[Robert Dewar]

Jeffrey Carter <jeffrey.carter@boeing.com> wrote in message news:<3B312260.728686B5@boeing.com>...
> If not, you do not have software engineers. You have coders who are
> wasting their time and the company's money on ignorant FUD, and
> introducing a new source of error into working software. At best you
> should fire them and replace them with software engineers; at worst you
> should require them to adhere to your company standard unless they have
> justification for deviating.


The above itself is FUD in this case.

It is quite obvious that in some cases short circuiting is critical
for efficiency without needing detailed measurements. For example, 
when searching in a binary tree, it can make the difference between
O(logN) and O(N) behavior in extreme cases (well in recursion cases
it can of course make the difference between finite and infinite
execution time in a non-lazy language).

Re: short-circuit control forms

[Ted Dennison]

In article <5ee5b646.0106221258.601d2bce@posting.google.com>, Robert Dewar
says...
>It is quite obvious that in some cases short circuiting is critical
>for efficiency without needing detailed measurements. For example, 
>when searching in a binary tree, it can make the difference between
>O(logN) and O(N) behavior in extreme cases (well in recursion cases

But if the binary tree isn't ever that large, then it might not be "critical for
efficiency" at all. However, in this case I'd agree with you completely that you
should probably still go with the short-circuit in the first place. 

Then again, this is a bit of a strawman argument. What are you doing using a
binary-tree instead of a simple linear linked-list in the first place, if the
performance hasn't already been determined to be "critical for efficiency"? It
seems in this case you have already started looking at efficiency, so its fairly
easy to agree with you that this is a case where its sensible to keep such
details in mind.

I have to wonder how much of the sides people take on this issue has to do with
the kind of applications they generally develop. The short-circuitist approach
does have the benifit of minimizing *average* runtime for an application. That
is a damn important number for anyone writing CPU-limited input processing
application like a compiler. However, for us folks doing real-time work, we
don't care at all about that number. What we have to worry about is meeting a
deadline in the *worst* case (or the deadline - our targeted spare). If we do
meet that deadline, great. If we don't, its usually due to one or two horribly
inneficient constructs somewhere in a tight loop, and the odds of it being a
non-short-circuit is pretty slim (could happen, but I haven't see it yet). The
other problem we have to deal with occasionaly is jitter (a routine taking a
variying time to complete, causing noticeble time variations somewhere else).
That issue is actualy made a smidge *worse* using a short-circuited construct.

Anyway, it seems that, of the positions I can identify, the most vocal
short-circuitists are compiler writers, and the most vocal nonshort-circuiters
are real-time programmers. But perhaps my analysis is a bit off, and the truth
of the matter is that you compiler writers just happen to be much more
knowledgable than us real-time developers. After all, at you are at least smart
enough to work on a system that can be used and debugged on your host machine.
We have to walk over to labs or fly halfway around the world just to try out our
code properly. How stupid is that? :-)

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: short-circuit control forms

[Jeffrey Carter]

Robert Dewar wrote:
> 
> Jeffrey Carter <jeffrey.carter@boeing.com> wrote in message news:<3B312260.728686B5@boeing.com>...
> > If not, you do not have software engineers. You have coders who are
> > wasting their time and the company's money on ignorant FUD, and
> > introducing a new source of error into working software. At best you
> > should fire them and replace them with software engineers; at worst you
> > should require them to adhere to your company standard unless they have
> > justification for deviating.
> 
> The above itself is FUD in this case.
> 
> It is quite obvious that in some cases short circuiting is critical
> for efficiency without needing detailed measurements. For example,
> when searching in a binary tree, it can make the difference between
> O(logN) and O(N) behavior in extreme cases (well in recursion cases
> it can of course make the difference between finite and infinite
> execution time in a non-lazy language).

It may well be true that short circuiting is necessary to obtain
acceptable run times when implementing a search in a binary tree, but
that seems to have no bearing on the subject under discussion. The post
that I was replying to described coders changing working Ada, which
implies that the software is already fast enough, because they believe
that short circuit forms are universally faster, without any evidence
that their beliefs are true. To change working software in a manner
known to be a potential source of errors without any evidence of
benefit, much less of necessary benefit, does not seem justifiable to
me.

I guess this means the above is FUD about FUD about FUD. Shall we try
for FUD ** 4?

Do your posts this afternoon represent situations you thought it very
important to comment on, or can we expect the pleasure of your posts on
a regular basis again?

-- 
Jeffrey Carter

Re: short-circuit control forms

[Larry Kilgallen]

In article <3B33CD82.328E3182@boeing.com>, Jeffrey Carter <jeffrey.carter@boeing.com> writes:

> It may well be true that short circuiting is necessary to obtain
> acceptable run times when implementing a search in a binary tree, but
> that seems to have no bearing on the subject under discussion. The post
> that I was replying to described coders changing working Ada, which
> implies that the software is already fast enough, because they believe
> that short circuit forms are universally faster,

Presumably this was in preparation for switching to a slower machine :-)

Re: short-circuit control forms

[Simon Wright]

Jeffrey Carter <jeffrey.carter@boeing.com> writes:

>                              To change working software in a manner
> known to be a potential source of errors without any evidence of
> benefit, much less of necessary benefit, does not seem justifiable to
> me.

Well, I would leave out "in a manner known to be a potential source of
errors"!

-S

Re: short-circuit control forms

[Wes Groleau]

> that seems to have no bearing on the subject under discussion. The post
> that I was replying to described coders changing working Ada, which
> implies that the software is already fast enough, because they believe
> that short circuit forms are universally faster, without any evidence
> that their beliefs are true. To change working software in a manner

To be more specific, this is "working Ada" for which size
is more of an issue than execution speed.  That changes a lot,
doesn't it?

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: short-circuit control forms

[Wes Groleau]

> It is quite obvious that in some cases short circuiting is critical
> for efficiency without needing detailed measurements. For example,

More than one person has stated (some with persuasive explanations)
that a short-circuit form can be slower or the same depending on
the application or compiler or processor.

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau

Re: short-circuit control forms

[Mark Lundquist]

"James A. Krzyzanowski" <James_A_Krzyzanowski@raytheon.com> wrote in message
news:3B30F836.D700DAA3@raytheon.com...
> Looking for expert opinions...
>
> We have a company standard which states:
> "standard => Use short-circuit control forms to specify the order of
>              conditions when the failure of one condition means that
>              the other condition will raise an exception.
>  guideline => Avoid short-circuit control forms otherwise."
>

That sounds like a good standard, modulo the issue of how to handle
side-effects in functions (let's not go there...)

> Our software engineers believe that using short-circuit control forms
> will make our software more efficient (speed-wise).  So, they have been
> replacing every "and" with "and then" and every "or" with "or else".

I would say that's not good practice (see below)...

>
> We use Rational Apex and a Rational Representative sent correspondence
> basically saying that their compiler will NOT optimize plain "and" and
> "or" to behave as though the best "and then" and "or else" order has
> been specified.
>
> The reason for our standard on this topic is because we expected the
> compiler to be smarter than the software engineer when it comes to
> specifying an order of conditions.  This is also consistent with
> Ada 95 Quality and Style: Guidelines for Professional Programmers.
>
> If using "and then" and "or else" will make our software quicker, and
> then the compiler doesn't optimize any better anyway, does anybody have
> a good reason why we should NOT use short-circuit control forms?

OK...

First of all, rewriting all conditionals this way is not necessarily an
optimization.  It all depends on what the expressions are, and whether there
is an "expected case".  The notion that short circuit forms are always
faster is an oversimplification.

Then, supposing you did get a net speedup if everyone did this... would it
be worth it?  Someone might say, "well, it can't hurt," (but see above),
"and as long as I'm in the neighborhood here, I might as well do it".  But
those changes don't quite come for free:

- Readers of code reasonably assume that things are the way they are for a
reason.  I don't think "we thought short circuit forms were faster" counts
as a good reason, and so I would expect that most readers would get the
impression that there is some other reason why it must be that way.  If it's
not really true, then the intent is obscured and the understanding process
is slowed down.

- Blindly replacing like this *is* error-prone, because you have to make
sure you're not losing side-effects that change the behavior of the program.
If there is cost to verifying this, then that's part of the cost of making
the change.

- If the programmer is checking in the change as part of another change, it
leaves the impression that it was necessary for whatever development
activity the new version is required for.  Again, confusing.

- Alternatively, they might try to "keep it clean", and create a new version
just for changing an "and" to an "and then" or whatever (I'll bet they don't
do that, but...:-)  But now we are creating a new version for a performance
difference that might only be marginally better.  The new version is subject
to the change propagation process.  And every additional version makes it a
little more difficult to follow the change log.  So there is a cost.

- If you added up all the time that programmers spend doing dubious
hand-optimizations, there's some opportunity cost there... they could
instead be doing hand-optimization the right way, which is to measure and
find out where the bottlenecks are, then figure out how to make those
bottlenecks *significantly* faster.

- Lastly, you have a standard in place, and programmers who are blowing it
off for their own reasons.  So the organization should do one of three
things: (a) say "Who needs a standard, anyway?" and chuck it; (b) say, "Our
standard is broken, let's fix it" (if that were the case :-); or, (c) tell
the programmers they need a better reason to blow off the standard, and to
quit going off half-cocked.  A good way might be to require some formality
for exceptions to your guideline.  That ought to cure them of this
tendency...

Have fun,
Mark Lundquist

Re: short-circuit control forms

[Al Christians]

Mark Lundquist wrote:
> 
> - If the programmer is checking in the change as part of another 
> change, it leaves the impression that it was necessary for whatever 
> development activity the new version is required for.  Again, > confusing.
> 

Attempting to solve multiple problems in the same set of check-ins 
ought to be cumpulsory to avoid.  It's dirty pool to plop that pastry
into an otherwise irrelevant thread.


Al

Re: short-circuit control forms

[Larry Kilgallen]

In article <b%aY6.212292$p33.4300386@news1.sttls1.wa.home.com>, "Mark Lundquist" <up.yerz@nospam.com> writes:

> - Blindly replacing like this *is* error-prone, because you have to make
> sure you're not losing side-effects that change the behavior of the program.
> If there is cost to verifying this, then that's part of the cost of making
> the change.
> 
> - If the programmer is checking in the change as part of another change, it
> leaves the impression that it was necessary for whatever development
> activity the new version is required for.  Again, confusing.

If there is any such confusion, the checkin should be rejected by the
reviewer as being insufficiently commented.

Re: short-circuit control forms

[Wes Groleau]

> - Readers of code reasonably assume that things are the way they are for a
> reason.  I don't think "we thought short circuit forms were faster" counts
> as a good reason, and so I would expect that most readers would get the
> impression that there is some other reason why it must be that way.  If it's
> not really true, then the intent is obscured and the understanding process
> is slowed down.

This is similar to the rationale for our standards/guidelines.
Since the RM, AQS, and most Ada textbooks say that the purpose
of a short-circuit is to avoid an exception in the second test,
using the form without comment is telling future readers that
this situation exists.  If that message is not true....

And, as others have pointed out.... anyone remember who
said (not an exact quote):

   More computing sins have been committed in the name
   of efficiency (without actually acheiving it) ..."

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau