Page 3 of 3

Posted: Fri Apr 14, 2006 7:45 am
by horst
It seems to me that the issue of boolean expressions is all about Mixing boolean and arithmetic expressions. But mixing is absolutely unnecessary (although supported in other language flavours). To me that is a typical case of something that has been done, just because it could be done.

I understand that it is difficult to untangle a mixture of arithmetic and boolean expressions. A boolean function, however, would do the job, and would be easy to implement. Example:

Code: Select all

 
result = Boolean(X > Y) * value 
The expression in parentheses would simply be anything that may succeed the "IF" keyword.

Re: Boolean Expressions

Posted: Sat Apr 15, 2006 3:46 am
by horst
Kaeru Gaman wrote:

Code: Select all

a = 7
b = 5
Debug #False Or (a>b)
I just discovered your solution.

Will this work?

Code: Select all

Macro Is(boolean)
  (#False Or (boolean))
EndMacro

Debug Is(12 < 13) * 22 
Debug 5* Is(100 = 99+3 Or 7 > 4) 
Debug Is(x) * 9
*edited: another pair of parentheses added

Posted: Sat Apr 15, 2006 4:06 am
by Dare2
:)


Is the "#False or" required for some cases or will this do?

Code: Select all

Macro Is(boolean)
  (boolean)
EndMacro

Posted: Sat Apr 15, 2006 8:33 am
by horst
Dare2 wrote: Is the "#False or" required for some cases ...
Actually, this work-around is based on the fact that Fred takes an expression as boolean, as soon as the boolean operators AND,OR, NOT are used in the expression. (At least that's how it seems to be). Examples:

Code: Select all

Debug (12 = 22 Or 5 > 3) * 22 
Debug (100 = 99+1 Or d > 8) *5
Simple comparisons (conditions) do not evaluate to #true or #false.

To trick Fred to accept a statement like (A > B) as boolean, we have to "decorate" it with a boolean operator, e.g.: #false or (A > B), which is done by the IS() macro.

Posted: Sat Apr 15, 2006 8:41 am
by Dare2
Okay, that makes sense. :)

So far I haven't found a case where the macro failed. Pretty useful.

Posted: Sat Apr 15, 2006 9:04 am
by blueznl
and pretty dangerous, as fred has stated this is not supported, so it may be broken at any time in the future...

good bug hunting...

Posted: Sat Apr 15, 2006 9:33 am
by Dare2
Yeah. I also use Not in unsupported ways, so when it all breaks I'm in trouble ... :)

Posted: Sat Apr 15, 2006 9:50 am
by horst
blueznl wrote:and pretty dangerous, as fred has stated this is not supported, so it may be broken at any time in the future...
I guess (hope), if Fred will change this at all, he will support a boolean function, like IS(BooleanExpression). This would be a clean solution, and should not be complicated, because the complete evaluation procedure exists already.

Posted: Sat Apr 15, 2006 12:43 pm
by jear
I guess (hope), if Fred will change this at all, he will support a boolean function
I think PB should evaluate

Code: Select all

(a > 60)
in the same manner as it evaluates

Code: Select all

If (a > 60) ...
as #True or #False depending of the value of a. That's all.
Now PB is evaluating

Code: Select all

(a > 60)
as 60 disregarding the actual value of a and this is simply "not true".

I would like code

Code: Select all

DisableGadget(#gg, a>60)
instead

Code: Select all

If a > 60
  DisableGadget(#gg, #True)
Else
  DisableGadget(#gg, #False)
EndIf

Posted: Sat May 06, 2006 12:39 pm
by dmoc
Hmmm, bummer, just hit this one as well. Tried the following and though it works in isolation it fails in the DisableGadget()...

Code: Select all

Procedure b2i(e.l)
  If e: ProcedureReturn 1: EndIf 
  ProcedureReturn 0
EndProcedure

...

  DisableGadget(#myGadget, b2i(anum <> 0))

...
Edit: Yet it works in SetGadgetState()