OK, was able to throw out half the starting values but it still takes 39 seconds to run.

Not very impressed with that.

Well, there you go then...

Remove the recursive b*ll*cks and it runs in 200ms!

LOL!

OK, so I found out that the erroneous numbers were somehow caused by trying to store too many primitive variables rather than because the numbers exceeded the storage capacity.

I've rewritten it using brute force (checking for unnecessary values before running) and not storing anything. I can do it now using unsigned long longs instead of having to use bigIntegers and it runs in 250ms.

If I try to store any values to increase the speed for repeated values it actually increases the length of time it takes for the program to run!

Stupid computers.

Thought of a solution to 24 last night.

It worked

Need to write a program for it but it is fast.

82 and 83 done with almost the same code

85 done.

Solved it on the first run of the program with a run time of around 29ms!



I was very pleased with that!

I didn't have to look up any formulae or algorithms either. Just worked out how to calculate the total rectangles on paper and then wrote an algorithm to find the solution over the possible range.

Altered it slightly (just changed the loops) and it now runs in 3 ms

And now done 38.

Program took about 10ms to run and was right first time

And 36 now

Done a total of 35 problems now!

Written a program for problem 59 but it takes far too long and is far too "dumb". It's just a 100% brute force method.

Going to optimise it with a couple of safe (I think) assumptions which should reduce the run time by around 26 times (at least) LOL!

Yay! I got my XOR function wrong which is why it was throwing me out.

In the end I brute forced all possible passwords against the encryption and filtered the results based on English language statistics and only one password came back

Takes about 3 mins to run though. Although that's on my slow PC with a high level language.

Number 2 just done...

...with about 10 lines of code, which is pretty good for me.

Nice

**Spoiler**

with Ada.Text_IO; use Ada.Text_IO;
with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;

procedure Sum_Of_Fib_Terms is

Sum_Total: Integer := 2; --Pre-load Total with first even value (That's Cheating! -Ed)

Fib_A : Integer := 1; --Pre-loading the three generator variables
Fib_B : Integer := 2;
Fib_C : Integer := 0;

begin

while Fib_C <= 4000000 loop
Fib_C := Fib_A + Fib_B; --Fibonacci Sequence Generator:
Fib_A := Fib_B + Fib_C; --Right-shifting operations saves the time of
Fib_B := Fib_C + Fib_A; --left-shifting the variables

Sum_Total := Sum_Total + Fib_B; --Increment total with even value

end loop;
Sum_Total := Sum_Total - Fib_B; --get rid of the last answer
Put (Item=> Sum_Total, Width => 15); --Screenprint the answer
end Sum_Of_Fib_Terms;

Dammit - this is getting addictive. Brute force is easy for number 3.

I've come up with a much more elegant algorithm but I've just discovered I'll need at least one goto.

Bugger

[edit] Just thought of how to do it with return

Right, I've been working on a Sudoku algorithm for problem 96.

I first wrote an algorithm to just fill in the obvious ones (i.e. if 8 different numbers appear in the same column, row or mini grid then the remaining number goes in the current slot).

That didn't do much but I kept it.

I then implemented a thing that looked at the numbers that could go into the current space. If any of the numbers can't go into another square in the mini grid then place it there.

This managed to solve about 10 or 11 out of the 50.

I've now implemented a system that checks an assumption of a number. i.e. this slot can take either 4 or 7. Check 4, does that work or does it break the grid? If it works then place 4 and repeat the first set of checks.

I've now got a program that solves 43 out of the 50 sudoku grids.

The remaining 7 all get broken by the assumption system because they get set so that they become unsolvable

It's good fun though