#### bug in convert[ratpoly], Maple 6 and Maple 7 (26.3.01)

I wanted to calculate the pade approximant to a Taylor series for given value of x.

I speciﬁed Digits:=31.

I used for this convert(series, ratpoly,i,i) (or convert(series, ratpoly,i-1,i) ) ,
pade(series,x,[i,i]) and convert(series,confrac,`subdiagonal`) where series is a series of
order 2i+1 (2i). Finally, I substituted \(x=1\).

Independently, I calculated the corresponding approximants using Wynn’s epsilon algorithm.

For \(i <10\) all three methods lead to nearly the same results (up to some 25 digits).

For \(i>10\) , convert(ratpoly) and pade suddenly returned results which where only correct to 4
digits.

I did these calculations under MapleV rel. 2 and under Maple6.

Under Maple 6 however, the convert(confrac) gave an error message "division by zero series" in
the case that the series were of order 2*i.

The help page doesn’t mention the algorithm used in the convert(confrac) routine.

After I had looked at the source code of `convert/confrac` I tried the undocumented third parameter
`superdiagonal` -- and it worked. Here is what I have got in Maple6:

All four approximations a1,a2,a3,a4 were the same if the order parameters were equal to those used in
f().

As the error with the convert[ratpoly] routine doesn’t seem to appear for every input, I
will give my input. The results of the convert[confrac] routine seem to converge to the
correct result (4.931704...) which I also know from calculations which don’t use a series
expansion.

The two methods diﬀer ﬁrst for the [10,10] approximant: confrac: 4.9330598771621... ratpoly: 4.9330573010774...
the [9,9] approximants coincide to 26 digits.

ﬁle perout:

maple program:

You certainly mean

ratpoly: \(4.9330730107748\)...

don’t you? Reading in your ﬁle perout. I can exactly reproduce your results as follows (note that I am
using `superdiagonal` again):

In order to get a comparable result with `convert/ratpoly` you have to use many more digits than 31.
If you use 1000 digits then you get, for example:

Thus, keeping the number of digits ﬁxed, `convert/confrac` gives much more precise results than
`convert/ratpoly` if the coeﬃcients in the polynomial to be approximated vary as much as in your
case.