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

Florian Dufey

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

I specified 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.

Helmut Kahovec (28.3.01)

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().

Florian Dufey (28.3.01)

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 differ first for the [10,10] approximant: confrac: 4.9330598771621... ratpoly: 4.9330573010774... the [9,9] approximants coincide to 26 digits.

file perout:


maple program:


Helmut Kahovec (2.4.01)

You certainly mean

ratpoly: \(4.9330730107748\)...

don’t you? Reading in your file 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 fixed, `convert/confrac` gives much more precise results than `convert/ratpoly` if the coefficients in the polynomial to be approximated vary as much as in your case.