ISTRUE operator

[Heinz Salomon]

It's probably a typical easy-to-answer beginner question...

The PowerBasic 3.50 reference guide describes the functionality of the ISTRUE operator as follows:
"...ISTRUE ensures that a true expression's value is -1, which isn't guaranteed with other operators."
This means to me that the ISTRUE test must fail when applied on any number/expression that is not equal to -1.

The following test program does not behave as expected:

$ERROR ALL ON
$DIM ALL

DIM A AS INTEGER
A% = 100

CLS

IF ISTRUE A% THEN
  'should only execute if A% = -1
  PRINT "A% is TRUE"

ELSEIF ISFALSE A% THEN
  'should only execute if A% = 0
  PRINT "A% is FALSE"

ELSE
  'should execute if (A% < -1) OR (A% > 0)
  PRINT "A% is neither TRUE nor FALSE"

END IF

The output:

A% is TRUE

What did I misunderstand?

Thanks for your help!

[Bob Scott]

Heinz,

The Help File says:
ISTRUE returns -1 (TRUE) when expr evaluates as non-zero, otherwise it returns zero (FALSE). ISFALSE returns -1 when expr evaluates as 0 (FALSE), otherwise it returns zero.

So, if A% is anything else but zero ISTRUE will return -1.

I think you may be getting confused between the value of A% and the result of the ISTRUE operator on A%.

If A% equals any value except zero then ISTRUE A% = -1
If A% equals zero then ISTRUE A% = 0

~Bob

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




[This message has been edited by Bob Scott (edited October 08, 2004).]

[Eric Pearson]

Heinz --

> "...ISTRUE ensures that a true expression's value is -1,
> which isn't guaranteed with other operators."

> This means to me that the ISTRUE test must fail when applied
> on any number/expression that is not equal to -1.

Perhaps the documentation would be less prone to misinterpretation if it said...

ISTRUE can be used to force a true (nonzero) expression's value to be -1. While other operators can return different values, ISTRUE always returns -1 if the expression being evaluated is nonzero.

-- Eric


------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[George Bleck]

ISTRUE(Expression) = - ABS(SGN(Expression))

------------------
George W. Bleck
Lead Computer Systems Engineer
KeySpan Corporation
My Email

[This message has been edited by George Bleck (edited October 08, 2004).]

[Michael Mattias]

>ISTRUE(Expression) = - ABS(SGN(Expression))

ISTRUE  (Expression) = (Expression<>0)
ISFALSE (Expression) = (Expression=0)

[Michael Torrie]

I think your question about ISTRUE has pretty much been answered. I have a question regarding the need for ISTRUE and friends.

It appears to me that in many circumstance, PowerBASIC's grammar makes no differentiation between the LOGICAL boolean operators and the BITWISE ones. For example, AND is used but logically (in an if statement) and bitwise (in an expression). Also, in an IF expression, AND could be boolean or logical, depending on where it was in the expression. How does the PowerBASIC compiler decide which operation to use? Or does it at all?

The presence of the ISTRUE and ISFALSE operators suggests to me that either
a) the compiler makes an inteligent guess as to whether you want a logical or bitwise and if it's wrong, you can force the issue with ISTRUE and ISFALSE

or

b) PowerBASIC has no logical operators at all. All boolean operations are bitmap. Certain binary operators (<,>,<>,>=,<=,=) always return 0 or -1, which means that most of the time you get what you want anyway using only bitwise operators. This is because if you define %TRUE as -1 and %FALSE as 0, then doing all boolean operations using bitwise operators is equivalent to logical operators.

Am I way off base? If not, which of the above is true?

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


[This message has been edited by Michael Torrie (edited October 10, 2004).]

[Michael Mattias]

Near as I can figger out, AND and OR are always treated as logical when ambiguity exists:

IF A AND B    ' << logical

IF A AND (B OR C) ' << AND is logical, OR is bitwise

IF (A AND B)    ' << parens make this unambiguously bitwise

I just use lots of parens so compiler knows what I mean

IF ISTRUE A AND B  ' << ambiguous, so I use ...

IF (ISTRUE A) AND B  ' AND is logical
'or
IF ISTRUE (A AND B)  ' AND is bitwise

Or if I really am not sure, I just nest some IFs

IF A AND B THEN
' If I didn't already know better, I could use either
 IF (A AND B) THEN   ' bitwise
' or
 IF A THEN           ' loigical using multiple IF
    IF B THEN

Bottom line is "use parens or nested tests to eliminate ambiguity and not have to guess how the compiler will interpret it."

YMMV.

MCM

[Michael Torrie]

Yes, but if you are nesting parens in order to correctly prioritize an expression, then you will have problems. For example:

IF A and (B or C) THEN ....

What if you mean OR to be logical too? This is a very common expression in my programming career. In this case, I intend the OR to be logical, but I still want the parenthesis to dictate that the OR is a higher precidence than the AND. If I recall my algebra correctly, A and (B or C) is equivalent to A and B or A and C. Thus the only way I can see to get this expression to evalutate properly is to do:

IF A and istrue(istrue(B) or istrue(C)) THEN ...

Thus having an ambiguous grammar is not a desirable thing, even if the compiler makes guesses as to which operator you mean. As I stated before, all logical operations can be accomplished with bitwise operators when we use -1 and 0 as the truth values. Thus in my example, ISTRUE and ISFALSE make the effect of the "or" operator logical, even if the compiler still considered it to be bitwise.

This leads me to wonder if *all* boolean expressions should be wrapped in ISTRUE and ISFALSE because of this ambiguity.

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

[Michael Mattias]

>What if you mean OR to be logical too

With OR, logical/bitwise is moot.

[Tom Hanlin]

All BASIC operators are arithmetic, not logical-- except AND, when
used without parentheses, in PowerBASIC. This exception is for reasons
of efficiency, to allow early-out optimization. That is, when the
compiler sees "IF A AND B THEN", it can know not to bother with
evaluating B in the case where A is zero, since anything ANDed with
zero is going to be zero.

------------------
Tom Hanlin, PowerBASIC Staff
Opinions expressed may not be those of my employer or myself

[Michael Torrie]

Thanks for the clarification, Tom. That confirmed what I thought. And the special treatment of "AND" makes a lot of sense. A good optimization. For the most part, my concerns are non-issues, because the arithmatic booleans work out in almost all cases.

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

[Heinz Salomon]

I obviously misinterpreted the quoted text.
Thank you for your help!

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