@Scot Gould 

1. The commands upperbound and lowerbound already exist. They are top-level, not part of any package.

2. `if` can be replaced with ifelse. However, the back quotes are a fundamental part of Maple syntax, and numerous other cases where they're used can't be so easily replaced.

@Scot Gould It should unquestionably be a set. It was just a typo on my part. There have not been any changes in this syntax. 

I fixed that in my code.

@RohanKarthik You can now "vote up" Answers by clicking on the thumb rather than the Best-Answer cup. Unlike Best Answer, any number of Answers can receive a Vote Up.

@Joe Riel You're right, and I had just removed that before I saw your Reply. It was a leftover from when I was debugging the procedure that slipped through the cracks. I don't use rtable_scanblock often enough to have memorized the more-obtuse details of its syntax. In particular, I had the arguments of the internal procedure in the wrong order.

@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.