Jump to content

Problems with Case function


This topic is 3569 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies

I'm new to filemaker pro advanced 13 and encountered some problems with the case function. I have to following function:

 

Case ( Product ID = Order Book_Test::ProductID ; Case ( Order Book_Test::Eformat = "Date&Price" ; Case ( Order Book_Test::Date = ( Get (CurrentDate)); Count ( Order Book_Test::Eformat))))

 

my problem is that filemaker stops at the first true Case. However, I need filemaker to validate all Cases and based on this result to execute the Count function. 

 

How can i solve this issue?

 

Thanks

Sam

Link to comment
Share on other sites

First thing, you are not using the Case() function correctly: it's not meant to be nested - on the contrary, the purpose of the Case() function is to eliminate nested Ifs. You also need to attach a result to each test.

 

Now, if you want to test for all those conditions being true, then you should be using something like =

Case (
Product ID = Order Book_Test::ProductID
and
Order Book_Test::Eformat = "Date&Price"
and
Order Book_Test::Date = Get (CurrentDate)
;
Count ( Order Book_Test::Eformat)
)

This will evaluate all three statements and if all return true, the count function will be executed and its result returned. Otherwise the result will be empty.

Link to comment
Share on other sites

It doesn't matter and is really just a preference, but when there is just a single test-result needed (even though the test is made up of multiple parts), you can use the If statement instead. Either way, it's best to put extra bracketing around the test which use operators like "and", "or", "not" to make sure the are evaluated as you want them to be. e.g.

If (
       (Product ID = Order Book_Test::ProductID)
      and
       (Order Book_Test::Eformat = "Date&Price")
      and
       (Order Book_Test::Date = Get(CurrentDate));
      Count(Order Book_Test::Eformat);
      "")
Link to comment
Share on other sites

 it's best to put extra bracketing around the test which use operators like "and", "or", "not" to make sure the are evaluated as you want them to be

 

IMHO, it's an extremely bad practice. The purpose of parentheses is to change the default evaluation order. They should not be used as a formatting device.

 

---

BTW, specifying an empty default result of If() or Case() is entirely redundant (although this may not be true for version 5.5 -  I'm afraid my memory doesn't go back that far...).

  • Like 1
Link to comment
Share on other sites

IMHO, it's an extremely bad practice. The purpose of parentheses is to change the default evaluation order. They should not be used as a formatting device.

 

I disagree. Any Boolean logical statement can be expressed without parentheses, so we're clearly not keeping parentheses around out of any mechanical necessity, but as an aid for human understanding. Using parentheses as a "formatting device" is consistent with that purpose. Harry's example is a little overzealous for my personal taste — the whitespace formatting is perfectly adequate for that calculation — but at least the parentheses aren't making that calculation any more difficult to follow, either (which is possible!).

Link to comment
Share on other sites

Actually I find Harry's calc more difficult to follow.  Parentheses are kept around because they are needed at times.  But it's just like an umbrella - you don't use one when the sun is shining because it isn't necessary.  But when it rains, not having one is a problem.

 

IOW, I agree completely with Comment's ... ahm ... comment that you quoted.  :^)

Link to comment
Share on other sites

Any Boolean logical statement can be expressed without parentheses, so we're clearly not keeping parentheses around out of any mechanical necessity, but as an aid for human understanding.

 

I am afraid I don't follow the logic of your argument. I am not objecting to the use of parentheses. Just because you can express:

2 * ( a - b )

as:

2 * a - 2 * b

doesn't mean that the parentheses in the first version are there as "as an aid for human understanding". They are necessary in order to guide whoever reads the expression - be it a human or a machine - to the correct result. If they are not necessary for this purpose - i.e. if removing them doesn't change the meaning of the expression - then they are by definition redundant. And redundant parentheses are making the calculation more difficult to follow. Because the educated reader asks himself/herself why are they there.

Link to comment
Share on other sites

I was coming back to provide this same example but my explanation would have been weaker for sure.  When I see unnecessary parentheses, it tells me the order of evaluation has been changed for a reason so I must re-read the calculation again to try to figure what the developer was trying to force.  It does not clarify; it confuses.

 

Instead, it makes more sense to me to focus on understanding order of evaluation, being willing to test until it is understood, and creating proper calculations.  

Link to comment
Share on other sites

If unnecessary parentheses give skilled readers reason to pause and re-read a calculation, I'll have Mr. Pink play them a song on the worlds smallest violin. Let's see how they like it when all boolean logic is re-written to eliminate all unnecessary parentheses, i.e., all parentheses. "Necessity" is not a good criterion for when to or not to use parentheses because they are never logically necessary. Saying that parentheses are necessary in "not ( a and b )" because it means something different than "not a and b" is a straw man argument.

Being able to express "not ( a and b )" as "not a or not b" may not necessarily mean that the intention of whoever put those parentheses there was to aid human understanding, but it does mean that parentheses in general are not necessary for guiding expressions to the correct result because that effect can be achieved by rearranging the expression. But we don't always like to do that because "not ( a and b )" might be easier for a human to understand than "not a or not b" by virtue of a closer correspondence to a human understanding of the solution being expressed by the logic.

The purpose of parentheses is to give human developers the flexibility to re-arrange logical statements in ways that are convenient for us — parentheses are not motivated by computer-readable clarity or correctness because there are more efficient approaches that would be used if those were the priorities of the calculation engine, such as prefix or postfix notation or simply not supporting parentheses in Boolean expressions. If FileMaker's calculation engine and other programming languages did not support parentheses, the computer would have no less capability to understand any logical expression with perfect clarity, and it would be no less possible to write a correct expression corresponding to any truth table we might need. Human developers, on the other hand, would have more work to do translating between human and computer understandings of solutions to problems.

Since parentheses are here (to stay) for human convenience, I'm happy to accept variation in practices due to personal taste. I've seen plenty of nasty-looking calculations resulting from negligent over- and under-use of parentheses. Harry's example doesn't hold a candle to those. It may be eccentric, but it's not pathological. A slippery slope argument would be more reasonable.

Link to comment
Share on other sites

parentheses in general are not necessary for guiding expressions to the correct result because that effect can be achieved by rearranging the expression

 

I am sorry, but as I said before I don't see the logic in this argument.  I don't see that you've brought anything new into it.

 

Rearranging an expression may or may not be an effort to make it more readable for humans. You certainly cannot infer any motivation to not rearranging an expression. All that has absolutely nothing to do with the question of redundant parentheses.

 

 

If unnecessary parentheses give skilled readers reason to pause and re-read a calculation, I'll have Mr. Pink play them a song on the worlds smallest violin.

 

I am all ears.

 

---

P.S. Note that unnecessary parentheses gave one reader reason to pause, re-read a calculation and then start this debate...

Link to comment
Share on other sites

Rearranging an expression may or may not be an effort to make it more readable for humans. You certainly cannot infer any motivation to not rearranging an expression. All that has absolutely nothing to do with the question of redundant parentheses.

 

I think we're discussing two different things in the same space. I make no claim about why or how one developer does or doesn't use parentheses already at their disposal. My claims are about why we have parentheses at our disposal at all. My answer to the latter makes it difficult to accept general recommendations for the former.

 

P.S. If you say "po-tah-toe" instead of "po-tay-toe," I'll have reason to pause and re-consider what it was that you meant to say, but that doesn't make your pronunciation incorrect or even bad.

Link to comment
Share on other sites

You can wrap that calculation (post #2 and #3) with Case() or If() equally well but compare them ... Comment's calc reads easily and works perfectly without additional parentheses to force explicit evaluation order because it follows the rules of evaluation order. Go on ... look back up at them.  :wink3: 

I am not faulting Harry's calculation (we all can use improvements and calc-tweaks from time to time) but I disagree with him that, "Either way, it's best to put extra bracketing around the test which use operators like "and", "or", "not" to make sure the are evaluated as you want them to be."   You can see the unnecessary clutter in the simple example above ... imagine if the calc were more complex and had a few more () functions as well. Now imagine that the developer reading the calc actually understands and practices following these rules. The first unnecessary opening parenthesis will tell them that the author wants to explicitly change the order thus inviting confusion. Once the remainder of the calculation is read, it becomes clear that the author was unaware of the proper evaluation rules in this combination.

For those interested in learning the rules, here are a few places to start:

This is standard knowledge and practice in the industry.  I doubt you will ever find a calculation by Comment (Michael Horak) or CobaltSky (Ray Cologon) or TheShadow where needless parentheses are used because they were unclear on the evaluation order (which is the ONLY reason you would ever add them in the first place) and I doubt that you have ever published such a calc yourself, Jeremy  :-)  ... I probably have particularly when new but also if busy or too lazy to test.  :crazy2: 
  
Instead of using unnecessary parentheses because you are uncertain if your calculation will evaluate properly, it makes more sense to find the answer ... learn the rules (order of operations) and then use parentheses (not the same as brackets) when you must be explicit in changing that order.  If uncertain, TEST IT so you will ( hopefully ) understand it for the next time.  It is called gaining wisdom.
 
This is a good discussion, guys!

Link to comment
Share on other sites

My claims are about why we have parentheses at our disposal at all.

 

Perhaps, but your claim ("as an aid for human understanding") is both unfounded and irrelevant to my original point.

 

Unfounded, because even if I care nothing about human understanding, I will still rewrite:

3 * a + 3 * b + 3 * c

as:

3 * ( a + b + c )

in order to minimize the number of evaluations the computer needs to perform.

Irrelevant, because even if I were to accept it, it still wouldn't change my position regarding redundant parentheses. Just because they are there for the benefits of humans only, that doesn't mean it's alright to use them wherever you feel like it.  

Basically, your logic could be restated as follows:

Any expression can be rewritten without using the multiplication sign. Therefore, the only reason for the existence of the multiplication sign is as an aid for human understanding. Therefore, you should not object when you see a bunch of terms being multiplied by 1.

Is multiplying by 1 "incorrect"? No, of course not. Is it good practice?

Link to comment
Share on other sites

You're using another straw-man argument. I've been talking about parentheses in boolean operations, not operations on real numbers. Your restatement of my logic is in a domain that does not behave the same way, so it is a dubious extrapolation. Not every expression of real arithmetic can be rewritten without using multiplication operations (or parentheses, for that matter, at least with infix notation).

 

Within arithmetic, I agree that parentheses are valuable for performance improvement with the operation notation we have, which can lead to some nasty-looking expressions with Horner's method. But if computer performance were a universal priority — the kind of thing where general recommendations that apply to all cases is safe to do — then the calculation engine would use an easier-to-parse prefix or postfix notation instead of parentheses. If performance were the primary reason for parentheses, parentheses would not have been the solution our computing tools arrived at. This doesn't prove that the motivating purpose of having parentheses is as an aid to understanding, but it does eliminate performance as a contender. (I already eliminated technical clarity.) Human understanding is the only not-yet-falsified hypothesis on the table.

 

So that's "unfounded" checked off my list; moving on to "irrelevant"...

 

I also agree that parentheses can be used in unhelpful ways. But my claims are not irrelevant because I reduce decisions of what parentheses are helpful or not helpful to a matter of case-by-case personal taste. Just because you're not persuaded doesn't mean the argument has no bearing on the matter or that someone else reading this thread later should feel stupid if they're influenced by it. Maybe it's not alright to use parentheses wherever you feel like it, but who's place is it to say what is and isn't alright in the absence of consistent supporting evidence? If some people find Harry's extra parentheses slightly more readable, should they eliminate the extra parentheses anyway just because someone else on the forum found them slightly less readable?

 

Sometimes it really is helpful to some people to see something multiplied by 1 or with a pair of parentheses that are not necessary. Just be grateful the calculation syntax wasn't modeled on LISP!

Link to comment
Share on other sites

You're using another straw-man argument.

 

Calling it names does not invalidate it, Jeremy.

 

 

I've been talking about parentheses in boolean operations, not operations on real numbers.

 

Parentheses are parentheses.

 

 

I reduce decisions of what parentheses are helpful or not helpful to a matter of case-by-case personal taste.

 

Yes, and that is where we disagree. Ultimately, this is a matter of communicating your intentions. Since I maintain that parentheses are a tool for changing the default evaluation order, using them for another purpose (or for no purpose at all) is not helpful in getting your meaning across.

 

Incidentally: if you live in a society that says "po-tay-toe", then saying "po-tah-toe" is incorrect. That's why my spellchecker flags "colour" as misspelled, but LaRetta's doesn't ... :joust: ).

Link to comment
Share on other sites

Calling it names does not invalidate it, Jeremy.

 

Except when that name points out that the argument follows a well-known invalid argument form, when it does.

 

I completely agree that this is about communicating intentions. I disagree that parentheses are only a tool for communicating a deviation from the default evaluation order. Parentheses communicate grouping. Harry's use is consistent with that. "These things go together," can be helpful to communicate even when the order of operations is unchanged. We could even think of grouping as parentheses' more general purpose anyway. While we're mixing uses of parentheses in boolean and real arithmetic, lets extend to prose! Using parentheses in a sentence has nothing to do with changing evaluation order.

 

Requiring that a practice be better for everyone is an unreasonable standard to satisfy. If the parentheses are helpful to Harry, shouldn't that be good enough for Harry?

 

If I live in a society that says "toe-may-toe," then saying "pomodoro" is incorrect. "Toe-mah-toe" is simply a quirk that briefly distracts attention and may even be charming. The intention is still communicated with perfect clarity, which is a reasonable standard of correctness. There are narrower situations where the alternate pronunciation is incorrect, but communicating intention is no longer the purpose of that constraint, so the metaphor breaks down at that point.

 

Incidentally, these ping-pong debates are a lot of fun; I look forward to many more!

Link to comment
Share on other sites

I disagree that parentheses are only a tool for communicating a deviation from the default evaluation order.

 

Well, that seems to be the point of contention here. I am not willing to be dragged away from it to all those corners you propose - such as the use of parentheses in prose. Or poetry. I mean, really.

 

 

If the parentheses are helpful to Harry, shouldn't that be good enough for Harry?

 

Harry is free to do whatever he pleases in the privacy of his home. But when he recommends a general practice of sprinkling parentheses all over the calculation, like powdered sugar over a cake - that's when I take the liberty to step in and present an opposing view.

Link to comment
Share on other sites

Incidentally: if you live in a society that says "po-tay-toe", then saying "po-tah-toe" is incorrect. That's why my spellchecker flags "colour" as misspelled, but LaRetta's doesn't ... :joust: ).

 

When new to FM, I corrected a developer on their spelling of 'realised' (I believe that was the word), telling them the proper spelling was 'realized' - how we spell it in the US. That is when I found out he was from Australia and the US was NOT the only right way to spell.  Shock!  I also found out that the US is minority on their dates.  

 

I set my MBP 15" to Australian and my rMBP 13" to US.  I LIKE the fact that both spellings appear to contradict each other ... it reminds me every day that life is grey.  Or ... is it  gray?   :giggle:

Edited by LaRetta
  • Like 1
Link to comment
Share on other sites

IMHO, it's an extremely bad practice. The purpose of parentheses is to change the default evaluation order. They should not be used as a formatting device.

 

This does not validate or invalidate either argument, but if you are looking at it from purely a math perspective, the definition of parentheses taught in schools to all math students covers both points.

 

Definitions of Parentheses

  • The symbols “(” and “)” are called parentheses and are generally used in grouping.
  • Parentheses are the the symbols used to show which operation or operations in an expression should be done first.
  • Parentheses are used to denote modifications to normal order of operations.

If you are trying to create a streamlined calculation as an experienced user, then you will use them little or not at all depending on your personal preference and experience level.

 

From my experience, for people that are not as educated on the order of operations, wether they be developers or management in an organization, parentheses can save hours when trying to explain calculations to others in meetings. They are helpful in indicating intent and clarify the overall logic.

 

For a developer that is going back into calcs months or years later, they can save time in the process of reabsorbing original intent.

Link to comment
Share on other sites

Looking at it from a purely math perspective, Jeremy is right. But we're not looking at it from a math perspective; we are looking at it from a perspective of good coding practice, which is quite different.

 

 

parentheses can save hours when trying to explain calculations to others in meetings.

 

I've never had to explain calculations in meetings (lucky me), certainly not to "people that are not as educated on the order of operations" (lucky me again), but if you find it convenient to use redundant parentheses for such occasion, by all means use them.  In the presentation - not in the calculation field.

 

They are helpful in indicating intent and clarify the overall logic.

 

For a developer that is going back into calcs months or years later, they can save time in the process of reabsorbing original intent.

 

You are describing comments.

Link to comment
Share on other sites

I work with actuarial calculations which are quite complex.

People other than myself need access to said calculations. Reasons being either for minor modifications as laws change each year or to verify the validity if anything ever comes into question and validity must be proven.

In short, it becomes a necessary evil to avoid issues.

 

So as a best practice in a closed solution for an experienced developer, sure don't use them unless absolutely necessary, but in the real world this cannot always apply.

 

Comments can be over used and become quite lengthly depending on the circumstances and the complexity of what needs to be communicated especially when a single addition of 2 () characters can suffice.  It certainly is not a hit to performance by any significant measure.

 

In the end I suppose we can all agree to disagree on some things.

Link to comment
Share on other sites

 Reasons being either for minor modifications as laws change each year or to verify the validity if anything ever comes into question and validity must be proven.

 

However, this sounds more like items are hard-coded within calculations which should ideally be records in a table so management can make changes in browse mode without entering field definitions.   I should think that anyone except a true developer in field definitions is inviting trouble. :-)

Link to comment
Share on other sites

But we're not looking at it from a math perspective; we are looking at it from a perspective of good coding practice, which is quite different.

 

Yup. In math, we can always get a black-and-white answer if we ask a precise enough question (leaving Gödel's theorem and the value of the question you choose to ask aside for the moment). Good coding practice does not always, or even usually, have that luxury; so we must stumble our separate ways in the fog, such as with the question of good practice for usage of parentheses. Sharing opinions and examples of different practices that work well for different people in different situations is all well and good, but mistaking black-and-white for shades-of-gray issues is an anti-pattern of its own that leads people to overconfidence and general wasted frustration. The single-exit-point debate is a great example.

 

 

I've never had to explain calculations in meetings (lucky me), certainly not to "people that are not as educated on the order of operations" (lucky me again), but if you find it convenient to use redundant parentheses for such occasion, by all means use them.  In the presentation - not in the calculation field.

 

Aids to understanding are more important in the calculation field, not less. The calculation field doesn't have you there to explain it. Comments and well-named variables for intermediate values help, and so do parentheses. There are many folks and machines in the target audience for the calculation, but the audience that offers the most useful constraints for how we write that calculation is the future maintenance developer who has no way to contact the original developer, is less skilled that the original developer, and is less familiar with the problem domain. The world runs on code maintained by this hypothetical person whether we like it or not. We can't write every calculation like it's a didactic example, but disregarding that audience is irresponsible.

Link to comment
Share on other sites

However, this sounds more like items are hard-coded within calculations which should ideally be records in a table so management can make changes in browse mode without entering field definitions.   I should think that anyone except a true developer in field definitions is inviting trouble. :-)

 

The people that do have access know enough to NOT be dangerous. Upper management does not have access nor do they want the responsibility considering the liability involved which would end in litigation. It revolves more around varying skill levels. As for pushing the calcs to a separate table, that is more a question of what they are willing to pay for. :)

Link to comment
Share on other sites

The people that do have access know enough to NOT be dangerous. Upper management does not have access ...

 

That makes more sense, Brian!  You had me worried for a moment.  But with a little girl THAT cute, you have no worries!   :laugh2:   Besides, you live in the best state there is!

Link to comment
Share on other sites

This whole silly "debate" proves there are too many over-egotistical "experts" in the forum playing idiotic power games. Time for me to stop bothering with this forum.

Really? This is  learning forum, and as such we like the different points of views, hearing thoughts on a subject helps us to become better developers.

 

That is always an option, see  Here

Edited by Lee Smith
add some things
Link to comment
Share on other sites

I've been soaking this thread up and loving it. Then came to Harry's last post and pfffffff when the balloon

 

I'd like to thank Harry for sparking this repartee (not "repartay" and pardon the parens !) and wish he'd have been able enjoy the philosophical swordplay.

I'm so new to this that the cushions still smell of chemical freshner-- and I really appreciate hearing the back and forth about best practice.

Link to comment
Share on other sites

This topic is 3569 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.