Xmas Puzzle 2020 (1)

Peter Nachtwey said:

Also, once a/b are selected that narrows down the choice ...

Click to expand...

For that matter if a<c then a<4, which can be proven pretty quickly for the left-hand double equality (a/b=c/d=...), and I am pretty sure with a bit more work also for the right-hand (a/b=c/de-...) as well.

Here's a clue to one of the contentious issues.

The one the clue refers to is the one that I didn't think was particularly contentious!

Probably too subtle, it's a decimal point.

Probably too subtle, it's a decimal point.

Click to expand...

I interpreted the clue as equally subtle; nil, nothing, nada.

I wrote Logix5000 code to test for solutions, but the number of iterations proved too much for the maxed out watchdog, so i gave up and deleted all the code. After deleting all the code I realized I could have done a fault routine and let it carry on regardless... DOH !

One question I have though, is to what precision are the fractions ? pi is nowhere equal to 22/7

daba said:

One question I have though, is to what precision are the fractions ? pi is nowhere equal to 22/7

Click to expand...

The fraction I use for pi is 355/113. I used this ratio all the time when programming 16 microprocessors in assembly code.
There are other ratios or series that are even more precise estimated of PI but 355/113 is the most practical one and it provides more precision that is necessary most of the time.

daba said:

I wrote Logix5000 code to test for solutions, but the number of iterations proved too much for the maxed out watchdog, so i gave up and deleted all the code. After deleting all the code I realized I could have done a fault routine and let it carry on regardless... DOH !

One question I have though, is to what precision are the fractions ? pi is nowhere equal to 22/7

Click to expand...

I was thinking one permutation per scan. 9! yields around 300k permutations, so at 1-2ms/scan, it would take 5-10minutes to complete.

drbitboy said:

I was thinking one permutation per scan. 9! yields around 300k permutations, so at 1-2ms/scan, it would take 5-10minutes to complete.

Click to expand...

I might have another go at this tomorrow - I like the idea that a PLC can solve a problem posted on a PLC forum, even if it takes several minutes ! ....

daba said:

I might have another go at this tomorrow - I like the idea that a PLC can solve a problem posted on a PLC forum, even if it takes several minutes ! ....

Click to expand...

What did you do to generate the permutations?


I was going to try Heap's Algorithm.

It's a bit more than five minutes though: Heap's Algorithm has a significant fraction of the passes through the main loop that do not generate a permutation; those extra scans could probably be eliminated with a bit more logic.

It takes 986,409 passes through the main loop to get the 300k+ permutations.

RSLogixMicroStarterLite/MicroLogix 1000 example below; it ran about one ms/scan on average, so it was 16-17 minutes, I think; it did find the four basic solutions with a<b and a<c.

One of the contentious answers is as follows:



.2/1 = .6/3 = 97/485


This increases the number of combinations somewhat

"somewhat" heh.

I put my PLC code back in to test for solutions, and sort of got it working.

It found 4 solutions (pure solutions that is, nothing sneaky with decimal points and the like).

I wanted to see if it could be done in one scan of the code, so used a series of nested FOR loops, and basically blindly iterating every damn combination. But the I had to do checking in the innermost loop to ensure we had all different values for a-j. This obviously slowed the process considerably, so Heap's algorithm would dramatically reduce the time taken.

First thing the checking did was RETurn if A>=B, or C>=D, then I just matrix checked the others against each other, RET'ing at every conceivable opportunity. If the numbers got through all the checks, I calculated and compared the fractions.

Anyway - it found the 4 solutions as follows.....

1st : @08:10 minutes
2nd : @09:40 minutes
3rd : @15:15 minutes
4th : @17:27 minutes

At 33 minutes in, the task watchdog faulted the processor (I had set it to maximum = 2000 mS), but at the time of faulting the a, b, c, d values were 6, 9, 7, 2 respectively, and I cannot believe there would be any more solutions above that. It's something I could test for by starting a & B at, say 5, and see if any more solutions exist, but I doubt it.

Incidentally, I had written a Program Fault routine to reset the Type 6, Code 1 task watchdog fault, but this did NOT work - Then realised a Task fault should be in the Controller Fault Handler, so I moved my fault handling to there, and it didn't work there either.... I believe the controller won't let you reset a watchdog fault.

So my answer is there are only four possible non-contentious solutions. (We are talking about the left hand equation, haven't thought about the other, yet).

drbitboy said:

It's a bit more than five minutes though: Heap's Algorithm has a significant fraction of the passes through the main loop that do not generate a permutation; those extra scans could probably be eliminated with a bit more logic.

Click to expand...

I like brute force but generating all the permutations is not required. You could just start with a list of numbers 1-9 and pass that to a function and then assign one of the numbers to a second list that represents the characters. As one makes recursive calls and the numbers from the list of numbers is used the number is removed from the list. When bad option is found then back up and try another number. The advantage is that you don't generate all the permutations because as soon as an invalid solution is found you back up and don't try the other combinations lower in the tree. This is somewhat how a chess program works but closer to how a lumber optimizer fills a volume with the optimal number and size of boards.

The problem is that PLCs don't have lists but you could get by with bit sets. The problem then is generating an encode or decode function like some of the old PLCs had.