c4countdown

This thread is probably going to be of little interest the majority of the forum members, but those of you who are statistically inclined might find the idea a little interesting.

I thought the idea of analysing possible numbers selections and targets might be an interesting idea, 4 large clearly being the easiest to analyse because of the much smaller possible number of selections.

I make there to be 55 possible combinations of 2 small, and 899 possible targets. So that's a possible 49445 selections. My thoughts were that, in theory, if somebody could run all these combinations through some sort of programme and somehow record the results it would be interesting to then sort through the results to look ar some statistics. For example:

-Which target is the least accessible?
-Which combination of 2 small numbers gives access to most solutions
-How many targets are completely impossible with 100 75 50 25 1 1 as the selection
-Are there any targets that are possible no matter what the selection? (apart from the ones you can get using just the larges: 101, 102, 103, 105 etc.)

My limited knowledge of computing tells me that running all 49445 selections and recording the results in some digestable way would be a very time consuming task, so this idea will probably never come to fruition, but yeah, it would be cool.

Whaddayall think?

JackHurst wrote:I make there to be 55 possible combinations of 2 small, and 899 possible targets. So that's a possible 49445 selections. My thoughts were that, in theory, if somebody could run all these combinations through some sort of programme and somehow record the results it would be interesting to then sort through the results to look ar some statistics.

I believe this (together with 3/3, 2/4, 1/5 and 0/6 selections) has been done at some time, and discussed somewere. Maybe someone with a better memory than mine can point us in the right direction.
One result I do seem to remember reading was that the selection which is least likely to give an impossible target is 2 large and 4 small.
I'd certainly be interested in revisiting this.

Is it not 45 combinations of 2 small?

Nope 55 like Jack said. For the 2 small you can have

1,1 1,2 1,3 1,4 1,5 1,6 1,7 1,8 1,9 1,10
2,2 2,3 2,4 2,5 2,6 2,7 2,8 2,9 2,10
3,3 3,4... etc
which totals 10+9+8+7+6+5+4+3+2+1 combos = 55. I'm guessing you forgot there was a 10?

Dinos Sfyris wrote:Nope 55 like Jack said. For the 2 small you can have

1,1 1,2 1,3 1,4 1,5 1,6 1,7 1,8 1,9 1,10
2,2 2,3 2,4 2,5 2,6 2,7 2,8 2,9 2,10
3,3 3,4... etc
which totals 10+9+8+7+6+5+4+3+2+1 combos = 55. I'm guessing you forgot there was a 10?

More likely he forgot there are two of each small number.

Dinos Sfyris wrote:Nope 55 like Jack said. For the 2 small you can have

1,1 1,2 1,3 1,4 1,5 1,6 1,7 1,8 1,9 1,10
2,2 2,3 2,4 2,5 2,6 2,7 2,8 2,9 2,10
3,3 3,4... etc
which totals 10+9+8+7+6+5+4+3+2+1 combos = 55. I'm guessing you forgot there was a 10?

I thought the combinations for 2 from 10 was done by ((10*9)/(2*1)), but wasn't sure so I asked, cheers Dinos

james doohan wrote:I thought the combinations for 2 from 10 was done by ((10*9)/(2*1)), but wasn't sure so I asked, cheers Dinos

That's how many ways there are of choosing 2 numbers from 10, which is slightly different to the problem here.

Howard Somerset wrote: One result I do seem to remember reading was that the selection which is least likely to give an impossible target is 2 large and 4 small.
I'd certainly be interested in revisiting this.

According to this:http://www.apterous.org/statland.php?se ... mbers_diff only one game of 2 large proved to be impossible out of 127000. Is there any way to find what the selection was?

Liam Tiernan wrote: According to this:http://www.apterous.org/statland.php?se ... mbers_diff only one game of 2 large proved to be impossible out of 127000. Is there any way to find what the selection was?

Here.

I'm currently building a database of all 4-large games and their optimal solutions. Should take about 5 hours. I'll publish the results after that. Also it should be easier to answer any other questions once the database is on hand.

The results are in. Here are the answers to your first questions (I think), feel free to throw follow-ups at me.

Difficult pairs
This table shows the pairs of smalls which are most likely to produce an unachievable target. The total number of impossible targets (out of 899) is also shown. Predictably, this table is mostly dominated by duplicate pairs, and the 1 tends to be hampersome. However, the (5,10) is harder than I expected. Also (1,1) was the only pair to generate any games where it is impossible to get within ten; 26 of them, in fact. This surprised me a lot.

Incidentally, here's the complete table for duplicate pairs.
Easy pairs
Contrary to my (loose) expectation, no pair allows every target to be made. However, the following pairs offer the widest range of targets. The number of available targets (out of 899) is also shown.
Hard targets
This table shows the targets which are the least often possible, and the number of pairs with which they are impossible (out of 55). This tallied with my intuition that larger targets are generally harder.


Easy targets
There are 202 targets which can be generated with any pair. The majority of these are, presumably, made with just the 4 large, although I'll leave it to someone else to fish through and delete those. Here's the full list: 101, 102, 103, 104, 105, 106, 107, 108, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 133, 134, 135, 136, 137, 138, 139, 140, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 160, 162, 167, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 210, 211, 222, 223, 225, 226, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 256, 258, 267, 271, 272, 273, 274, 275, 276, 277, 278, 279, 280, 292, 294, 295, 296, 297, 298, 299, 300, 301, 302, 303, 304, 305, 306, 308, 310, 322, 324, 325, 326, 328, 336, 342, 344, 346, 347, 348, 350, 352, 353, 354, 356, 357, 364, 372, 375, 376, 378, 396, 397, 399, 400, 403, 404, 406, 425, 446, 450, 453, 454, 456, 475, 492, 496, 500, 504, 525, 550, 575, 600, 624, 625, 650, 675, 700, 725, 750, 775, 800, 825, 850, 900, 925, 938, 950, 975.

Charlie Reams wrote:Easy targets
There are 202 targets which can be generated with any pair. The majority of these are, presumably, made with just the 4 large, although I'll leave it to someone else to fish through and delete those. Here's the full list: [blah blah blah]

32 of those targets can be achieved with just the big 4. Here is the amended list:
104, 106, 107, 108, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 122, 123, 124, 126, 127, 128, 130, 131, 133, 134, 135, 136, 137, 138, 139, 140, 142, 143, 144, 145, 148, 149, 151, 152, 155, 156, 157, 158, 160, 162, 167, 170, 171, 172, 174, 176, 178, 179, 180, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 198, 199, 201, 202, 204, 205, 206, 207, 208, 210, 211, 222, 223, 226, 244, 245, 246, 247, 248, 249, 251, 252, 253, 254, 255, 256, 258, 267, 271, 272, 273, 274, 276, 277, 278, 279, 280, 292, 294, 295, 296, 297, 299, 301, 303, 304, 305, 306, 308, 310, 322, 324, 325, 326, 328, 336, 342, 344, 346, 347, 348, 352, 353, 354, 356, 357, 364, 372, 375, 376, 378, 396, 397, 399, 400, 403, 404, 406, 425, 446, 453, 454, 456, 475, 492, 496, 504, 550, 600, 624, 650, 700, 750, 775, 800, 825, 850, 900, 925, 938, 950, 975.

Thats quite interesting, how long did it take you to do all that?

JackHurst wrote:Thats quite interesting, how long did it take you to do all that?

About half an hour to write the program, six hours to build the database, and then another half-hour to compile the results you wanted.

I love you a bit.

I was interested to see that 938 was in the list of easy targets but 937 wasn't, considering that the method used to obtain most of them would be based around the calculation (50*75*25)/100=937.5. This prompted me to realise that If you can make 1 or 2 out of the smalls, you will always be able to get 938 and 937. There are only 12 such combinations of 2 smalls which you can't make 1 or 2 from, so the discrepancies between 938 and 937 must lie within these selections.

Another point I find very interesting is that if you can make (2/3) from of the smalls, there is a method you can use involving fractions, which gets 937 and 938 but is against the rules:

((50*25+(2/3))*75)/100=938
((50*25-(2/3))*75)/100=937

The reason it is against the rules is that you can't reorder the working so that (2/3) does not appear as a fraction. All examples I have seen before this where you can use a fraction in your working, can be reordered and legalised, for example:

100 75 50 25 4 6---->222

((50*6)-4)*(75/100)=222 is an illegal method using fractions, but it can be rewritten as :
((50*6)-4)*75)/100=222 which is legal as it does not involve fractions.

But anyway, it only turns out that the only combination of 2 smalls from which you can make (2/3), but you cant make 1 or 2 from is 6 and 9.

So if 938 and 937 are possible with 6 and 9 using some other method, its turns out that my "interesting observation" isn't as interesting as first thought.

And according to a solver I just used, there isn't a legal method for 937, but there is one for 938:
(25-6)*50-(9*100)/75=938

So yeah, the moral of this story is that if you ever face the selection:
100, 75, 50, 25, 6, 9--->937, you can do:
((50*25-(6/9))*75)/100=937 to get the solution but you wont get nay points. Sucks doesnt it?

Wouldn't you be able to do this fraction method if you used brackets in the notes declaration, but not if you left it to the methodology thing, which doesn't have brackets and would leave you unable to commit to a non-integer?

I base this on, say, if you do 2/3 you won't be able to 'commit' to the decimal/fraction result, but it still doesn't stop you dead in your tracks. So I think you can then add, say, *75 on the end of that and then you WILL be able to commit to 50, no?

Good point Matt. I guess in theory you might be able to get away with it in the notes, but you definitely wouldn't be able to input the solution onto the interface. I think you're suggesting that after you have 2/3 down, you add on the operation to multiply that by 75, but to do that you would need brackets, so its not possible on the interface. So basically, as i undertand, you are suggesting that clicking [2] [/] [3] [*] [75] would give you 50, but it would give you 2/225 because of bidmas.

JackHurst wrote:So basically, as i undertand, you are suggesting that clicking [2] [/] [3] [*] [75] would give you 50, but it would give you 2/225 because of bidmas.

With BIDMAS, division and multiplication have the same priority so you read from left to right, giving you 50 (you can verify this by using a calculator). As for apterous' implementation of this, it'll be down to the way Charlie wrote the code.

Edit: You can't do this in the GUI, as I just tried [2] [/] [3] [*] [6] (which should give 4) and it wouldn't let me commit.

Yeah, I was under the impression that would give 50. Either way, the point of interest is then whether or not there's a difference in the functionality achievable between the notes method and the method method.

Matt Morrison wrote:Wouldn't you be able to do this fraction method if you used brackets in the notes declaration, but not if you left it to the methodology thing, which doesn't have brackets and would leave you unable to commit to a non-integer?

Nope, all the internal arithmetic is done with integers. The method interface is secretly just generating text for the Notes box, so you can't beat the system that way.

Charlie Reams wrote:

Matt Morrison wrote:Wouldn't you be able to do this fraction method if you used brackets in the notes declaration, but not if you left it to the methodology thing, which doesn't have brackets and would leave you unable to commit to a non-integer?

Nope, all the internal arithmetic is done with integers. The method interface is secretly just generating text for the Notes box, so you can't beat the system that way.

Just as a matter of personal intrigue, do you literally just work with Java ints and if the user attempts to make a fraction, use error handling to enforce the "Give up" selection?

Simon Myers wrote:

Charlie Reams wrote:

Matt Morrison wrote:Wouldn't you be able to do this fraction method if you used brackets in the notes declaration, but not if you left it to the methodology thing, which doesn't have brackets and would leave you unable to commit to a non-integer?

Nope, all the internal arithmetic is done with integers. The method interface is secretly just generating text for the Notes box, so you can't beat the system that way.

Just as a matter of personal intrigue, do you literally just work with Java ints and if the user attempts to make a fraction, use error handling to enforce the "Give up" selection?

Yep.

There's a lot of scope here for potential Project Euler problems, n'est-ce pas?

Charlie Reams wrote:About half an hour to write the program, six hours to build the database, and then another half-hour to compile the results you wanted.

Are you planning to do similar for the other four choices of selection?

A quick estimate, based on the above, suggests:
a few minutes to adapt your program for each of the other four selections
a day under two months to build the data base
open-ended for the analysis

I look forward to some interesting results around mid July.

Howard Somerset wrote: Are you planning to do similar for the other four choices of selection?

I could do. The annoying thing is that the numbers solver is very fast, and about 5.9 of those 6 hours were spent waiting for the database engine. If I tune that a bit, it would be pretty tractable.

I remember doing some analysis of this, probably back in 2007, and posting the results on the old forum. I've still got the spreadsheets I created then and could dig out some facts if folks are interested. Large primes, like 937, tend to be hardest.
One interesting point if that you are about twice as likely to be able to find a solution using 5 numbers as needing all 6.

Here are some boring statistics extracted from my data :

There are 13,243 different sets of 6 numbers, giving a total of 11,905,457 possible numbers games. Of these 10,858,746 (91.21%) are solvable.
1,226 sets can solve any target between 101 & 999.
The most difficult target is 947 which can be solved with 9,017 different sets. The easiest are 102, 104 and 108 which can each be solved with 13,240 sets.

Of course, any valid statistical analysis of this would need to take into account that sets are not equally likely to come out. With 6 small, you are 32 times more likely to get 1,2,3,4,5,6 than 1,1,2,2,3,3.

Ray Folwell wrote:1,226 sets can solve any target between 101 & 999.

I wonder if there's a way of splitting this up further to decide which is the "best". Maybe based on number of solutions (although as discussed previously, this isn't necessarily easy to define). Or maybe if you carry on past 999, which set of numbers can hold out the longest?

One definition of 'best' would be which set used the least number of numbers in total to solve all 899, so count 2 if you can solve with 2 numbers up to 6 if you have to use all 6 ( does that make sense?). It's also something I could extract fairly easily.

On that method, the 'best' set is 4, 7, 9, 10, 75, 100 which solves all 899 with a total of 3661 numbers, an average of 4.07 numbers per solution. There is only one target that needs to use all six of those numbers to solve.

I leave finding that target as an exercise for the reader (or Kai).

I've just discovered that 6, 7, 8, 9, 10, 100 can solve each of the 899 using no more than 5 numbers

<3

Ray Folwell wrote: With 6 small, you are 32 times more likely to get 1,2,3,4,5,6 than 1,1,2,2,3,3.

I think it's actually 64 times more likely.

Ray Folwell wrote:One definition of 'best' would be which set used the least number of numbers in total to solve all 899, so count 2 if you can solve with 2 numbers up to 6 if you have to use all 6 ( does that make sense?). It's also something I could extract fairly easily.

On that method, the 'best' set is 4, 7, 9, 10, 75, 100 which solves all 899 with a total of 3661 numbers, an average of 4.07 numbers per solution. There is only one target that needs to use all six of those numbers to solve.

I leave finding that target as an exercise for the reader (or Kai).

I've just discovered that 6, 7, 8, 9, 10, 100 can solve each of the 899 using no more than 5 numbers

All very interesting stuff. But just out of interest, could you work out which number set can solve the most consecutive numbers starting with 100 or 101 (I'm sure the answer would be the same)?

Not easily, the data I've got is for the valid targets of 101-999. I don't think it would be simple to modify my program to get the result you want.

Gavin Chipper wrote: All very interesting stuff. But just out of interest, could you work out which number set can solve the most consecutive numbers starting with 100 or 101 (I'm sure the answer would be the same)?

I never can resist a challenge.

2, 3, 5, 8, 9, 100 can solve everything between 101 and 1912.

The next best set stops at 1868, so this is better by a long way

Ray Folwell wrote:

Gavin Chipper wrote: All very interesting stuff. But just out of interest, could you work out which number set can solve the most consecutive numbers starting with 100 or 101 (I'm sure the answer would be the same)?

I never can resist a challenge.

2, 3, 5, 8, 9, 100 can solve everything between 101 and 1912.

The next best set stops at 1868, so this is better by a long way

Excellent work! Presumably this selection can also do 1-100? I suppose it wouldn't take that much effort for me to do manually.

The smallest number than cannot be solved with any set is 62663.

Hey Charlie, how about investigating how many targets between 1001-9999 can be got using just the 6 large. The reason I say this is that I just did a 6 large attack, and I could pretty much always get close to the target without even using the smalls.