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