Although the documentation warns that the functions may return different values at different runs, I bet a lot of programmers still make the mistake of assuming the result of the functions would be stable. Pretty dangerous!

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23.

Find the sum of all the multiples of 3 or 5 below 1000.

Well, the naive way to solve this problem is simply to generate a list, and then to find the sum of its elements:


sum(filter(lambda x: x%3==0 or x%5==0, range(1,1000)))

and the answer is 233168.

Although I appreciate the elegance of functional programming (lambda function, filter, sum), mathematically the above code is not a good solution. The sum of all numbers that are either dividable by 3 or 5 in fact equals the sum of all numbers that ar dividable by 3, plus the sum of all numbers that are dividable by 5, minus the sum of all numbers that are dividable by 15, therefore


rg = range(1,1000)
sum(filter(lambda x: x%3==0, rg)) + sum(filter(lambda x: x%5==0, rg)) - sum(filter(lambda x: x%15==0, rg))


And again, the answer is 233168.

I am now staring a series in this blog to show my solutions to some of the problems.

While it may look innocent, it’s actually dangerous. In case of an exception, the system prints the String representation of e.getStackElement(), which actually is of type StackElement[]. Since it is an array, its String representation is only the address of the array, instead of the content of the array. Since the output is a one-liner, it does not catch one’s eye in the log, and it may take some time (and really took mine) for the debugger to find the exception.

I have no idea why the original programmer come up with the idea of using getStackElement(). Maybe he thought println(e.getStackElement()) were the same as e.printStackElement().

((for (x <- 100 until 1000; y <- x until 1000) yield x * y) filter (x => x.toString == x.toString.reverse)).max

The defect of this system was that even “xy.enabled” is changed to “true”, the feature xy was still not activated in the system.

It was not very easy to find the problem, but after a while of debugging, I finally got it: the original programmer made a mistake while coding, and reading the property “xy.enabled” is done by a method Util.getBooleanProperty(“xy.url”). Obviously, “xy.url” is wrong. I replaced it by “xy.enabled”, and it worked fine.

But why does the original code, with Util.getBooleanProperty(“xy.url”), not throw an exception? Obviously getBooleanProperty is supposed to read a string representing a boolean value, obviously xy.url does not a boolean value!

Yes, that’s true. The method getBooleanProperty reads like this:


public static getBooleanProperty(String property) {
return getProperty(property).equalsIngoreCase("true");
}


where getProperty(String p) returns the String value of property p stored in the property file.

getBolleanProperty really does not throw any exception if the value is not a boolean value at all!

If the original programmer had designed any syntax check, or simpley used Boolean.valueOf, which throws an exception if the parameter is malformed, debugging this problem would have been much easier. This is where exceptions are supposed to help.

Since I am programming Python now, I asked myself how to do foldr in Python.

The answer is surprisingly simple: just reverse x and y in the lambda expression, as well as the list. For instance, bin2int can be implemented in Python as:


def bin2int(x):
  t = copy.deepcopy(x)
  t.reverse()
  return reduce(lambda y,x: x+2*y, t)


Voila. There we got a foldr in python!

[1] Graham Hutton. Programming in Haskell. Cambridge University Press. 2007.

If you run this script, an error is reported:

Caught: groovy.lang.MissingPropertyException: No such property: b for class: groovy.lang.Binding

But if you remove the “def” type of variable b, surprise, it works!

def b = 5
println this.binding.getVariable("b")


This means that a variable of a script is stored in its binding only when the variable is not declared with a type. Interesting, no?

The reason for this strange behavior is that when in a script a variable is not declared, it is then stored in the binding of the script. If the variable is not yet contained in the binding, then it is added to the binding. On the other side, when a variable is declared in the script, then it is considered local, and not stored in the binding.

I don’t really undestand the reason of this rule, though. It only complicates things unnecessarity. Simply putting everything in the binding would be clear and leave the programmer no chance to make mistakes (in confusing binding or not binding).

Exploring the Groovy literatur to find more …