Are braces required?

Hi Gio, Perhaps you are referring to the fact that FME uses different Regex engines in different places. It is on development's plan to consolidate these. We'll notify you, when that work is done.

In FME 2016.0 we should have unified all the Regular Expression engines. We'll check to be sure this case is dealt with.

Hi @XiaomengAtSafe, I would like to know why some math operators (e.g. ==) work for non-numeric operands.

"See the C Manual for more details on the results produced by each operator." -- FME Documentation on Math Operators

In my understanding, C math operators never work for non-numeric operands. I always feel strange. This could also be one of inconsistencies between documentation and actual behavior of FME.

Hi, no i am not referring to that.

I am referring to parsing errors.

In tcl using a variable string as operand can lead to reg parsing error, most common, when there are specialcharacters in the string. Using double qoutes aleviates the problem except when there are certain characters in the string. (so at this point u can still heve regexp in a attribute used in a regexp...) Using braces tells the reg engine to use everything inside as a string.

The above logical query, now fails unless you force it to see the content of the variables as a string, that is, using braces. (prior to fme2015 this would work without braces)

If in the above expression @Value(zone) = A then the expression would be yield a expression string starting A==A|| etc. Without braces the first A is not recognised as a string, : result error invalid bareword "A". a parsing error.

Heres is a example error log.

AttributeCreator_2: Failed to evaluate arithmetic expression '(B2== {A}||({B2}=={B1}&&{FASE3}=={FASE1}))?300:200'

AttributeCreator_2: TCL Error Message:

invalid bareword "B2"

in expression "(B2== {A}||({B2}=={B1}&&{...";

should be "$B2" or "{B2}" or "B2(...)" or ...

AttributeCreator_2: Failed to evaluate function '(B2== {A}||({B2}=={B1}&&{FASE3}=={FASE1}))?300:200'

Failed to evaluate numeric expression '(B2== {A}||({B2}=={B1}&&{FASE3}=={FASE1}))?300:200'. Result is set to null.

...I removed the braces on the first operand to force the above error.

as you can see all variables (operands) enclosed in braces do not yield this error.

This is not a matter of regengine flavors.

Fme should know the content of the variable is a string, so one should not have to enclose the variable name like )} or "@Value(ZONE)"...or so i think.

Different regengines is more of a nuiscance then a real problem. Parsing errors are a more serious problem.

@ Takashi: "==" is not a math operator, it is a logical operator.

And why is that the best answer?? I'm confused...;)

The == operator belongs to "FME Math Operators", and some program languages treat it as a comparison (or relation) operator in general. But the classification of operators is not a problem.

Even though FME and C are apparently different in the definition about operators, the documentation says "See the C Manual ....". It's the problem.

Okay, I think we've been barking up the wrong tree on this one, sorry for that.

To be clear, you're in an AttributeCreator, and authoring a Conditional value, and that must be numeric conditional value. So you've chosen the Arithmetic editor. And you're working to author a conditional value inside of that as well, using the ? : syntax.

Takashi is 100% correct that our documentation of the Arithmetic editor references the C manual, which is not what we should be doing. We are using Tcl's expr to evaluate the said expression. SO we should update our doc to instead refer to Tcl expr for the operator definitions. We'll file a PR for that update.

That said, the issue of auto-quoting is an interesting one. Because FME is NOT a strongly typed environment, in general we do not know what we're going to get when we access the value of an attribute. This lack of strong typing is part of the power of FME, because it enables such flexibility.

But there is a cost to that flexibility and power, and that is that, for more complicated situations such as this, the quoting burden is put upon the workspace author. Our job, which we are striving to do better at, is to provide the best possible documentation to guide such an author so they know how things will be parsed and interpreted.

Short answer -- I can't see how we ever could safely inject { } around Value( ) calls, but I'll ask the team. (Would there be any harm in always doing it? That is what we'll figure out).

And I have to rush off now to an interview for an additional technical writer for our team to help us do an ever better job of relating the ins and outs of these dark corners of FME. (Yes, I'm serious!)

Thanks for pointing this out @gio .

Dale