## Weekend Programming Challenge – Winners

First of all I would like to THANK YOU to all who participated in the first issue of our Weekend Programming Challenge!

Secondly as we did this challenge rules quickly, I greatly underestimated how difficult would be to judge which code is best π

I admit that I never expected such interest, so many submissions giving the short time we put to solve the problem.

The best long terms benefit for running this challenge is that it will be great source to learn new and interesting things looking at the submitted codes and solutions.

For instance I never have hear that GNU/Octave exist, and I never have seen code made in Scala language, same for the other colleges here at Olimex.

So we think we are under-qualified to comment or decide if the code for solution-10 and solution-19 is good or bad as we can’t π

What we very liked to see in the submitted solutions is that some authors make control of their inputs and check for different situations, this way optimizing their code, in case of the line to be vertical or horizontal no need to make divisions or sqrt(). This should optimize the speed as “if” is faster than */sqrt().

Also we like the control of the input and the verification if A=B although it’s subject to interpretation as the problem says A and B define Line, it’s always better if you check for ANY situation which may occur trather to count that A and B will be always different points. Do not get us wrong, the solutions which do not check if A=B also are correct in the spirit of the problem, but incomplete in our point of view.

This one line solution-18 is one of my personal favourites (although not optimized as always will do math even if the line is vertical or horizontal):

def d(A, B, C):

(a, b, c) = (P(A), P(B), P(C))
return (((c.x * (b.y – a.y) + c.y * (a.x – b.x) – a.x * b.y + b.x * a.y) ** 2 / ((a.x – b.x) ** 2 + (a.y – b.y) ** 2)) ** 0.5 if A != B else None)

Solutions: 1,2,3,5,6,7,8,9,10,12,13,15,16,20 have possible problem with division by zero as do not check their input.

We ask ourselves what happens if A==B in Solution 8 and 9.

Solution 4 check for horizontal line but forgot to check for vertical line.

Solution 11 is one of the best and offers two different way to complete the job with 2D geometry (first part) and with vectors (second part).

Same is for Solution 14,17,18 they do everything correctly.

Solution 10 and Solution 19 are impossible to be commented by us as we are out of knowledge π

From the very beginning we stated that this competition will be just for the sake of the challenge and for fun.

There will be no material prize intentionally – to keep away the overheating discussions which always supports competition with material prizes.

I see this challenge as something which may help us to improve our knowledge and see how different persons can see on one even simple problem from different angles, using different tools, and this way to make our own horizons wider π

So if we have to select winner for this round, they should be few and I would give winner badge to:

4,11,14,17,18 + eventually (10,19) π

Thanks again to all who submitted their solutions! Looking forward to see you again next Friday.

1. P.S. If you have any comments or suggestions how to make this WPC better please tell me, we can do it for the next issue this Friday!

• Ideas for the challenge:
1) Have some ‘ground rules’.
2) For some challenges (not all) restrict the languages that may be used if specialist coding environments provide a particularly ‘easy’ solution.
3) Set challenges for which a compilable language must be used.
4) Set challenges for which an interpreted language must be used.

Examples:
For “1”:
Code will be assessed on run-time and correctness (or accuracy*) of results;
Specify a level of built-in optimisation that will be allowed for compilable languages;
Inputs must be checked for errors and well-formedness (if this is not a built-in feature of the language/compiler/interpreter);

* For challenges that require approximations or soft-computing methods

For “2”:
For a challenge that involves vectors/matrices you could ban GNU/Octave and Matlab.
For a challenge involving text parsing, ban methods using regex.

• if we restricting the languages will miss some fun, we would never learned for Octava nor see Scala code if we applied these in the first round
this also may decrease the number of people who participate

I do not see problem that some languages may do some solution easier than other or may have ready library to deal with it

• Oh I agree, setting a restriction should only be done rarely, if at all! Perhaps restricting methods rather than languages? Then you could, for example, set a challenge to replicate the behaviour of some specified regex but without using regex?

2. Haha! Thank you (I think)! I’m looking forward to a new challenge on Friday to occupy me over the Easter weekend.

If it helps you at all GNU/Octave is a Matlab clone, so if you have/know anyone that can “do Matlab” then they should be able to read that. I can’t help with Scala though – I had to look that up on Wikipedia!

3. Emilio Moretti
Mar 26, 2013 @ 19:57:30

It was interesting to see other people solutions, but the problem should be detailed better next time.
how is returning “None” better than throwing an exception for cases that are out of the defined problem?
in my case, I throw a division by zero exception when an invalid line is defined (A==B). We could argue that the exception could be more descriptive or that it should be thrown when the Line instance is created. But I would still throw an exception for the exceptional case were the user calls the function for something it was not defined to solve (like the distance between two points).

• Yes, some general rule setting out the kind of (hopefully graceful) behaviour that should result if input occurs that means any part of the problem becomes “undefined” would be good.

4. A lot depends on your environment. A lot of systems I work on its more important that the code does not fail causing the program to halt than it is for the software to detect all the possible fault conditions, which is why I missed the A=B situation in my code. However, because I made sure the division by zero could not occur, it would not fail, it effectively chose the vertical line through A and B and measured the distance from that. I’ll confess that was a happy side-effect of my avoiding the vertical line problem as I did not consider the A=B problem directly since the problem stated A and B defined a line.
In my (distressingly!) long career as a programmer I have had to deal with a lot of software that crashed on a regular basis because the programmers where very pedantic about throwing exceptions but not so pedantic about catching them. It may seem “wrong” to return zero for negative square roots, or 1 for divide by zero, but if it means your airplane doesn’t fall out of the sky because the fuel gauge returns -0,22 due to a glitch, then maybe its not all bad…..

Mar 26, 2013 @ 22:39:00

Scala is not that hard. At least the basic parts of the language. My solution is obscure not because of Scala but because it was an exercise. It’s not a perfect solution because I’m still learning Scala which SOMETIMES can become a bit hard.
Don’t restrict the languages or I won’t learn Scala better thanks to the challenges.
You have to provide some “dangerous” and tricky input data, which participants must use as input to run the unit tests they must write themselves, and the tests must pass (this is difficult if input is tricky). You also have to provide the correct output for that input, which participants can use in assertions: this way the textual description of the problem would become less ambiguous and less important.
Participants can also write code which prints the total execution time (the fastest program according to their own estimation wins in the “speed” category), try to write the shorter program without considering unit tests (the shorter wins the “shortness” category), try to invent the most original mathematical or logical algorithm (Google helps the judgement), try to write a library for the task which they unit-test accessing it from as many different languages as they can (that wins in the “portability” category, I’m skilled at this) and finally a “mobile” category.

Mar 26, 2013 @ 22:51:28

Ok, the “mobile” category is a joke π but another category could be “recursive function”. Most programmers find recursion hard because it’s not used often in real life (it can cause stack overflow, except for tail-call optimized recursion in Scala). I find it hard, too, even if I used it.
People, if you know something that is hard for most programmers, propose it as another category π

• “Best commented” ? Most of the programmers I work with seem to find that impossible π

Mar 26, 2013 @ 23:04:33

Ian, I thought about the “most commented” category, too, but that is not a good measure. A better one would be “better self-documentation in code” (I mean, typed function signatures, descriptive variable names, javadoc annotations etc.)
Another category could be “code quality”. For example JSLint is a code analysis tool for Javascript with which Javascript code can be judged

• @Emiliano Providing examples of input that the programme must handle correctly/gracefully is a fantastic idea – it would certainly have cut-short all the discussion about A=B on week 1.

@Ian/Emiliano I agree that self- or explicit- documentation should be a measure, not just because it will help people not familiar with the language understand what’s going on, but also because it’s what good code *should* do (by most measures of ‘good’)!