XOR

[-Queue-]

I found an interesting post on an old FileMaker bbs regarding the efficiency of Case( ), If( ), and Choose( ) versus logical operators. An example was given, that is allegedly more efficient than any of the three, involving xor. To produce a text field displaying "1 Day", "2 Days", or "3 Days", etc., based on a field containing the number of days remaining for a project. The calculation was NumToText(Entry) & Left(" Days",(0 xor (Entry-1))+4) versus a statement such as NumToText(Entry) & " Day" & Case(Entry > 1, "s").

My question: does such usage of xor really provide a more efficient and quicker calculation than a Case( ), If( ), or Choose( ) would? Furthermore, would the same result not be given using or instead of xor?

Anybody? Ray?

[BobWeaver]

I think whoever originally posted it thought that XOR looked more impressive than OR. And, since they are XORing the value with 0, you should be able to replace the expression with just about anything that returns a logical value of TRUE for an input value of TRUE.

So, you could also use (0 <> (Entry-1))+4) too.

I believe that operators are generally more efficient than function calls (ie., case, if, choose), but from past experience, nothing is certain unless you test it in your application.

[-Queue-]

Duly noted. I am currently testing this in a file I'm developing. I just wanted to hear the gurus' thoughts on the matter, since I'm an efficiency hound, always looking for the better way to perform calculations.

Your alternate example is valid, but I'm curious whether it may be less efficient as it's no longer a strictly boolean argument. The zero must be tested against the result of the second argument to determine whether they are equal. An OR or XOR IMHO would only test whether either (or both) are zero.

Thanks for your contribution, Bob!

[BobWeaver]

I was thinking about something similar a couple of days ago, and it occurred to me why the XOR was probably used. It isn't really any more efficient, but it makes it easy to invert the result by just changing the 0 to a one. This might have been used during testing when the developer wasn't sure whether a normal or inverted result was required.

Normal result = 0 XOR <<SomeLogicalExpression>>

Inverse result = 1 XOR <<SomeLogicalExpression>>

[-Queue-]

That's a good insight, Bob. After further digging I found that the Case( ) is allegedly less efficient than a logical operator due to the amount of memory storage required. If this is true, it would follow that an If( ) is actually more efficient than a Case( ), because the number of expected arguments is a constant, whereas Case( )'s are unknown and therefore require a maximum of memory storage. An interesting theory, regardless of its validity.

I have begun incorporating OR and XOR in situations where it does seem to be quicker to evaluate truth rather than a complicated nest of conditionals. It's a nice trick to have available when trapped in parentheses hell.

[BobWeaver]

I tend to think that If and Case statements are just not very elegant. Whenever I use one, I feel dirty and have to go take a shower.

[Ugo DI LUCA]

What a clean guy I would be....

Very interresting theory guys.

[Lee Smith]

Case Statements are easier to write, easier to read, and easier to understand.

They are like a breath of fresh air compared to If Statements.

So I may be needing a bath, but at least I can breathe

Lee

[BobWeaver]

I agree Case() functions are much better than nested If() functions, but whenever I can create an equivalent function that doesn't use either one, (and without being any longer), then I'm much happier.

[Ugo DI LUCA]

Recently, on another Forum, some where somehow complaining that boolean calc, if efficient, could become troublesome in case you need TO debug or develop someone else's work, as it is less explicit than a Case or If.

My opinion is rather different. I'd be inclined to favour efficientcy to "explicity" .

What about you too (three...) ?

[BobWeaver]

Good question. While I try to design things to be as understandable as possible, I won't dumb them down at the expense of efficiency.

This is a situation that has come up in my non-Filemaker work quite often. I design industrial control systems which involves a lot of controller programming. Our clients regularly ask us to program the system in a way that is easy for their electricians to understand. I like to respond to that request by asking them to have their electricians wire all their motors to operate at no more than 24 volts so that if I feel the urge to mess around with their wiring, I won't get my fingers burned.

In other words, if someone else is going to be debugging my work then they should be qualified to do it. If they can't understand boolean expressions, then they should keep their fingers out of it. And I'll keep my fingers out of their work.

[-Queue-]

I couldn't have said it any better, Bob, more harshly probably, but not better. Would you not agree that in any other major programming language, a discussion or debate about this sort of thing would be absurd? Go to a C++ or php board and hear them complaining about boolean and logical operators, whining that the syntax is too complex and their class methods are too oblique to be understood by other programmers. Forget about computer science fundamentals and efficient coding, I just want to see it all written in English.