question unclear, pls post your code or your sheet - use the "green arrow" in the editor.

Have you check whether you are running a supported platform?

http://www.maplesoft.com/products/system_requirements.aspx

You need to provide the rule for "old to new", what has to be done

The syntax is subs( currentExpression = newExpression, termToWorkOn), algsubs is similar.

Likewise you can try eval(termToWorkOn, currentExpression = newExpression)


And it is simply not clear, what you want to do.


Note that D_0 etc does not make sense, except you mean constants and that your expressions
do not depend on your variable t.

ODE[2]; 
%*4*x^2/u[0];
#factor(%);
collect(%,D);
convert(%, Diff);

What is ftn?

Try maplemint(prcNewton) and look up  that command.

What kind of lecture you are following? By whom? Why not
using a clear proc, where all inputs are directly defined and
thus are documented?

You have 2 inputs, your code uses the case of 4.

One can go that route. But should have understood basics
(and personally: one should stay to that instead of some
non-documented overloading).

I would guess it is 26/3, using some brute methods.

But would need some time for a sketch (PC is broken).

I have never cared much for complex roots of polynomials. But made some search
(since RootFinding:-Analytic does not provide any references (shame!!) and it
is not for the polynomial case, but more generally).

The best was Hubbard, Schleicher, Sutherland How to Find All Roots of Complex
Polynomials by Newton's Method, Inventiones (2001), free for download from 
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.23.3794

with some newer "A small probabilistic universal set of starting points for
finding roots of complex polynomials by Newton's method" either at AMS 2012
for money or at http://arxiv.org/abs/1009.1843 for free as preprint.

That may be an entry point to searching for literature on concurrent methods.


Usually articles in Inventiones can not be simply read. But through the Intro
one can jump to § 9 and I have the *feeling* one can work backwards from there
for a recipe (no, I am missing time + patients for that).


However I still have some problems: they use the assumptions "roots in the unit
disk" and suggest to scale to that. That can be done: If Sum(b[^j]*z^j) = 0
then Sum(a[j]*x^j) = 0 for a[j] = b[j]*r^j, x = z*r, r = original radius for
some given equation Sum(a[j]*x^j).

But in the given case r^j will overflow. So I do not see how Matlab can do it
in the assumed mode = double precision.

It is a mess that the poster does not provide any concerte information beyond
the poor assertion "xxx can do it": no results, no settings. Nothing.


One may note that the article asserts that the Newton method would allow to
proceed with higher precision to get some more accurate result (due to the way
the go, but that's beyond my knowledge): refine to ones needs.

And one may note that the estimate for the radius due to Knuth/Henrici (see my
upload) may not be good - but it voids numerical cancellations problems.

Also the authors reject a divison by known zeros (I think, that is meant by
the terminus 'deflate', it is a bit hazardous, yes).

I have some doubts, that using 10 Digits and asking for solutions of a polynomial
function in degree = 85 makes deeper sense (check the solutions, but implicitely
that was already said) beyond an estimate.

The given code needs about 5 - 6 minutes for Digits = 10 or that magnitude.

Roughly I do the following: use Sturm chain to find real roots (as alread shown
there are 9 of them).

Dividing them out (ignoring the numerical reminder) gives degree = 76. And that
polynomial has only purely complex roots. Those are conjugated, hence a search
can restrict to one half plane. And should deliver 76/2 = 38 solutions.

The search domain can be estimated by a criterion of Cauchy, for which a formula
of Knuth can be used.

That results in a runtime of 1.5 minutes.

Of course that may not be a general recipe, but for high degrees it may help.


Find a sheet attached.

MP_fsolve_highdegre.mws

As you opened a new thread I 'answer' here.

Since you want numerical results one may set Digits:=15

Then you may not use Pi/4 or whatever, but numerical values

Further I would avoid to simplify in case of numerical values
(often they result in the contrary).

Instead of MatrixMatrixMultiply(A,B) I would write A.B and
also would use Vector[1] instead of Vector(1) for entries.

Vectornorm may need conjugate true/false.

But this all is minor: I guess you use too much symbolics.

Approximating a rational function is perhaps a risky way.

To solve a matrix equation like A*x = b you better may use LinearSolve.

Determinants generally are the wrong way, they ARE to 'complex'.

There are certainly better methods than the following to compute some
determinants (guess Maple has better ones), but roughly one can say,
that det = sum of n! elements, where those elements are products.

For n=40 you have 10^48 summand, but for n=60 you have 10^82.

http://en.wikipedia.org/wiki/Determinant#Further_methods gives a
better insight, but it is certainly highly non-linear in dimension.

I almost never used it (it is quite inconvenient, but you may try with(difforms)
and then &^( (e1 -e2+ e3), (e2-e4)), for which you have to supply degrees
by defform(e1=p, ...)

May be DifferentialGeometry[ExteriorDerivative] is your friend ... starting by
with(DifferentialGeometry), looking up DifferentialGeometry[algebraic operations]
Which does not really invite me to use it (I miss a simple 'overloading' for the
operators). But I am simply not used to that package, I guess.

map(ln, Kpco2F): 
Statistics:-Fit(La-b/t, T, %, t);

                                     33908.7491104913
                 -10.3301955847975 + ----------------
                                            t

Roughly 'evalf' does not guarantee n Digits, it uses n Digits (or more)
for the computation.

For example you may try an approximation for Pi by a fraction m/n
and then apply evalf to the difference.

So it does not estimate itself, how many 'decimal' places would be
needed for a correctly rounded result.

At least in newer versions the system should remember the result of
(A), re-using it for (B)

It is not clear what 'f' should be:

f(t);
                            a(t) + D(x)(t)

Why do you expect a (seemless) backward functionality?

Actually you load a script for a software (old version), which you do not have.
Especially the syntax and libraries changed.


The concurrent software probably would not run on old machines and conversely.

Especially if you have an operating system not being supported by the old Maple
or a newer Maple not supporting the old OS' suggested once.

This is quite common, you may look up 'migration projects': machine, OS and the
application SW changed, you feed a 'program' for old versions of all of them.

One way is 'virtualization', deferring problems.

And the application center certainly holds code, which would not pass Maple's
quality assurance.