February 2019
 

[url]http://www.research.ibm.com/haifa/ponderthis/challenges/February2019.html[/url]

Any tips on pseudocode to identify the endpoint? I think I figured out the rest on my own.

My problems are the following:
1. I don‘t see the 64 different values of the relatedness score. I have found a paper which explains the „19276“, but I have not found the complete WORD.
2. I don‘t see any correlation between the 14 and the 64.
3. I don‘t see the sense of the condition „with each digit being used exactly once“- the screenshot contains 0,444444 and so on.
I think that I have completely misunderstood the challenge.

[QUOTE=Dieter;508268]My problems are the following:
1. I don‘t see the 64 different values of the relatedness score. I have found a paper which explains the „19276“, but I have not found the complete WORD.
2. I don‘t see any correlation between the 14 and the 64.
3. I don‘t see the sense of the condition „with each digit being used exactly once“- the screenshot contains 0,444444 and so on.
I think that I have completely misunderstood the challenge.[/QUOTE]

1. You don't need to see the values. However, examining how many unique scores are possible for each number of scorers is useful to discover the pattern of increase.
nScorers nValues examples

1 2 0,1

2 3 0,.5,1

3 5 0,.33,.5,.66,1

4 7 0,.25,.33,.5,.66,.75,1

5 11
6 13
7 19
8 23
9 29
10 33
11 43
12 47
13 59
14 65
2. See above
3. This endpoint refers to the equivalent of the 64/65. You would need to identify a 10 digit number of possible values, such as 1,023,456,789 which contains each digit exactly once.

I see that you can earn an asterisk if you solve the problem in hexadecimal. As of the most recent update, nobody had done so.

Alas, I don't know a slick'n'quick way to get a hold of the hex expression for an integer. Even if I did, I [i]also[/i] don't know a slick'n'quick way of doing the requisite integer computations to produce the numbers to be tested. Knowing the approximate size of the integers that need to be tested, I reckon it would take me quite a while just to get there. Pass.

[QUOTE=c10ck3r;508273]1 2 0,1

2 3 0,.5,1

3 5 0,.33,.5,.66,1

4 7 0,.25,.33,.5,.66,.75,1
[/QUOTE]

So, is the pattern the number of distinct fractions a/b such that 0<=a<=b<=n?

And we're looking for 10 digit (resp, 16 hex digit) count with all the digits used?

If so, there are 50 possible solutions in base-10 (found using PARI script in 0.3s).

[QUOTE=Dr Sardonicus;508337]I see that you can earn an asterisk if you solve the problem in hexadecimal. As of the most recent update, nobody had done so.

Alas, I don't know a slick'n'quick way to get a hold of the hex expression for an integer. Even if I did, I [i]also[/i] don't know a slick'n'quick way of doing the requisite integer computations to produce the numbers to be tested. Knowing the approximate size of the integers that need to be tested, I reckon it would take me quite a while just to get there. Pass.[/QUOTE]

The difficult bit of this problem is producing the initial numbers. Once you have them you can solve it in any base. You can make a list of the digits, sort them and check for duplicates.
I found a really simple solution based on OEIS. I am not certain whether it is correct if anyone has solved I would like to confirm my answer with them before sending it. It seemed way too easy to me.
Speed is going to be an issue for base 16 based on the size of the smallest pandigital number in base 16 [url]https://en.wikipedia.org/wiki/Pandigital_number[/url]

[QUOTE=henryzz;508345]I am not certain whether it is correct if anyone has solved I would like to confirm my answer with them before sending it. It seemed way too easy to me.
[/QUOTE]
Without revealing the n's:
Smallest = 1093486725
Largest = 9314028765

Assuming there are no mistakes in the code, the smallest value for 16 digits is 1162978044206898255

I've stopped the script at appr n=2.63e9 (2.3 hrs of runtime) and the largest value found so far is 2106319367353202805 (789 solutions).

[QUOTE=Dr Sardonicus;508337]I see that you can earn an asterisk if you solve the problem in hexadecimal. As of the most recent update, nobody had done so.[/QUOTE]
The solver list hasn't been updated even once after the asterisk task was added, so there's no information about how many people have done so.

[QUOTE=uau;508375]The solver list hasn't been updated even once after the asterisk task was added, so there's no information about how many people have done so.[/QUOTE]

Considering the amount of time my dumb bruteforce script took, I'm guessing everybody who has attempted has done so by now.