Is there any way not to leave <choose> after first <when> match but continue check else conditions?
I believe it's a no. As the spec says:
The content of the first, and only the first, xsl:when element whose
test is true is instantiated. If no xsl:when is true, the content of
the xsl:otherwise element is instantiated. If no xsl:when element is
true, and no xsl:otherwise element is present, nothing is created.
from: http://www.w3.org/TR/xslt#section-Conditional-Processing-with-xsl:choose
you can't make it fall through other conditions like that. just convert it into a set of <xsl:if> following one another if you need a fall through
UPDATE. Here's a quote from the O'Reilly's XSLT book ( http://docstore.mik.ua/orelly/xml/xslt/ch04_02.htm ):
The C, C++, and Java switch statement is roughly equivalent to the
element. The one exception is that procedural languages
tend to use fallthrough processing. In other words, if a branch of the
switch statement evaluates to true, the runtime executes everything
until it encounters a break statement, even if some of that code is
part of other branches. The element doesn't work that
way. If a given evaluates to true, only the statements
inside that are evaluated
Related
I am trying to optimize my IF statement in Lua. When there are two conditions in an IF statement with the AND operator, does Lua read left to right and stop as soon as it reaches one false? That is, if there is a condition which is quick to check and a condition which is slower to check, is it more efficient to put the condition which is quick to check first (i.e. left most)?
For example, assume I have two functions that return true or false, quick_fn() and slow_fn(), and I want to execute code only if both functions return true. In terms of speed, is there a difference between the following two ways of writing this code? If Option #1 is equivalent, should I always be putting the quick_fn() in the leftmost spot?
Option #1:
if quick_fn() AND slow_fn() then
[code]
end
Option #2:
if quick_fn() then
if slow_fun() then
[code]
end
end
This is explained in the Lua documentation (emphasis added):
The negation operator not always returns false or true. The
conjunction operator and returns its first argument if this value is
false or nil; otherwise, and returns its second argument. The
disjunction operator or returns its first argument if this value is
different from nil and false; otherwise, or returns its second
argument. Both and and or use short-circuit evaluation; that is, the
second operand is evaluated only if necessary.
Note that the operator is spelled and, not AND. Lua is case-sensitive.
Struggle with MARIE Assembly.
Needing to write a code that has x=3 and y=5, is x>y then it needs to output 1, if x<y it needs to output one,
I have the start but don't know how to do if else statements in MARIE
LOAD X
SUBT Y
SKIPCOND 800
JUMP ELSE
OUTPUT
HALT
Structured statements have a pattern, and each one has an equivalent pattern in assembly language.
The if-then-else statement, for example, has the following pattern:
if ( <condition> )
<then-part>
else
<else-part>
// some statement after if-then-else
Assembly language uses an if-goto-label style. if-goto is a conditional test & branch; and goto alone is an unconditional branch. These forms alter the flow of control and can be composed to do the same job as structure statements.
The equivalent pattern for the if-then-else in assembly (but written in pseudo code) is as follows:
if ( <condition> is false ) goto if1Else;
<then-part>
goto if1Done;
if1Else:
<else-part>
if1Done:
// some statement after if-then-else
You will note that the first conditional branch (if-goto) needs to branch on condition false. For example, let's say that the condition is x < 10, then the if-goto should read if ( x >= 10 ) goto if1Else;, which branches on x < 10 being false. The point of the conditional branch is to skip the then-part (to skip ahead to the else-part) when the condition is false — and when the condition is true, to simply allow the processor to run the then-part, by not branching ahead.
We cannot allow both the then-part and the else-part to execute for the same if-statement's execution. The then-part, once completed, should make the processor move on to the next statement after the if-then-else, and in particular, to avoid the else-part, since the then-part just fired. This is done using an unconditional branch (goto without if), to skip ahead around the else-part — if the then-part just fired, then we want the processor to unconditionally skip the else-part.
The assembly pattern for if-then-else statement ends with a label, here if1Done:, which is the logical end of the if-then-else pattern in the if-goto-label style. Many prefer to name labels after what comes next, but these labels are logically part of the if-then-else, so I choose to name them after the structured statement patterns rather than about subsequent code. Hopefully, you follow the assembly pattern and see that whether the if-then-else runs the then-part or the else-part, the flow of control comes back together to run the next line of code after the if-then-else, whatever that is (there must be a statement after the if-then-else, because a single statement alone is just a snippet: an incomplete fragment of code that would need to be completed to actually run).
When there are multiple structured statements, like if-statements, each pattern translation must use its own set of labels, hence the numbering of the labels.
(There are optimizations where labels can be shared between two structured statements, but doing that does not optimize the code in any way, and makes it harder to change. Sometimes nested statements can result in branches to unconditional branches — since these actual machine code and have runtime costs, they can be optimized, but such optimizations make the code harder to rework so should probably be held off until the code is working.)
When two or more if-statements are nested, the pattern is simply applied multiple times. We can transform the outer if statement first, or the inner first, as long as the pattern is properly applied, the flow of control will work the same in assembly as in the structured statement.
In summary, first compose a larger if-then-else statement:
if ( x < y )
Output(1)
else
Output(one)
(I'm not sure this is what you need, but it is what you said.)
Then apply the pattern transformation into if-goto-label: since, in the abstract, this is the first if-then-else, let's call it if #1, so we'll have two labels if1Done and if1Else. Place the code found in the structured pattern into the equivalent locations of the if-goto-label pattern, and it will work the same.
MARIE uses SkipCond to form the if-goto statement. It is typical of machine code to have separate compare and branch instructions (as for a many instruction set architectures, there are too many operands to encode an if goto in a single instruction (if x >= y goto Label; has x, y, >=, and Label as operands/parameters). MARIE uses subtract and branch relative to 0 (the SkipCond). There are other write-ups on the specific ways to use it so I won't go into that here, though you have a good start on that already.
I want to validate an assumption that a set of 'or' statements as a predicate of a for-each operates analogous to the choose statement. Either things work as I expect or I just haven't hit the edge case that will cause an issue.
In a choose structure I know that it is evaluated in sequence and when the sequence finds a test that resolves to 'true' the processor drops out of the choose.
<xsl:choose>
<xsl:when test="number($A) and $A=1">
<!—do a thing -->
</xsl:when>
<xsl:when test="number($A) and $A=2">
<!—do a thing -->
</xsl:when>
<xsl:when test="number($A) and $A < 3">
<!—do a thing -->
</xsl:when>
</xsl:choose>
So if the first and third when is true (highly probable), the processor drops out of the choose when the first when resolves as true. This is great and expected. However, when this choose needs to be compressed into a for-each it seems a simple task, but a nagging thought in my mind is that I'm just getting lucky.
<xsl:for-each select="bunch of paths[(number($A) and $A=1) or (number($A) and $A=2) or (number($A) and $A < 3)]
In this example whether the first or third (or both) passes probably doesn't matter, but most of my work operates on financial dates so in that respect I want to be sure that if the first and third both pass that the predicate will evaluate the same as the choose statement.
So, I'm just seeking to ensure that my assumption that has been based on observation of predicate evaluation within the for-each is the same as the choose.
A significant difference between the two cases is that with the xsl:for-each example the evaluation context changes (both in the predicate, and in the body of the for-each instruction), while in the xsl:choose case, the context is the same throughout.
Another difference is that xsl:when always takes the effective boolean value of the test expression (so number 1 means true), whereas predicates have different semantics if the value is numeric.
I have been working with xslt recently, and I have been having trouble understanding the difference between | and or and when I should use which. I understand I can just use the error messages to figure out which one I need to be using but I am interested in learning why I can't use one or the other.
Would anyone be able to help point me in the right direction to someplace where I can learn the difference?
| is concerned with nodes, or is concerned with "truth", that is, Boolean values.
Explanation
The | or union operator
This operator returns the union of two sequences that, in this case, are interpreted as two sets of nodes. An interesting detail is that the union operator removes any duplicate nodes. Also, it only accepts operands of the type node()*, i.e. a sequence of nodes. The nodes are returned in document order.
The or operator
The technical term for this operator is Boolean Disjunction. It takes two arguments, both of which must evaluate to a Boolean value ("true" or "false") individually. Or, more precisely, the operands of or are jugded by their effective Boolean value by converting them to xs:boolean. All of this also applies to the and operator, by the way.
Examples
Use the union operator to enlarge a set of nodes, typically in a template match:
<xsl:template match="Root|Jon">
Why not use the or operator here? Because the match attribute expects a set of nodes as its value. union returns a set of nodes, whereas the or operator returns a Boolean value. You cannot define a template match for a Boolean.
Use the or operator to implement alternatives in XSLT code, mainly using xsl:if or xsl:choose:
<xsl:if test="$var lt 354 or $var gt 5647">
If any of the two operands of this or operation evaluates to true, then the content of xsl:if will be evaluated, too. But not only comparisons like "less than" (lt) have a Boolean value, the following is also perfectly legal:
<xsl:if test="$var1 or $var2">
The above expression only evaluates to true if at least one of the two variables is a non-empty sequence. This is because an empty sequence is defined to have the effective Boolean value of false.
Coercion
Note that because of the way XSLT coerces things to appropriate types, there are some contexts where either operator can be used. Consider these two conditionals:
<xsl:if test="Root | Jon"> ... <xsl:if>
<xsl:if test="Root or Jon"> ... <xsl:if>
The first conditional tests whether the union of the set of children named Root and the set of children named Jon is non-empty. The expression Root | Jon returns a sequence of nodes, and then that sequence is coerced to a boolean value because if requires a boolean value; if the sequence is non-empty, the effective boolean value is true.
The second conditional tests whether either of the two sets of children (children named Root and children named Jon) is non-empty. The expression Root or Jon returns a boolean value, and since the operator or requires boolean arguments, the two sets are each coerced to boolean, and then the or operator is applied.
The outcome is the same, but (as you can see) the two expressions reach that outcome in subtly different ways.
From Documentation
| - The union operator. For example, the match attribute in the element <xsl:template match="a|b"> matches all <a> and <b> elements
or - Tests whether either the first or second expressions are true. If the first expression is true, the second is not evaluated.
I have two questions -
(I)
code-fragment-1
if(<condition-statement>){
}
else if(<condition-statement-2>){
//statements-1
}
//statements-2
code-fragment-2
if(<condition-statement>){
}
else{
if(<condition-statement-2>){
//statements-1
}
//statements-2
}
Are the above two code fragments same?
(II) when are else ifs (in C++) used?
The only difference is in example 1 your Statement2 will get executed regardless of the conditions you check. In example 2, Statement2 will only get executed if your if condition is false. Other than that, they're basically the same.
No, in the first case you execute the else block only if the <condition-statement> is not verified AND only if <condition-statement-2> is verified.
In the second case you execute the else block simply if the <codition-statement> is not verified.
In this case are equivalent until you does not have any //statements-2.
About the question : when is the else if (in c++) used ?
Is used basically under the same conditions of all other languages that have this construct.
else is executed as alternative to the related if, else-if is executed as alternative but with an 'attached' if to be verified, otherwise is not executed.
So they are not logically equivalent.
the syntax of an if is really
if(condition) statement;
What the {} really do is allow you to group together multiple statements. In your second example you only have one statement(the if) inside your {}s, so yes, both examples are the same, except //statements-2 always gets run when !=true
In your first code sample, statement-2 is executed unconditionally. In the second it is conditional. Not the same.
'else if' is generally to be preferred, because you can keep inserting or appending more of them indefinitely, or append an 'else', whereas with the other form you have to endlessly mess around with braces to get the same effect, and you risk altering the semantics, as indeed you have done in your second sample.