Have continued to play around with expressions involving decimal points, which have provided much greater complexity and some new instances of algebraic equivalence. For example, these two expressions

Code:

ab/(c/d)
a.b/(.c/d)

are obviously equivalent. In this case, the introduction of decimal points added no new solutions, nor does it affect the ordering of the digits or any other significant variableness. So, in compiling both a minimum list of expressions, and a more inclusive 'concise' list, my list compilation logic would prefer the former, simpler expression, and discard the second.

In considering these two less obviously equivalent expressions

Code:

(a+b)*.c+d
a+(.b+.c)*d

it's more of a toss-up, perhaps the former selected as being somewhat briefer, or perhaps both retained in the 'concise' list for purposes of variableness in the ordering of digits.

But there are other more interesting cases. For example, the whole-number expression

is practically useless for the 2019 Challenge. It cannot yield a positive integer, and the only way it can yield a negative integer is if 'a' were '1', or either a or b were zero, in which case b's leading negative sign turns out to be meaningless. But by introducing a single decimal point

it becomes a quite useful expression. Replacing '.a' with '.1', '.2' or '.5' ('.0' is disallowed) and 'b' with a non-zero digit, this expression can provide a nice variety of positive integer values, quite possibly some of them new solutions. (As a matter of fact, this very expression is needed in the exhaustive run for at least 23 of the 53534 solutions.)

The above and other complexities, and the scope of new possibilities explain how decimal points ended up making my program run 20 times slower. By way of review, my original program generated equations on the fly in the form of Reverse Polish Notation strings. When a dynamically generated RPN string yielded an acceptable value, it was converted to an algrebraic expression and then stored/displayed.

So now my latest program follows astrogeek's lead in using pre-generated expressions, and goes one step further in also using corresponding pre-generated RPN strings to valuate efficiently and speedily. No dynamic expression generation necessary, no on-the-fly conversions necessary between RPN and algebraic expressions, and a minimum of validation logic. Fast.

This was possible, of course, only after producing adequate lists of expressions. My latest 'concise' list using decimal points contains 1426 expressions, down from 1941, since i've tried to reduce most unneeded leading negative signs and unneeded decimal points where possible. Have also produced a new minimum expression list. Previously underestimated how the increased scope of decimal point equations would affect the minimum number of expressions needed. Using the exact same techniques used to derive 193 expressions for the original Challenge, i could derive no fewer than 485 expressions to yield the full 54534 solutions. (Am not sure, but 54534 solutions and 485 minimum expessions may both be improvable numbers.)

The 'concise' list of 1426 expressions is by no means definitive. My previous list of 1941 was a sort of 'garden run' selection, starting with a long list, then programmatically culling where two or more expressions yielded exactly the same solutions. My goal was a relatively brief list to achieve all 53534 solutions, and in which a non-exhaustive but nice variety of equations might be selected according to user preference. My current list consists of a few more refinements, selecting against unnecessary, superflous, or ugly complexity where possible, and also 'cherry-picking' a few favorite expressions for specifically desirable equations for 2019 and a few other select years. For example, i hand-picked

just so that it would give the prettily ordered equation

for the home year 2019, even though it was not strictly needed.

Ended up putting all lists together in one .h include file. Two arrays of strings, one for algebraic expressions, the other for corresponding RPN strings. Both arrays start with 485 minimum expressions followed by 941 more. The exhaustive run processes only the first 485 (for speed), single year runs process all 1426 (for variety); a simple matter of two different limits in the 'for' loop. Limited to 485 expressions, the exhaustive run on the fast server now processes all 715 4-digit numbers w/ 10000 permutations, generating 54534 solutions in less than 2 seconds. The .h file containing the lists is attached:

exp.dot.lists.h.txt
This include file, along with the C program code and current fractional-exponential math routines, are also available as before at

http://cyberjerry.info/calc/fx/LQpuzzle.php.

What remains someday is to document my methodology for generating the lists, both for LQ and for my own future reference. Right now i will just say that my list-generating methodology was, i think, quite similar to Beryllos', albeit spastic and haphazard, with many dead-ends and detours, much less methodological than his approach.