Which Witch is Which?

[Aldo Cavini]

Lance,

my first post on this forum was almost wrong (I wrote ANDs are always bitwise, etc.), but something was right: for instance, I warned Mark the risk (in some cases) of using the NOT operator. In fact, I mostly don't use it.

Of course anybody can use the statements he prefers. I'm not discussing about the compilers are good or bad; I say what I think is a well written (and readable) code, keeping in mind the compilers (not only PowerBasic's) may work with not obvious rules. Fortunately, it is possible to have a clearly coded program using parentheses and avoiding unary operators: this is the way I use.

Bye

------------------

[Tom Hanlin]

Michael, ISTRUE and ISFALSE are unary operators, like NOT. They bear some
conceptual resemblance to functions, but aren't.

Aldo, ISTRUE and ISFALSE exist for clarity and convenience. Yes, there are
other ways of doing the same thing, just as you could replace (NOT a&) with
(a& XOR &HFFFF) ...pick the method that suits you best.

------------------
Tom Hanlin
PowerBASIC Staff

[Lance Edmonds]

Aldo, for the sake of argument, try comparing the behavior of the NOT operator on non-zero values as against those of ISTRUE, ISFALSE, etc. The value of ISTRUE and ISFALSE can be seen a little more clearly because the results are consistent.

FOR x& = -5 to 5
  PRINT x&, NOT x&, ISFALSE x&, ISTRUE x&
NEXT x&

However, you don't have to use 'em if you don't want to... stick with =0 and <> 0 if you so choose.

BTW, ISTRUE and ISFALSE operators have been around in PowerBASIC compilers for years... they are not "new" to PB/DLL or PB/CC.
------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Aldo Cavini]

Bob, sorry I don't understand the difference between comparations and the ISTRUE or ISFALSE operators (or functions, as Michael said?). I wrote this code (it works in PB/CC):

FOR A& = -1 TO 1
  PRINT A& = 0, A& <> 0, ISFALSE A&, ISTRUE A&
NEXT

The results are:

 0            -1             0            -1
-1             0            -1             0
 0            -1             0            -1

I really don't see the difference.

Steve, I didn't study the logic system you mentioned, however I also feel more comfortable using a lot of parentheses. Sometimes I'm tired, and omit ones... but I add them later.

Michael, I'd have written the following:

PRINT "MY VERSION ", X, X <> 0, ( X <> 0 ) + 2, MID$( "YN", ( X <> 0 ) + 2, 1 )

Aldo


------------------

[Michael Mattias]

Expanding on both Mr Edmonds' and Mr Zale's comments, I had contacted support when this did not seem to be working correctly:

(fabricated PB/CC code submitted)

 PRINT "WITHOUT PAREN", X, ISTRUE(X), ISTRUE(X) + 2, MID$("YN", ISTRUE(x)+2,1)
 PRINT "WITH PAREN  " , X, ISTRUE(X), (ISTRUE(X)) + 2, MID$("YN", (ISTRUE(x))+2,1)

In "real life" X is either zero or non-zero, and I wanted to create a function to return "Y" or "N" depending on X being non-zero or zero.

Details: I was using SQLGetInfo to query database capabilities; this function returns a "number" or "zero" ;or it returns an integer with individual bits set. Within the context of my application, either non-zero/any bit set may be interpreted as "Yes."

ISTRUE's behavior - consistently returning minus-one for any non-zero argument - is kinda handy for this.

BTW, ISTRUE and ISFALSE return values. Doesn't that make them functions rather than operators as stated in the help file?


MCM

[Steve Hutchesson]

It seems to depend how and where you learnt the logic you use.

A very long time ago when i was at UNI I studied a system of logic
by Donald Kalish and Richard Montague that was based on Russell
and Whitehead's logic, Tarsky's notation and strict bracketing
so I still write any formula and logical operators with full
bracketing as it is non ambiguous.

Full theorem dereivation sinks in after a while and while I confess
that I have long forgotten the quantifier calculus, the truth function
calculus is the same logic used in computer software so I have
retained that somewhat better.

I have always been very wary of operator percedence as you tend to
have to look it up somewhere where strict bracketing can be read
as it is.

Regards,

[email protected]

------------------

[Bob Zale]

Actually, that's not entirely correct. The primary underlying purpose of ISTRUE and ISFALSE is to present a uniform result from a variety of expressions. ISTRUE always returns the value 0 unchanged, and converts all other values to -1. ISFALSE does the opposite. There are many uses for this functionality beyond simple relational comparisons.

Regards,

Bob Zale
PowerBASIC Inc.


------------------

[Aldo Cavini]

This is the reason I don't like the ISTRUE and ISFLASE operators. They can easily be translated into equality and inequality tests:

1- ISFALSE ANYTHING: same as comparing ANYTHING = 0
2- ISTRUE ANYTHING: same as comparing ANYTHING <> 0

IMO (it is only a personal preference) the "=" and "<>" operators are more readable - to evaluate a complex expression it is enough to know the operators precedence.

------------------

[Lance Edmonds]

Michaels comment stems from discussions on the effects of mixed expressions, such as the following snippet:

IF ISTRUE(x&) + 2 THEN...

Essentially, the ISTRUE & ISFALSE operators do not require parentheses to enclose the expression, so PowerBASIC evaluates the entire expression that follows the keyword [in this case: (x&) + 2, which translates to x& + 2], thus:

IF ISTRUE (x& + 2) THEN ... ' parentheses shown for clarity purposes only.
IF ISTRUE x& + 2 THEN ...

If you wish to evaluate the logical truth or falsity of _part_ of an expression, you must enclose the boolean portion of the expression in paretheses to separate the elements:

IF (ISTRUE x&) + 2 THEN...

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Michael Mattias]

If you want to make sure comparisions are boolean rather than bitwise, use ISTRUE and ISFALSE a lot.(But watch the parentheses with these)

MCM

[Lance Edmonds]

Mark: All I can say is "naturally" !

Aldo: If you are more comfortable with explicit boolean or forced bitwise evaluation in IF/THEN statements, then there is no problem at all... the compiler will give you exactly what you asked.

Of course, using the default boolean/short-circuit evaluation may give your code a small performance boost (depending on what it is doing), but if there is any chance of confusion, trading off code maintainability is probably not a good idea.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Aldo Cavini]

well, I do prefer to have always the best readable code. I never write something like IF A& AND B& THEN... - I use one of the following:

1- IF A& <> 0 AND B& <> 0 THEN...
2- IF ( A& AND B& ) <> 0 THEN...

The two are longer, but I can have both the logical and the bitwise behavior, and I know what I'm doing at a glance - even if I use another Basic compiler ( I shouldn't say about other basic compilers here...)

Lance, sorry I forgot that short circuit evaluation. As I already stated, I like a compiler does what I want - I mean, I like a code that is written in such a way I have not to wonder what it does... It is difficult to remember ALL the (more or less) hidden rules of each compiler, when one have to write code in many languages (in my case, no PCs only)...

Aldo

------------------

Thank you!

Lance, Will things like this be in the "updated/upgrade" help file?

------------------
Cheers!

[Lance Edmonds]

Short Circuit Evaluation
PowerBASIC features short-circuit evaluation of relational expressions using AND and OR. This optimization means that evaluation of a relational expression in an IF, IF/END IF, DO/LOOP, or WHILE/WEND is terminated just as soon as it is possible to tell what the result will be. For example:

IF LEN(a$) AND MyFunc&(a$) THEN CALL ShowText("Ok!")

In the above example, if LEN(a$) is zero, then there is no further need to evaluate the expression, because 0 and anything will always be FALSE. So, if LEN(a$) is zero, MyFunc() is not called at all, and ShowText() is not executed.
To give short-circuit optimization an extra boost, AND and OR are treated as a Boolean operator rather than a bitwise operator, and this can sometimes produce unexpected results. For example, consider the following expression:

a& = 4
b& = 2
IF a& AND b& THEN ShowText("TRUE") ELSE ShowText("FALSE")

Applying the traditional BASIC bitwise evaluation, you would expect to see FALSE displayed because (4 AND 2) = 0. Due to the short-circuit optimization though, each value is treated as a Boolean, just as if you had written:

IF ISTRUE a& AND ISTRUE b& THEN …

If you believe this may be a problem for your particular code, you can disable the short-circuit evaluation by surrounding the entire conditional in parentheses:

IF (a& AND b&) THEN ShowText("TRUE") ELSE ShowText("FALSE")

The parentheses force the entire expression to be evaluated, so AND reverts to being a bitwise operator.

I hope this helps!

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Aldo Cavini]

Mark,

PowerBasic compilers have not a BIT data type. If I'm not wrong, ANDs (and ORs, etc.) are ALWAYS bitwise. If you use it on conditionals, the TRUE/FALSE status depends on whether the result is 0 or not 0.

Let's have the expression (127 and 258). The result is 2. You can use this expression to make an assignement: you'll get a 2. If you use it inside an IF/THEN block, the result is TRUE (<> 0).

Remark: if you write IF NOT (127 and 258) THEN... the result is TRUE again - (NOT 2) is <> 0!. To correctly handle this situation, you should use IF ISFALSE (127 and 258) THEN...

The doubt you have with all BASICs is not on logical operators - it is on the "=" sign. It can be used both on assignements and on the equality relational operator. (For istance, C language has "=" for assignements, "==" for tests; Pascal has ":=" for assignements, "=" for tests...). In Basic you can write A=(B=C). (B=C) is a relational test; you will assign A with a 0 (false) is B <> C, or with -1 (true) if B = C.

<added later>
The parenthesis don't change the operators meaning - they only affect the evaluation order. You can write the following statement: IF A < ( B AND C > D ) THEN... The compiler will check C against D; the result can be 0 or -1. This value is logically ANDed with B; this AND result is then checked against A: the final result will be a 0 (false) or a -1 (true).

------------------


[This message has been edited by Aldo Cavini (edited May 30, 2001).]

Mark,

If memory serves me corectly:

p AND q is the logical expression.
(p AND q) is the bitwise expression.
example: IF (p AND q) = q THEN whatever- says if q bit in p
is set, return q.

Cheers,
Cecil

------------------

Hello all,

Could somebody explain how PBDLL knows when to use a "bitwise" AND instead of the "conditional" AND. Under what conditions does the compiler see AND as "bitwise"?

I really hope my question makes sense...




------------------
Cheers!