Scala: First and Last Element of a Set?

I just came into two functions of class Set of Scala: head to return the “first” element of the set, and last to return the “last” element. Clearly, this is a case of unfortunate design. Since the elements of a set are not ordered, there is neither a first one nor a last one. I wonder why the Scala team made this design.

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!

Project Euler Problem 1

The first problem of Project Euler is pretty simple. It reads:

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.

Project Euler

Project Euler is a very nice collection of math/programming problems. It provides very valuable exercises for math/programming. While the first problems are easy to solve, the others may be pretty challenging.

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

Greedy SmartSVN

Did you know deinstalling SmartSVN requires to close quite a few other applications?

A Simple Mistake of Using Java Exception

Recently I ran into the following code in a legacy system:

try {
...
} except (Exception e) {
System.out.println(e.getStackElement());
}


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().

One Liner Scala for Project Euler Problem 4

It only takes one line code to solve Problem 4 of Project Euler in Scala (and many other functional programming languages):

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

 

 

How to Use Exceptions: An Example

Today I had to debug a legacy system, including a feature, let me call it xy. In the property file, there were two properties concerning this feature: “xy.enabled” and “xy.url”. “xy.enabled” is used to indicate whether the feature should actually be activated, and if it is true, the system needs to read some data from a URL stored in “xy.url”.

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.

Foldr in Python

In [1, p.70] Graham Hutton gives a nice example of the power of the function “foldr” in Haskell. The following function bin2int provides a very elegant way to convert a binary number to a decimal number:
bin2int = foldr(\x y -> x + 2 * y) 0

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.

Something surprising in Groovy Meta Programing

Suppose you have a Groovy shell which contains the following code:

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


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 …

Ten Things Oscar Nierstrasz Hates About Object-Oriented-Programming

Found at “The Journal of Object Technology“