4 Replies Latest reply on Mar 15, 2018 4:39 AM by Simon Runc

    Bug in Calculation Evaluator?

    Thomas Rones

      If it is not possible to set parameters from calculated fields, then why would this calculation say it is valid?


        • 1. Re: Bug in Calculation Evaluator?
          Simon Runc

          Hi Thomas,


          So this formula is valid as making a equality statement is another way of equating something to True/False. So it's not setting the parameter, but just returning True if COUNTD of Event Name > 300 And the parameter = 301, If COUNTD of Event <=300 And Parameter = 299 then it will also return TRUE. If the Parameter doesn't equal 301 or 299 it will always return false


          This example might help



          Where I could have written this


          IF SUM([Sales]) > 100000 THEN TRUE

          ELSE FALSE



          Hope that makes sense?

          1 of 1 people found this helpful
          • 2. Re: Bug in Calculation Evaluator?
            John Sobczak

            Or even written it as simply:    Sum([Sales]) > 100000  

            • 3. Re: Bug in Calculation Evaluator?
              Thomas Rones

              Thanks Simon, that is what I was thinking, and also why I included the feature request tag. The feature request being showing some kind of error if the person tries to set a parameter value in a calculated field.


              As an aside, why would the parameter also be evaluated? It comes after the then.

              ...but just returning True if COUNTD of Event Name > 300 And the parameter = 301...


              I know that none of us non-employees could know, but I wonder what the actual validation code looks like.

              • 4. Re: Bug in Calculation Evaluator?
                Simon Runc



                So it's not so much that the parameter is evaluated in the IF part of the statement, just the [Parameter Value] = 301 is another way of writing TRUE if [Parameter Value] does equal 301 and FALSE if it doesn't


                So say the COUNTD of Event was 301, then the output would be the evaluation of the next part of the IF statement. So at that point [Parameter] = 301 is then computed (as an output); If the [Parameter] = 301, the output is TRUE and if not if would return FALSE. Conversely if COUNTD of Event was 299 Then it the output would be from the ELSE part, and then the evaluation of [Parameter] = 299 would be evaluated (so if [Parameter] does equal 299 then it would return TRUE and FALSE if not).


                A Parameter is just a way of allowing a flexible input...so if I had a formula

                IF SUM(Sales) > [Parameter] THEN 'Good' ELSE 'Bad' END

                with the parameter is set to 100000


                I could equally write IF SUM(Sales) > 100000 THEN 'Good' ELSE 'Bad' END


                having a parameter means myself (or a user) could then change the 100000 threshold, without having to go in and edit the formula. So similar to my 1=0/ 1=1 example, it's just equating it as if the value in the parameter had been 'hard-typed' in (which is also why they are single select). Using 1=1 or 1=0 to return TRUE or FALSE is common in some programming languages, so Tableau is allowing for this convention. Tableau seems to allow for most common conventions in formulas (so we can use IF, IIF, CASE and we can use == or = or != or <>), which means people don't get caught up in a particular syntax when using Tableau, regardless if they came from Excel, SQL, Python...etc.