In a first way I computed the integral giving two 2F1 hypergeometric function terms in
the unit circle hypergeom([1/2, n+1],[2+n],r) which I reduced with some handwaving for
the series to hypergeom([1/2, large],[large],r), which is 1/sqrt(r), giving the 26/3. (*)

But was warned by an article of Temme "Large parameter cases of the Gauss hypergeometric
function" (2002), http://arxiv.org/abs/math/0205065v1 about sloppy reasoning.

Hence looked into filed lectures about asymptotics. And after verifying the above is
correct. But one apply that directly, without computing the integral:

  Int((1-(3/26)*x-(37/49)*x^2)^n, x = 0 .. 1) = Int(f(t)*exp(n*phi(t)),t = 0 .. 1)


Now from asymptotic expansions for such an integral over an interval t = a ... b it is
know, that it can be approximated as follows (Laplace case):

  eval(%, f=1);
  eval(%, phi = 't -> ln(1-3/26*t-37/49*t^2)');
  simplify(%, exp) assuming 0
  1/n*f(b)/D(phi)(b)*exp(n*phi(b)):
  subs(b=a, %):
  J(n) = %% - %;

                   f(b) exp(n phi(b))   f(a) exp(n phi(a))
            J(n) = ------------------ - ------------------
                      n D(phi)(b)          n D(phi)(a)

And one continues by using that

  eval(%, f = 1):
  eval(%, phi = 't -> ln(1-3/26*t-37/49*t^2)');
  subs(a=0, b=1, %);
  simplify(%, exp);
  
  %*n;
  limit(%, n=infinity);


            limit(n*J(n),n = infinity) = 26/3

(*) Correction: 1/sqrt(1-r), use 'simplify' for that.

@Markiyan Hirnyk 

One can look at the problem in the following way:

Say we have a polynomial in x of degree 85 and coefficients of magnitude ~ 1.

Take x=10 and let us work with Digits = 10.

Then evaluation in x is of magnitude 10^n for each monomial term of degree n.

But since Digits=10 means, that only the 10 leading decimal places contribute
to the overall value which is ~ 10^85. Hence all terms through deg < 75 do no
longer contribute, numerically they would be ignored.

@Markiyan Hirnyk 

One can look at the problem in the following way:

Say we have a polynomial in x of degree 85 and coefficients of magnitude ~ 1.

Take x=10 and let us work with Digits = 10.

Then evaluation in x is of magnitude 10^n for each monomial term of degree n.

But since Digits=10 means, that only the 10 leading decimal places contribute
to the overall value which is ~ 10^85. Hence all terms through deg < 75 do no
longer contribute, numerically they would be ignored.

@Markiyan Hirnyk 

What I want to say: having high degree and low working precision is not a good idea,
because I guess the poster worked with Digits=10 and resulting in his coefficients.

For example he mentions 'Matlab', and that is likely to work in double precision
(that confirms my guessing). But as shown in my sheet that checking the zeroes
results in very large values (because of a high degree too high).

Simple example: your 'largest' root is ~ -63420.8 -15882.0*I. Now taking the 85th
power will be ~ 1e410 + 1e409*I which will overflow in usual double precision.

Your verfication used enough Digits concerning the degree, yes.

@Markiyan Hirnyk 

What I want to say: having high degree and low working precision is not a good idea,
because I guess the poster worked with Digits=10 and resulting in his coefficients.

For example he mentions 'Matlab', and that is likely to work in double precision
(that confirms my guessing). But as shown in my sheet that checking the zeroes
results in very large values (because of a high degree too high).

Simple example: your 'largest' root is ~ -63420.8 -15882.0*I. Now taking the 85th
power will be ~ 1e410 + 1e409*I which will overflow in usual double precision.

Your verfication used enough Digits concerning the degree, yes.

Why do you need the determinant? You said you want to solve a linear equation.

Why do you need the determinant? You said you want to solve a linear equation.

Seems it does not simplify automatically, so continue by

  simpform(%);

                            wdegree(e3)
                   (1 + (-1)           ) (e1 &^ e3)

And you see, that it depends on the degree of e3.

PS: I am not sure, whether they always mean "pure degree".

Edited: 
the terminus in Algebra is "anti-commutativ" or "alternating"
(in this case), not "anti-symmetric"

Seems it does not simplify automatically, so continue by

  simpform(%);

                            wdegree(e3)
                   (1 + (-1)           ) (e1 &^ e3)

And you see, that it depends on the degree of e3.

PS: I am not sure, whether they always mean "pure degree".

Edited: 
the terminus in Algebra is "anti-commutativ" or "alternating"
(in this case), not "anti-symmetric"

How about "No, a polynomial takes any values in the complex plane" ?

For Reals it may be infimum .. supremum, open or closed, but that may
depend on *defined* domain and function

For example where do you think the square root is defined. And a function. ?

I guess one can guess what you want. But: what do you actually need and what for?

How about "No, a polynomial takes any values in the complex plane" ?

For Reals it may be infimum .. supremum, open or closed, but that may
depend on *defined* domain and function

For example where do you think the square root is defined. And a function. ?

I guess one can guess what you want. But: what do you actually need and what for?

Hi acer,

I used IEEE doubles for inputs only and rounded the 'true' decimal and the rational
approximation both to their nearest IEEE doubles, which are Rationals.

Then I compared those rational numbers, without using decimal float approximations.

I enclose my modified sheet, which shows it, avoiding the mentioned library.

But of course the errors may be larger than I see them in my test cases.

tan_approx_compiled_.mws

Edited: absolute error 1 DBL_EPSILON and 2 ULPs (binary) - so not as good as
I hoped above, but not that bad

PS: Thx for the interesting remark on 'option inline' !

Hi acer,

I used IEEE doubles for inputs only and rounded the 'true' decimal and the rational
approximation both to their nearest IEEE doubles, which are Rationals.

Then I compared those rational numbers, without using decimal float approximations.

I enclose my modified sheet, which shows it, avoiding the mentioned library.

But of course the errors may be larger than I see them in my test cases.

tan_approx_compiled_.mws

Edited: absolute error 1 DBL_EPSILON and 2 ULPs (binary) - so not as good as
I hoped above, but not that bad

PS: Thx for the interesting remark on 'option inline' !

He already asked at the usenet, tan(x) ~ x + x^3 P(x^2)/Q(x^2) was
a suggestion and one user pointed to

http://www.research.scea.com/research/pdfs/RGREENfastermath_GDC02.pdf

He already asked at the usenet, tan(x) ~ x + x^3 P(x^2)/Q(x^2) was
a suggestion and one user pointed to

http://www.research.scea.com/research/pdfs/RGREENfastermath_GDC02.pdf