@acer I don't think that this has anything to do with LinearAlgebra[Generic]. The theorem is using ordinary arithmetic of matrices of bivariate polynomials to generate a single bivariate polynomial. To see such a polynomial, run the example from my Answer.

I'd guess that Domineering is an abstract board game.

@acer Thanks for the testing. A condition satisfied by many (most?) banded coefficient matrices used in practice for the numerical solution of PDEs is strict diagonal dominance (i.e., the magnitude of the diagonal entry in each row is greater than the sum of the magnitudes of the other entries in the row). I suspect that any examples of ill-conditioning (such as the appearance of Float(infinity) in the solution) that arose in your testing came from coefficient matrices without this property. I suspect that the LAPACK code makes some adjustments when this condition is not satisfied. My code does not. Of course, it's my fault for not checking that and not having mentioned it earlier. It was on my mind as I wrote that code that the division by the diagonal entries was potentially problematic.

@acer That's a great Answer with information of wide applicability. Vote up.

@tomleslie Nice. Vote up.

The weirdness surrounding 10 even applies when it's replaced by an abstract constant with assumptions. Compare:

limit((x-a)^n*x/x^(n+1), x= infinity) assuming n::posint, a>10;
limit((x-a)^n*x/x^(n+1), x= infinity) assuming n::posint, a<10;

@Kitonum You provide no clue as to how you constructed your function. Surely you did computations to get that.

@tomleslie While it's true that LinearAlgebra offers many solvers optimized to the structure of the coefficient matrix, it doesn't provide a dedicated tridiagonal solver; which is a shame, because that's a very important and commonly occurring case. 

The solver that I wrote (link given in the Answer below) outperforms by several times the best option provided by LinearAlgebra.

@acer No worries, I enjoy the opportunity to guess correctly. :-)

@acer Does WFH = "Work from home"?

@acer Thanks for the comparisons. The randomness is not session dependent. The key, which can be set with randomize(key), is always reset to 1 by a restart.

Very strange indeed. The cutoff at precisely 10 remains as you stated regardless of whether one uses decimals, exact fractions, or even exact transcendental constants! Try 11*sin(1), 12*sin(1), exp(2), exp(3), 3*Pi, 4*Pi.

I'm using Maple 2019.2.

Here is a much better algorithm for your task. It's better because rather than checking all numbers less than m for the presence of 2s in their base-3 representation, it generates only those numbers without 2s. It does this by converting numbers to base 2 and using their digits as the base-3 digits. 

rfin:= (m::nonnegint)->
    local M:= 1+floor(log[3](m+1)), E:= 3^~[$0..M], e, q; 
    remove(`>`, [seq(add(e*irem(b,2,'b'), e= E), b= 0..2^M)], m)
:     
rfin(50);
  [0, 1, 3, 4, 9, 10, 12, 13, 27, 28, 30, 31, 36, 37, 39, 40]

Again, to use this syntax, you must use the 1D input (aka Maple Input) mode (where, by default, the code appears dark red and monospaced, as above).

@acer The abbreviation of EmpiricalDistribution to Empirical that you've used seems to be undocumented. I don't have any problem with that; I just thought that it should be pointed out. I think that it's ridiculuous and unfortunate that so many names in Maple have redundant words tacked onto their ends. The GraphTheory package is one of the worse offenders.

Please don't repeat Questions from other threads. I read your other Question (the one I just deleted) in it's original thread yesterday, and I don't know the answer.

@emendes Change both instances of degree(p) to degree(p, var). The var at the end of the that line of code does nothing, and can be removed.