This calc should produce True¶1but it produces 1 (num1 and num2 are number fields and this calc result is set to text) and there is correct data in the fields.

Case ( num1 = 5 ; "True" )

& ¶ &

not num1

and

not num2

Obvious type cast issue? Probably but I cannot pin down how it determines the data type here. FM clearly evaluated it as number result so all non-numbers disappear producing 1. IIRC, FM returns the data type of the last evaluated portion of a calculation so I looked to the Order of Operations. PEMDAS says Case() with its parentheses would evaluate first so it would make sense then that the boolean (blue) would evaluate last and produce a number result but there is more ...

What works:

• Replace the blue boolean with plain number, (well then it can't be because number was last part evaluated)
  
• Wrap parentheses or GetAsNumber() around blue boolean (so it isn't because it needs to perform an evaluation since these calcs do also and they work). Reversing the calc (putting logical test first and Case() second still breaks and produces 1.
  
• Then maybe it is because FM has to evaluate the blue boolean but that does not fit either because, even without the AND, it is a logical boolean evaluation and the following works:
  

Case ( num1 = 5 ; "True" )

& ¶ &

not num2

It appears that the switch to number result is because of the logical operator 'and' but also not the logical operator 'not'. So is FM seeing the 'and' logical operator as a text function between two numbers instead of a logical operator and it is evaluating it not as a single evaluation?

It feels inconsistent but I know it is my lack of understanding it. And no, please don't tell me to play it safe and wrap everything with GetAs() or to type cast needlessly. I would rather deepen my understanding of the theory and write clean, efficient, easy-to-understand calculations. What logic am I not understanding?

It's the and that does it. Everything before it is and everything after it is a proposition.

Case ( num1 = 5 ; "True" )

& ¶ &

not num1

and

not num2

is read as:

GetAsBoolean (

Case ( num1 = 5 ; "True" )

& ¶ &

not num1 )

and

GetAsBoolean (

not num2

)

WOW, I did not expect that kind of interpretation but that perfectly matches my results and the more I look at it the more logical it becomes. And upon reading about proposition, it is because it has two sides ( just as you show) that each side is a Boolean test and it explains why NOT didn't break (because it only has one side)!

THANK YOU for saving me from further suffering and now I can go to bed! I am on iPad so can't test at the moment but I would bet XOR and OR behave same way because of their two-sided natures. Much appreciated Michael! :-)

it has two sides ( just as you show) that each side is a Boolean test and it explains why NOT didn't break (because it only has one side)!

That is correct, and NOT is also much lower in precedence than AND or OR. For example:

1 and 0 & "text"

returns 0, because the right-hand side proposition is 0 & "text". OTOH:

not 0 & "text"

returns "1text" because NOT's proposition is only 0.