Magic 3 - A Proposed New Problem
Back to General discussions forum
This is a different way of looking at number base problems.
Hi, many thanks for this. I get the correct results for the first 15 numbers but then have very small differences for the 3 largest. Deltas are both positive and negative. Hopefully somebody else will solve soon.
Mathias,
Thanks for this. I realised this morning that there was one thing that I had forgotten to check for. I looked at my code this morning and discovered the error. Then I found your post which confirms the problem. I am busy at the moment but will fix it later today and send an update to Rodion.
I am in the same boat as Mathias. No rush, of course.
Hi Friends, the code is updated with the one Clive speedily provided - I'm just sorry for slow reaction on my part (the same with some other points I see now mentioned here at forum - regretfully got a bit confused state around my school classes these few weeks and need to invent some instruments for kids from scratch). Very curious by the way whether issue description given by Mathias may give me a clue for this puzzle. I started to think on it lively enough and was proud about few ingenious conclusions I made, but Clive's generator uses such impressively large numbers! Very nice puzzle for slowpoke folks like me :)
Hi, I do not think my description gives anything away - all it says is that I got some answers right and some wrong.
Interestingly, two solutions got accepted before the correction, and they disagree with my solution.
For example for n=21519553475642535,
I get the answer 1793296134335536 but others produce one less 1793296134335535.
I've just resubmitted my code with additional assert statements.
I suspect the issue might be that using float numbers as part of the calculation is not precise enough.
For example, (my) Python evaluates 21519553475642535/4 as 5379888368910634.0 which is not quite right.
Mathias,
I agree with the answer of 1793296134335536 which you give above. I wasn't aware that anyone had had a solution accepted before the correction had been put in place. I just assumed, having spotted the error, that no-one would get an accepted solution. It is just possible that both solutions had the same minor error that mine had, but that seems fairly unlikely.
Having just said that, I have just re-constituted my previous solution and it does give an answer which is one less than this.
My guess is that all three solutions are impacted by a similar float precision issue. Best to stay entirely in the integer space.