Comments on: Project Euler Problems 1 and 2

By: The Great VB vs F# Euler Shootout Problem 1 | Do Loop Until You Die

The Great VB vs F# Euler Shootout Problem 1 | Do Loop Until You Die — Wed, 24 Sep 2008 03:09:54 +0000

[...] was going to solve the problem in VB the standard brute force iteration way until I came across the following blog entry. Again, I take no credit for the following code. It has been scoffed from another [...]

By: Path To Nirvana

Path To Nirvana — Fri, 18 Jul 2008 18:31:20 +0000

ProjectEuler Problem 1…

I have been learning Haskell, since couple of weeks. I am following the online book, Real World Haskell. For fun and learning, I decided to solve some problems from ProjectEuler. My solution for the first problem went through 3 stages, as I learnt more…

By: Hugh Redelmeier

Hugh Redelmeier — Fri, 11 Apr 2008 14:38:04 +0000

-jn-:
Functional programming didn’t lead you to the fastest solution since you didn’t get to the fastest solution. Yours has a loop (recursion). My bc solution (above) has none. It also happens to be side-effect free and hence functional.

My version takes a little bit of mathematical reasoning to come up with, or a memory of the tale of Gauss summing the integers 1 to 50 too quickly for his teacher http://www.americanscientist.org/template/AssetDetail/assetid/50686?&print=yes

By: -jn-

-jn- — Thu, 10 Apr 2008 02:24:30 +0000

I finished the saga of Project Euler problem one, and found that the functional approach led me to the fastest solution in an unexpected way ( http://joelneely.wordpress.com/2008/04/09/the-burden-of-fp-part-3/ ). Thanks for the encouragement, and for keeping your series going.

By: The burden of FP « Sliding up the banister

The burden of FP « Sliding up the banister — Sun, 06 Apr 2008 16:58:33 +0000

[...] not) brings me to Project Euler and the title of this post. I had heard of Project Euler before, butthis post enticed me to visit the site. One look and I was [...]

By: Hugh Redelmeier

Hugh Redelmeier — Mon, 24 Mar 2008 19:03:28 +0000

Problem 1 seems to be quite efficiently solved in the standard UNIX bc program. O(1) (ignoring the fact that bc uses arbitrary precision numbers).
$ bc
define s(n) { return n * (n + 1) / 2 }
define t(n,m) { return s((n – (n % m)) / m) * m }
t(999,3) + t(999,5) – t(999,15)
233168
quit

s(n) is the sum of the integers 1 to n, inclusive.
t(n,m) is the sum of all the integers that are multiples of m between 1 and n, inclusive.
The problem answer is the (sum of multiples of three) + (sum of multiples of five) – (sum of multiples of 15 since they would have been counted twice).

Your C# program would choke if you changed 1000 to a googol. The BC program says:
23333333333333333333333333333333333333333333333333333
33333333333333333333333333333333333333333333333166666
66666666666666666666666666666666666666666666666666666
66666666666666666666666666666666666666668
I haven’t checked if that is correct. but it has about the right number of digits.

By: PJ6

PJ6 — Sun, 23 Mar 2008 17:19:15 +0000

Actually, someone throw Ackermann at it and see what it does…

By: PJ6

PJ6 — Sun, 23 Mar 2008 17:15:17 +0000

J: The DotNet Framework’s compiler works extremely well. I would expect that the newer structures are supported with optimizations that one could otherwise only achieve writing IL by hand.

By: J

Sun, 23 Mar 2008 10:30:50 +0000

I quote “C# could solve problem 1 very neatly – can it keep up the pace in problem 2? Actually, yes it can, after a fashion.”

While efficient writing is one thing, what happens when the code hits the silicon? Do they compile efficiently? Does the processor run faster with one snippet over another?

Many get spoiled by GHz machines with GB of RAM, but those of us in the embedded market still worry about code size and execution speed…