On Sun, Jan 16, 2022 at 12:34 PM 'Michael Day' via Programming <programm...@jsoftware.com> wrote: > OK - your approach is far more efficient than mine! I suspect you did > what I had in mind, but couldn't quite get that mind to produce.
I should perhaps add.. My first (reverse) pass through the possibilities did not concern itself with which digits would have been involved. All I was concerned about on that first pass was what values would allow the final result of Z=0 to be achieved. Initially, I expected a combinatorial explosion, but when I tested it to see how far I could get before that happened... well... here's what I saw for the possibilities: #@>hist 1 9 82 738 6643 738 82 738 6643 738 82 738 82 9 1 The first and last values were also both zero, which made sense. This was not enough by itself to adequately constrain the search space: */#@>hist 3.53794e31 But it allowed me to run each stage independently, with those values, which constrained the possible digits at each stage. At this point, my digit counts looked like this: #@>digits 5 7 4 8 9 9 2 6 9 9 7 9 9 9 Also, this meant that I could throw all possibilities for the last eight digits at J and expect to have less than 1e7 values for the final Z result. So I set it up to cycle through the first six digits (starting at the max representable value and counting down), and only needed 15 iterations of this approach to find my result. That said... I do not know if this merely means that I was lucky that my answer was reached easily. (For example, the first four digits were all the maximum plausible digits for part A, and the first 8 digits were all minimum plausible digits for part B.) Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
