Are IF..THEN statemen 
Author Message
 Are IF..THEN statemen


 In> I'm writing a program that has one large loop.  I would like to use
 In> the same loop a number of times in the program but with different parts
 In> inside the loop turned off.  I'm wondering if I have an IF (something
 In> is true) THEN (run procedure) does an if statement in the loop slow it
 In> down significantly if the condition is not met?  Thanks.
 In> --
 In> R. Hannay    

 In> http://www.*-*-*.com/ ~rhinoh/

An IF/THEN statement is a boolean, so it only requires a simple test of
one byte of code to see if it's a 1 or a 0, which takes no time at all....
to a degree. If you have a lot of IF/THEN statements within the loop then
the overall time taken to make a loop will obviously increase.

You may want to consider using a CASE statement instead, which may be
more economical speed-wise.

  /-=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=-\

  %        Author of Disk Ease v0.9.1 Floppy Disk Indexer/Database       $
  $               http://www.*-*-*.com/ ~kforwood/              %
  \-=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=-/
            WARNING:  Unsolicited advertising will be reported
                  to your ISP. Flames merely laughed at.

___ Blue Wave/QWK v2.20



Wed, 18 Jun 1902 08:00:00 GMT  
 Are IF..THEN statemen

Quote:
> An IF/THEN statement is a boolean, so it only requires a simple test of
> one byte of code to see if it's a 1 or a 0, which takes no time at all....
> to a degree. If you have a lot of IF/THEN statements within the loop then
> the overall time taken to make a loop will obviously increase.

> You may want to consider using a CASE statement instead, which may be
> more economical speed-wise.

   Probably not, as Case statements degenerate into a series of
If...then code.  When Borland expanded the Case range, they could no
longer use a transfer vector, which would be extremely fast, to
accomplish the logic.


Wed, 18 Jun 1902 08:00:00 GMT  
 Are IF..THEN statemen



Quote:


> In> I'm writing a program that has one large loop.  I would like to use
> In> the same loop a number of times in the program but with different parts
> In> inside the loop turned off.  I'm wondering if I have an IF (something
> In> is true) THEN (run procedure) does an if statement in the loop slow it
> In> down significantly if the condition is not met?  Thanks.
> In> --
> In> R. Hannay    

> In> http://www.cris.com/~rhinoh/

>An IF/THEN statement is a boolean, so it only requires a simple test of
>one byte of code to see if it's a 1 or a 0, which takes no time at all....
>to a degree. If you have a lot of IF/THEN statements within the loop then
>the overall time taken to make a loop will obviously increase.

>You may want to consider using a CASE statement instead, which may be
>more economical speed-wise.

>  /-=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=-\

>  %        Author of Disk Ease v0.9.1 Floppy Disk Indexer/Database       $
>  $              http://goodship.cn.camriv.bc.ca/~kforwood/              %
>  \-=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=--=oOo=-/
>            WARNING:  Unsolicited advertising will be reported
>                  to your ISP. Flames merely laughed at.

>___ Blue Wave/QWK v2.20

You should also remember that boolean expressions are evaluated from
the left, so if the first conditition is not true, the remaining terms
are not even tested. This also saves time.




Wed, 18 Jun 1902 08:00:00 GMT  
 Are IF..THEN statemen

Quote:

> You should also remember that boolean expressions are evaluated from
> the left, so if the first conditition is not true, the remaining terms
> are not even tested. This also saves time.

This is based on the assumption $B-.  Complete Boolean evaluation *can*
be enabled using $B+ (though I haven't yet found a case where I'd want
to or need to enable it).

--
Scott Earnest        | We now return you to our regularly |



Wed, 18 Jun 1902 08:00:00 GMT  
 Are IF..THEN statemen



Quote:

>This is based on the assumption $B-.  Complete Boolean evaluation *can*
>be enabled using $B+ (though I haven't yet found a case where I'd want
>to or need to enable it).

I think the choice is for compatibility. A Pascal compiler should use
complete evaluation.

Osmo



Wed, 18 Jun 1902 08:00:00 GMT  
 Are IF..THEN statemen

Quote:



> >This is based on the assumption $B-.  Complete Boolean evaluation *can*
> >be enabled using $B+ (though I haven't yet found a case where I'd want
> >to or need to enable it).

> I think the choice is for compatibility. A Pascal compiler should use
> complete evaluation.

> Osmo

I am always careful to check that I do not have "complete evaluation"
selected in my compiler options.  The reason for this is
that there are a lot of times where I use something like

If (P <> NIL) and (P^.Next <> NIL) and (P^.Next^.Value < Key)
then A
else B;

If I had complete evaluation enabled, I would instead have to
write it as:
   If (P <> NIL)
   then if (P^.Next <> NIL)
        then if (P^.Next^.Value < Key)
             then A
             else B
        else B
   else B;

Thus, as you might already suspect, I simply use the default
short-circuit
evaluation because it allows me to write simpler code in many cases.

--
Rob Stow                When using the "reply" feature of your mail

                        the address so that it becomes like the one
                        at the left.



Wed, 18 Jun 1902 08:00:00 GMT  
 Are IF..THEN statemen



Quote:


>>This is based on the assumption $B-.  Complete Boolean evaluation *can*
>>be enabled using $B+ (though I haven't yet found a case where I'd want
>>to or need to enable it).

>I think the choice is for compatibility. A Pascal compiler should use
>complete evaluation.

I fully agree! I just want to give an example:

Program SideEffect;
var s1,s2:Integer;
function OddSum(a,b:Integer;var Sum:Integer):Boolean;
  begin
    Sum:=a+b;
    OddSum:=Odd(Sum)
  end;
begin
  if OddSum(1,4,s1) and OddSum(2,7,s2)
    then WriteLn('Both were Odd. The values were ',s1,' and ',s2,'.')
end.

Not a very good style of programming (functions with side-effects may
cause many difficult-to-discover bugs), but it is standard pascal!

Anyway, I prefer the possibility of using something like
    if (p<>nil) and (p^.Next<>nil)
      then ...
even if not standard. So I always use short-circuit.

Babis Athineos

--

WWW : http://users.hol.gr/~babis
Snail-mail: Papadoniou 61, 11145 Athens, Greece



Wed, 18 Jun 1902 08:00:00 GMT  
 Are IF..THEN statemen

Quote:





>>>This is based on the assumption $B-.  Complete Boolean evaluation *can*
>>>be enabled using $B+ (though I haven't yet found a case where I'd want
>>>to or need to enable it).

>>I think the choice is for compatibility. A Pascal compiler should use
>>complete evaluation.

>I fully agree! I just want to give an example:

>Program SideEffect;
>var s1,s2:Integer;
>function OddSum(a,b:Integer;var Sum:Integer):Boolean;
>  begin
>    Sum:=a+b;
>    OddSum:=Odd(Sum)
>  end;
>begin
>  if OddSum(1,4,s1) and OddSum(2,7,s2)
>    then WriteLn('Both were Odd. The values were ',s1,' and ',s2,'.')
>end.

Bad example as it would work with short-circuit as well. After all the
program outputs only if the condition passes and in that case both
functions have been called. Make that "or" and then you have it correct.

Quote:

>Not a very good style of programming (functions with side-effects may
>cause many difficult-to-discover bugs), but it is standard pascal!

>Anyway, I prefer the possibility of using something like
>    if (p<>nil) and (p^.Next<>nil)
>      then ...
>even if not standard. So I always use short-circuit.

Yes, the benefits of short-circuits are much better than the
disadvantages. (In fact the disadvantages are basically only because of
lack of compatibility in dirty examples like above)

Osmo



Wed, 18 Jun 1902 08:00:00 GMT  
 Are IF..THEN statemen

Quote:


> >I prefer the possibility of using something like
> >    if (p<>nil) and (p^.Next<>nil)
> >      then ...
> >even if not standard. So I always use short-circuit.

> Yes, the benefits of short-circuits are much better than the
> disadvantages.

I think that this example is poorly chosen. There is no guarantee that
p<>nil will be evaluated before p^.Next<>nil. The use of the AND
operator only guarantees that both will be evaluated to find the value
of the boolean expression, not necessarily in which order.

We always read from left to right, which frequently makes us forget that
the compiler is not bound to do the same.

AME



Wed, 18 Jun 1902 08:00:00 GMT  
 Are IF..THEN statemen



Quote:

>>Program SideEffect;
>>var s1,s2:Integer;
>>function OddSum(a,b:Integer;var Sum:Integer):Boolean;
>>  begin
>>    Sum:=a+b;
>>    OddSum:=Odd(Sum)
>>  end;
>>begin
>>  if OddSum(1,4,s1) and OddSum(2,7,s2)
>>    then WriteLn('Both were Odd. The values were ',s1,' and ',s2,'.')
>>end.

>Bad example as it would work with short-circuit as well. After all the
>program outputs only if the condition passes and in that case both
>functions have been called. Make that "or" and then you have it correct.

Thanks for the correction, Osmo, I am sorry about that.

I should have thought of it, since I tested it in the IDE and it worked,
even if I did not alter the "complete boolean evaluation" option...

Finally I think I do need some rest!

Babis Athineos

--

WWW : http://users.hol.gr/~babis
Snail-mail: Papadoniou 61, 11145 Athens, Greece



Wed, 18 Jun 1902 08:00:00 GMT  
 Are IF..THEN statemen



Quote:


>> >I prefer the possibility of using something like
>> >    if (p<>nil) and (p^.Next<>nil)
>> >      then ...
>> >even if not standard. So I always use short-circuit.

>> Yes, the benefits of short-circuits are much better than the
>> disadvantages.

>I think that this example is poorly chosen. There is no guarantee that
>p<>nil will be evaluated before p^.Next<>nil. The use of the AND
>operator only guarantees that both will be evaluated to find the value
>of the boolean expression, not necessarily in which order.

>We always read from left to right, which frequently makes us forget that
>the compiler is not bound to do the same.

The default short-circuit setting requires it to do so, and to stop
evaluating the condition as soon as the outcome is certain.  However,
the Wirth/ISO Pascal standards, I believe, require complete evaluation.
Therefore Borland sagely provide an option.

Very limited testing suggests that, with BP7.01 Real mode {$B-}, A & B
boolean,
        if A and B then ...
&       if A then if B then ...
generate the same code.  IMHO the latter is better, because, although 4
characters longer, I think that I read it slightly quicker.

--

  Web URL: http://www.merlyn.demon.co.uk/ -- includes FAQqish topics and links.
  Correct 4-line sig separator is as above, a line comprising "-- " (SoRFC1036)
  Standard quoter : ">" / "> " recognised by most good news readers (SoRFC1036)



Wed, 18 Jun 1902 08:00:00 GMT  
 Are IF..THEN statemen



Quote:


>> >I prefer the possibility of using something like
>> >    if (p<>nil) and (p^.Next<>nil)
>> >      then ...
>> >even if not standard. So I always use short-circuit.

>> Yes, the benefits of short-circuits are much better than the
>> disadvantages.

>I think that this example is poorly chosen. There is no guarantee that
>p<>nil will be evaluated before p^.Next<>nil. The use of the AND
>operator only guarantees that both will be evaluated to find the value
>of the boolean expression, not necessarily in which order.

In case of short circuit the expressions are evaluated from left to
right always. That is just so that one can write tests like above. Also
both of them are not evaluated if the first fails.

Quote:
>We always read from left to right, which frequently makes us forget that
>the compiler is not bound to do the same.

>AME

Osmo


Wed, 18 Jun 1902 08:00:00 GMT  
 Are IF..THEN statemen



Quote:

>Very limited testing suggests that, with BP7.01 Real mode {$B-}, A & B
>boolean,
>        if A and B then ...
>&       if A then if B then ...
>generate the same code.  IMHO the latter is better, because, although 4
>characters longer, I think that I read it slightly quicker.

But what if you need common else for them?

Osmo



Wed, 18 Jun 1902 08:00:00 GMT  
 Are IF..THEN statemen




Quote:


>>Very limited testing suggests that, with BP7.01 Real mode {$B-}, A & B
>>boolean,
>>        if A and B then ...
>>&       if A then if B then ...
>>generate the same code.  IMHO the latter is better, because, although 4
>>characters longer, I think that I read it slightly quicker.

>But what if you need common else for them?

The codes will then be significantly different, as is proper ... I
should perhaps have put "no else" above.

--

  Web URL: http://www.merlyn.demon.co.uk/ -- includes FAQqish topics and links.
  Correct 4-line sig separator is as above, a line comprising "-- " (SoRFC1036)
  Standard quoter : ">" / "> " recognised by most good news readers (SoRFC1036)



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. DBLookupCombo - Documentation/Am I mad?

2. I am really sorry

3. What am I doing wrong...

4. I am stuck - TDecisionQuery AV in SQLORA8.DLL

5. WHAT DBGRID FIELD AM I

6. IndexDefs - am I using the right property?

7. Desperate for help...What am I missing?

8. Am I hitting the Limit here?

9. SQL - Where am I wrong?

10. HELP : I am stuck ! DBGrid (D1)

11. Losing File Handles - But I am not using Files

12. Am I in protected mode?

 

 
Powered by phpBB® Forum Software