Hi, all --
Here is an interesting arithmetical problem that appeared in a student-engineer magazine in 1993 or 1994:
Assume that each integer from 1 through 9 is used exactly once to form three quotients of single-digit integer numerators and two-digit integer denominators. How many ways could the digits be arranged such that the sum of these three terms equaled unity?
Example:
7 8 9 181
---- + ---- + ---- = --- ~= 1.005
12 36 45 180
is almost a solution.
I obtained the above result by trial-and-error, but was unable to analytically deduce the correct answer. In 1995, I wrote a recursive C-language program that found the solution by "brute force", evaluating all 9! = 362,880 possible combinations of digits. Of course, there are six ways to arrange the three terms, so there are "only" 60,480 unique combinations.
Several years ago, I showed this problem to a colleague who offered the following:
"There is a subset that populates a more general relationship,A C E
--- + --- + --- = 1
B D Fwhere A is odd and 2*D = F.
Example: 1/2 + 1/3 + 1/6 = 1."
He obtained the correct solution by trial and error within this subset of combinations. I can't offer a proof that the stated equation is generally true, or why it may have been a necessary (not merely sufficient) condition for the solution.
So, the challenge: Can anyone provide a direct analytical solution to this problem? If not, would anyone dare to attempt to write an efficient HP calculator program to solve the problem?
I believe that the HP-15C offers sufficient programming features to tackle the problem using the brute-force method:
- Enough storage registers to maintain nine separate digits and to store solutions
- Nine usable flags (flags 0-9 excluding flag 8) to track whether a digit is "in use"
- Subroutines, conditional tests, and plenty of labels
- A versatile indirect register
So, a workable HP-15C program could be written. However, I also believe that such a program might take literally weeks to run to completion on an actual HP-15C! Recursion and integer arithmetic could not be employed, as my C program does.
The HP-71B would be more suitable, with 12 times the speed, BASIC language, and recursion.
Of course, with computing speed being an important issue, a PC-based simulator would be a better choice than an actual calculator.
I doubt that there is any trivially-simple derivation of the solution; I also believe that an efficient program would require time and effort. Still, the mathematical knowledge and programming skills offered in response to Valentin's challenges never ceases to impress me. I'll post my C-language program shortly, as a guide for those who might find it useful.
Best regards,
-- KS