When are strings evaluated in Velocity? - performance

At which time are strings evaluated in Velocity? Directly at initialization or when referencing the string?
Example code to better illustrate the question:
#set($mystring = "A ${myobj.mymethod()} B")
#foreach($element in $somelist)
$element $mystring
#end
So the string contains some velocity code. Then consider the following code:
#foreach($element in $somelist)
$element A $myobj.mymethod() B
#end
Which is faster performance-wise, or are they equal?
Thanks in advance.

The first method is faster, as the second method will call $myobj.mymethod() at each iteration.
But as long as this call isn't expansive, you may as well privilege code readability by reducing intermediate variables.

Related

Compare 43 variables in all possible ways

I am trying to figure out which method is the best way to cross compare 43 variables (data sets, data)
I need to compare variable 1 with variable 2,3,4,5,6,7....43 and then compare variable 2 with variable 1,3,4,5,6,7....43 and so on, to variable no. 43.
I think i should use some kind of a loop, but i am clueless how to perform this operation efficient.
I think I just need some kind of pseudo code. Either way I want to do this in a do-file in Stata.
Assuming e.g. variables var1-var43 and that the "comparison" between the first and the second differs from that between the second and the first, which is what your question implies, then
forval i = 1/43 {
forval j = 1/43 {
if `i' != `j' {
<code for comparison between var`i' and var`j'>
}
}
}
With other variable names, foreach might be better.
As #NickCox suggested, you could use a O(NxN) nested loop. If that takes too long, which it could if your "43" is actually 1000, then there's a better way. Sort each list (indirectly), which is O(N logN), and run a merge-order loop, which is O(N), so altogether it is O(N logN).

What is the diference between these two pieces of code?

This prints 1:
def sum(i)
i=i+[2]
end
$x=[1]
sum($x)
print $x
This prints 12:
def sum(i)
i.push(2)
end
$x=[1]
sum($x)
print $x
The latter is modifying the global variable $x. Why is it modified in the second example and not in the first one? Will this will happen with any method (not only push) of the class Array?
Variable scope is irrelevant here.
In the first code, you are only assigning to a variable i using the assignment operator =, whereas in the second code, you are modifying $x (also referred to as i) using a destructive method push. Assignment never modifies any object. It just provides a name to refer to an object. Methods are either destructive or non-destructive. Destructive methods like Array#push, String#concat modify the receiver object. Non-destructive methods like Array#+, String#+ do not modify the receiver object, but create a new object and return that, or return an already existing object.
Answer to your comment
Whether or not you can modify the receiver depends on the class of the receiver object. For arrays, hashes, and strings, etc., which are said to be mutable, it is possible to modify the receiver. For numerals, etc, which are said to be immutable, it is impossible to do that.
In the first snippet, you assign new local variable to hold result of $x + [2] operation which is returned, but it doesn't change $x (because + method doesn't modify receiver object). In your second snipped, you use Array#push method, which modifies an object (in this case, object assigned to $x global var and passed as i into your sum method) on which it's called.
i.push(2) appends 2 to the array pointed by i. Since this is the same array pointed by $x, $x gets 2 appended to it as well.
i=i+[2] creates a new array and set i to it - and now this is a different array than the one pointed by $x.

OR between two function call

What is the meaning of a || between two function call
like
{
//some code
return Find(n.left,req)||Find(n.right,req);
}
http://www.careercup.com/question?id=7560692
can some one help me to understand . Many thanks in advance.
It means that it returns true if one of the two functions is true (or both of them).
Depends on the programming language, the method calls Find(n.left,req) -> if it's true - returns true. if it's false, it calls Find(n.right,req) and returns its Boolean value.
In Java (and C and C#) || means "lazy or". The single stroke | also means "or", but operates slightly differently.
To calculate a||b, the computer calculates the truth value (true or false) of a, and if a is true it returns the value true without bothering to calculate b, hence the word "lazy". Only if a is false, will it checks b to see if it is true (and so if a or b is true).
To calculate a|b, the computer works out the value of a and b first, then "ors" the answers together.
The "lazy or" || is more efficient, because it sometimes does not need to calculate b at all. The only reason you might want to use a|b is if b is actually a function (method) call, and because of some side-effect of the method you want to be sure it executes exactly once. I personally consider this poor programming technique, and on the very few occasions that I want b to always be explicitly calculated I do this explicitly and then use a lazy or.
Eg consider a function or method foo() which returns a boolean. Instead of
boolean x = a|foo(something);
I would write
boolean c=foo(something);
boolean x = a||c;
Which explicitly calls foo() exactly once, so you know what is going on.
Much better programming practice, IMHO. Indeed the best practice would be to eliminate the side effect in foo() entirely, but sometimes that's hard to do.
If you are using lazy or || think about the order you evaluate it in. If a is easy to calculate and usually true, a||b will be more efficient than b||a, as most of the time a simple calculation for a is all that is needed. Conversely if b is usually false and is difficult to calculate, b||a will not be much more efficient than a|b. If one of a or b is a constant and the other a method call, you should have the constant as the first term a||foo() rather than foo()||a as a method call will always be slower than using a simple local variable.
Hope this helps.
Peter Webb
return Find(n.left,req)||Find(n.right,req);
means execute first find {Find(n.left,req)} and return true if it returns true or
execute second find return the value true if it return true, otherwise false.

When to use parenthesis and when not to use parenthesis while assigning variables in VB6?

I am looking at some old VB6 code. I am new to VB and I come from a C/Java background, so I don't understand some of the assignment statements. Here is one example -
Private Type UGH
Rsp(3) As Byte
ProgramId(7) As Byte
RID(7) As Byte
TID(3) As Byte
FL(39) As Byte
End Type
Private UHeader As UGH
Later, the assignment takes place as follows-
With UHeader
StringToByteArray UHeader.ProgramId(), "ABCDPQRS"
My question is, why is the parenthesis used after ProgramId in the above assignment? To me it seems like a function call, but it obviously is not a function call. Then what is it?
Well it is not actually needed. Calling the same line without the parenthesis will do exactly the same thing. The reason it is allowed is because it is a byte array.
Maybe rewriting the line like this will make it more readable:
call StringToByteArray(UHeader.ProgramId(), "ABCDPQRS")
But this is also valid:
call StringToByteArray(UHeader.ProgramId, "ABCDPQRS")
It would probably make more sense to you if the StringToByteArray method was a function instead of a subroutine:
Private Function StringToByteArray(ByVal strValue As String) As Byte()
'conversion code left out
End Function
Then you can call it like this:
UHeader.ProgramId() = StringToByteArray("ABCDPQRS")
or this:
UHeader.ProgramId = StringToByteArray("ABCDPQRS")
The parenthesis in this case is used to designate an array. For Rsp(3) as Byte, it indicates an array of 3 bytes indexed from 0 to 2.
For the line: StringToByteArray UHeader.ProgramId(), "ABCDPQRS", StringToByteArray is a method that takes a byte array--when passing an array to a method, you pass it in as array().
Parenthesis are also used for array syntax.
And so it's said, StringToByteArray UHeader.ProgramId(), "ABCDPQRS" is not strictly an assignment, it is a method (subroutine or function) call. StringToByteArray is going to be defined somewhere in your program and it will probably take a ByRef array parameter, a string parameter, and it probably copys the string parameter into the the byte buffer.
UHeader.ProgramId is actually a pointer to the array. You can simply do this: StringToByteArray UHeader.ProgramID, "ABCDPQRS". The rule in VB6 is that Functions require parenthesization of argument lists and Subs require non-parenthesization, unless preceded by the Call statement in which case they do.
Since you are passing the array by reference (the default), operations performed in the subroutine are performed on the array itself. Basically, you are passing a pointer to an array and a literal string, and the subroutine will populate the array with the characters in the string. Sort of like an "informal" function call, if you will.

Is Odersky serious with "bills !*&^%~ code!"?

In his book programming in scala (Chapter 5 Section 5.9 Pg 93)
Odersky mentioned this expression "bills !*&^%~ code!"
In the footnote on same page:
"By now you should be able to figure out that given this code,the Scala compiler would
invoke (bills.!*&^%~(code)).!()."
That's a bit to cryptic for me, could someone explain what's going on here?
What Odersky means to say is that it would be possible to have valid code looking like that. For instance, the code below:
class BadCode(whose: String, source: String) {
def ! = println(whose+", what the hell do you mean by '"+source+"'???")
}
class Programmer(who: String) {
def !*&^%~(source: String) = new BadCode(who, source)
}
val bills = new Programmer("Bill")
val code = "def !*&^%~(source: String) = new BadCode(who, source)"
bills !*&^%~ code!
Just copy&paste it on the REPL.
The period is optional for calling a method that takes a single parameter, or has an empty parameter list.
When this feature is utilized, the next chunk after the space following the method name is assumed to be the single parameter.
Therefore,
(bills.!*&^%~(code)).!().
is identical to
bills !*&^%~ code!
The second exclamation mark calls a method on the returned value from the first method call.
I'm not sure if the book provides method signatures but I assume it's just a comment on Scala's syntactic sugar so it assumes if you type:
bill add monkey
where there is an object bill which has a method add which takes a parameter then it automatically interprets it as:
bill.add(monkey)
Being a little Scala rusty, I'm not entirely sure how it splits code! into (code).!() except for a vague tickling of the grey cells that the ! operator is used to fire off an actor which in compiler terms might be interpretted as an implicit .!() method on the object.
The combination of the '.()' being optional with method calls (as Wysawyg explained above) and the ability to use (almost) whatever characters you like for naming methods, makes it possible to write methods in Scala that look like operator overloading. You can even invent your own operators.
For example, I have a program that deals with 3D computer graphics. I have my own class Vector for representing a 3D vector:
class Vector(val x: Double, val y: Double, val z: Double) {
def +(v: Vector) = new Vector(x + v.x, y + v.y, z + v.z)
// ...etc.
}
I've also defined a method ** (not shown above) to compute the cross product of two vectors. It's very convenient that you can create your own operators like that in Scala, not many other programming languages have this flexibility.

Resources