Brian Schröäer wrote:
> On Mon, 15 Nov 2004 08:48:24 +0900
> Dennis Ranke <dennis.ranke / epost.de> wrote:
> 
> 
>>Here is a small update to my solution. A simple optimization speeds up 
>>the solver by a factor of nearly two. Now I'm down to 5 seconds for the 
>>worst case on this machine :)
>>
>>[snip]
> 
> 
> Interesting read. I never thought about building the terms bottom up
> instead of top down ;).  I was in such a recursive mindset.

It seems to me that this weeks quiz received the largest amount of 
really unique approaches of all the quizzes, yet. That's what makes it 
this interesting. :)

> I hope your ideas don't force me to rethink my solutions and spend 
> even more time that I don't have ;).

Oh yes, it's hard to lay down this quiz. ;)

> One thing I noticed is, that you used:
> 
> 
>>     best_difference = (@target * 1000).abs
> 
> 
> this shurely works but is cheating. Why not use:
> 
> 
>>     best_difference = 1.0/0.0
> 
> 
> That would really be bigger than any other difference you'd encounter.

True, good idea.

> It is not possible to find all solutions, using your programm, did I understand this right?

This is correct, it will only find one solution in it's current 
incarnation, as it just throws away a new term if it has already found 
another term with the same value using the same input numbers. However, 
it would be easily possible to remeber those terms instead (say, the 
first term found holds a list of duplicates) and then iterate through 
all the possible solutions in the end. This shouldn't slow down the 
calculations a lot (the main factor would be the creation of a lot more 
Term instances), but it would take a lot more memory.