[QUOTE=ramshanker;429261]Are there no 14 & 18 digit answer to this? My program didn't turn-up anything. I am having doubt whether I am doing it right or not.

Though it did reproduce the 10 & 12 digit ones posted above. My code is for even digits only.[/QUOTE]

There is an 18 digit solution.

[QUOTE=henryzz;429419]There is an 18 digit solution.[/QUOTE]

Ok, I figured out the bug in my python code. Can someone explain this to me.

After a certain number of digits, python results give incorrect division values.

[COLOR="Red"]>>> int( 194216878433174216 / 10 ) % 10
0[/COLOR]
[COLOR="SeaGreen"]>>> int( 19421687843317421 / 10 ) % 10
2
>>> int( 1942168784331742 / 10 ) % 10
4
>>> int( 19421687843317 / 10 ) % 10
1
>>> int( 1942168784331 / 10 ) % 10
3
>>> int( 194216878433 / 10 ) % 10
3[/COLOR]


First result is wrong. Trying on my 64 bit Python 3.5.0 shell. Is it a bug in python interpreter or it's supposed to be this way only?
It gives correct for high digit multiplication.

>>> 194216878433174216 * 194216878433174216
37720195868326371910875197407214656

So obviously it can handle >64 bit numbers, but some problem at the boundary?

Anyway I figured out a way for odd number and found both 15 digit ones. Now running for those 18 digit ones. :)

[QUOTE=ramshanker;429503]Ok, I figured out the bug in my python code. Can someone explain this to me.

After a certain number of digits, python results give incorrect division values.

[COLOR="Red"]>>> int( 194216878433174216 / 10 ) % 10
0[/COLOR]
[COLOR="SeaGreen"]>>> int( 19421687843317421 / 10 ) % 10
2
>>> int( 1942168784331742 / 10 ) % 10
4
>>> int( 19421687843317 / 10 ) % 10
1
>>> int( 1942168784331 / 10 ) % 10
3
>>> int( 194216878433 / 10 ) % 10
3[/COLOR]


First result is wrong. Trying on my 64 bit Python 3.5.0 shell. Is it a bug in python interpreter or it's supposed to be this way only?
It gives correct for high digit multiplication.

>>> 194216878433174216 * 194216878433174216
37720195868326371910875197407214656

So obviously it can handle >64 bit numbers, but some problem at the boundary?

Anyway I figured out a way for odd number and found both 15 digit ones. Now running for those 18 digit ones. :)[/QUOTE]

The [c]/[/c] operator always gives a floating point result (in Python 3+). The result highlighted is the first number on your list large enough that the last digit of the result is lost due to rounding error. Use the [c]//[/c] operator instead (and drop the [c]int()[/c] conversion).

[code]In [1]: 194216878433174216/10
Out[1]: 1.942168784331742e+16

In [2]: 19421687843317421/10
Out[2]: 1942168784331742.0

In [3]: 194216878433174216//10
Out[3]: 19421687843317421[/code]

Ok, found the 18 digit one. :banana:

Run-time 5967.29 sec.

Time to go for the big gun... any hint how many minimum digits for "**"? :grin:

If my program did not miss any solutions, then there are 2 solutions with 21 digits. There seem to be no solutions with 19 or 20 or 22 digits.

[QUOTE=ramshanker;429534]Ok, found the 18 digit one. :banana:

Run-time 5967.29 sec.

Time to go for the big gun... any hint how many minimum digits for "**"? :grin:[/QUOTE]

That is much faster than mine. Mine took a couple days.

[QUOTE=Anonuser;429536] there are 2 solutions with 21 digits. .[/QUOTE]

1 Found.... yeaaaaaaaaaa :showoff: . Let's see how much higher I can go.

The official solution (what is essentially my solution :smile:) is out at: [url]https://www.research.ibm.com/haifa/ponderthis/solutions/March2016.html[/url]
I've updated the corresponding oeis sequence.

[QUOTE=axn;427940]Using brute force exhaustive search (O(10^8)), I was able to find two solutions for n=15.
[/QUOTE]
[QUOTE=ramshanker;429534]Ok, found the 18 digit one. :banana:
Run-time 5967.29 sec.[/QUOTE] etc. (other posts)

My timings in the low range: for
n value, timing in thread time on my ancient core-i3
n=15: <1 second
n=18: 2 seconds [to get *]
n=21: 61 seconds (close to the famous 1 minute rule) [to get **]
n<=30: 152 hours

[QUOTE=R. Gerbicz;430729]The official solution (what is essentially my solution :smile:) is out at: [url]https://www.research.ibm.com/haifa/ponderthis/solutions/March2016.html[/url]
[/QUOTE]

So we can send a write-up also about the solution? This is my first time participating in Ponder-This contest. I just mailed them the number from my O(10^(d/2)) implementation output.

I wrote mine in python, an interpreted language, so I guess (wild guess) I could achieve at least 5 times improvement in run time with C code. However lost my interest after that lucky (early in the search sequence) 21 digit solution. My Python code managed ~140k candidate numbers per second.

[QUOTE=ramshanker;430732]So we can send a write-up also about the solution?[/QUOTE]

Yes, of course. Here I'm regularly posting solutions of the month puzzle (if I've solved).

[QUOTE=ramshanker;430732]I wrote mine in python, an interpreted language, so I guess (wild guess) I could achieve at least 5 times improvement in run time with C code. However lost my interest after that lucky (early in the search sequence) 21 digit solution. My Python code managed ~140k candidate numbers per second.[/QUOTE]

In general Python is not that slow. And it is a little technique to avoid the somewhat costly squaring in most of the cases (my solution was in c).

The next term is a(28)=42438303108538316396992097393368 found by Dieter Beckerle using my posted algorithm, but his own code. And there is no more term up to 10^32. The oeis sequence is updated, now it is in draft. ([url]https://oeis.org/A269588[/url]).

ps. Note that here still k=3, so there is a speedup of 1000 over the classical approach.