As people are asking for tips to solve this puzzle, I could provide pointers to kick-start but not too much to reveal the answer.

Tips

Change subject of the equation. Make x to become the subject.
In algebra we represent it as x = f(n, y). But this representation is useless to you until you finish change subject.

Do you find that the value of y is always within a specific range, from [start] to [end]?
Define [start] and [end] for y.

Write a for-loop, for y = [start] to [end], test whether x is an integer under the given n and y

Within the for-loop, if âx is integerâ is TRUE, calculate value of x, then output one line of answer.

Note: Using the test case examples, you may have to test through 100,000 different values of y.
Your testing method has to be efficient to run at least 100k times in a flash.

How can it be so fast like that?
The test result is either TRUE or FALSE only. You do not need to know the true value of x in the test.
Calculate the exact value of x only after confirming x is an integer.

The above is just one possible approach. It does not rule out other algorithms that may run even faster.

I try to solve this in Haskell (which I donât speakâŚ but hey thatâs the challenge )
I use a recursive function instead of loop, something like this:

loop :: Int -> Int -> IO ()
loop y n
| _is-end-of-loop-expression_ = ()
| _is-valid-solution-expression_ = do
let x = _expression_
putStrLn $ "1/" ++ n ++ "= 1/" ++ x ++ "+ 1/" ++ y;
(loop (y + 1) n)
| otherwise = loop (y + 1) n

I get an error message âcouldnât match expected type IO () with actual type ()â .
It seems to me that the problem that I generate output with putStrLn only in the second match, but not in the first.
I couldnât fix my code with âtry and errorâ nor found relevant Haskell article.
Haskell coders, please help! Thanks.

Thanks for the help, this solved the issue!
PS: the code excerpt I posted also missed some âshowâ functions in the putStrLn and the ; was error but these were easier to find out.

This was a really good puzzle. Seemingly harder at first glance but with a suprisingly easy solution once you start to analyze the hand calculated output. There are several ways that you could go down a rabbit hole on this one.

Hi everybody,
Did anybody solve this using C language ?
I canât do it because of the variable storing limitations.
âintegersâ in C cannot store a value exceeding a limit.
This means that I always failed the two last tests because the numbers are too big.
So, if anybody found a solution to this, Iâd love if he can share it with my in PM.

PS: I passed all the tests with the same algorithm using Python.
Have a good week-end.

C is more flexible than many other languages in terms of data type choices.

Besides the usual âintâ, have you ever heard of âlong intâ, âunsigned long intâ, âlong long intâ or even âunsigned long long intâ ?

If not, this puzzle is a chance for you to try them out.

Thanks for your quick answer. Unfortunately, I tried them all.
I used an unsigned long long int (which is supposed to be 64 bit) and the two last cases donât work.

Then, I checked the version of the C compiler Codingame uses. And, to my surprise, they use one of the latest (most recent) compilers!!!
This means I could use uint64_t types as integers.
They donât work either.

For instance for the before last case if you do:
unsigned long long int result = 71339 * 71340
Then fprintf(stderr, âresult = %llu\nâ, result)
The displayed result is absolutely false (1632927230790790372) .
On my calculator, the result is: 5089324260

I really need someone who actually tried using C and succeeded.
Unfortunately, I cannot see any C solutions because I didnât get 100% using C language but Python instead.

It works. of course because of the âLâ suffix on the numbers.
On the other side, I was able to solve this using C language at last.
I made a mistake with the scanf at the beginning of the auto-generated program.
The default one is using â%dâ which is for simple int.
If I choose unsigned long long int, then, that could not work.
Thanks again for your help!
Itâs very appreciated.

Seen your note so that I reviewed the statement and the stub. They are still correct because all input numbers are within the range of normal âintâ. In the middle of calculation it is programmersâ responsibility to promote the input data type into other suitable data types as needed. You already know that writing in python there is no need for this promotion. The puzzle auto-gen stub is responsible for getting correct inputs but should not too much pre-define how to use the inputs.
Congrets you finally succeeded in solving it in C.

You are definetely right. I shouldnât have changed the way the autogen program handles the input.
I changed back and made it worked again. That was a better coddE.
Thanks again for your help!
Have a safe end of week-end.

I think i have the right formula for finding y. but the rounding of the numbers is too precise for me. y isnât an integer itâs 15.99999999999999 (for instance). when i use round(y, 10) itâs either too precise or too crude it seems.

Your formula may be perfect but float-point calculation by computer is notorious to be inaccurate. It gives surprise more often than you expect. This puzzle can be solved by using no float-point variables in the whole processing.

Hello !
My code seems to be ok and passes all tests, but after submission, the second âvalidatorâ always gives an error message ??!!!?! I canât find why !! Can anyone give me some help to understand the difference between tests and validators ? Thanks.

Calling this problem âEasyâ is outrageous
The description is totally incomplete
At least put a link to the math beneath it
Read the other âEasyâ problems and tell me if you find it correctly marked as it, @java_coffee_cup

The math is a little challenging; maybe more than most people could handle with just high school algebra. I think JCC intended that to be part of the fun. Outside of not giving away the math, the description is clear and complete and the actual coding is easy. There are multiple good solutions that take just a few lines and use only primitive types. The biggest frustration I ran into was getting Java to stop casting my long values to int.

Hint: It helps to think about the 1/n = 1/x + 1/y : {x >= y} equation in terms of limits.

@ ToshiTuringMachine You did very well to relay this puzzle to a classic school of maths study. You need these references when you are writing an academic paper in research.

While this problem belongs to the spectrum of Diophantine equations, one does not need to know or apply any Diophantu maths theory or equation or any advanced maths to solve it.

Diophantus started his study 2000 years ago.

In terms of solving this problem, it is probably still a piece of cake for an average coder today equiped with modern technologies but without the Diophentus maths knowledge. On the contrary, Diophantus and his followers who know their school of study well but without knowing computer or programming will find it hard to manually doing all calculations.

Easy or hard depends on what year you are living in and what tools you are using.