pagan

5142 Reputation

23 Badges

16 years, 329 days

 

 

"A map that tried to pin down a sheep trail was just credible,

 but it was an optimistic map that tried to fix a the path made by the wind,

 or a path made across the grass by the shadow of flying birds."

                                                                 - _A Walk through H_, Peter Greenaway

 

MaplePrimes Activity


These are replies submitted by pagan

@Fritz I wrote to call fsolve(G, a..b) and not fsolve(G(x),x=a..b). The reason you'd still be seeing an attempt at symbolic solving is because of premature evaluation.

There are several ways to avoid that premature evaluation.

Take `a` and `b` as being of type `numeric`, below.

G:= X->S.LinearAlgebra:-LinearSolve(evalf(subs(x=X,R)),T)-L:

fsolve(G, a..b);

...or...

G:= X->S.LinearAlgebra:-LinearSolve(evalf(subs(x=X,R)),T)-L:

fsolve('G(x)', x=a..b);

...or...

G:= proc(X)
if type(X,numeric) then
S.LinearAlgebra:-LinearSolve(evalf(subs(x=X,R)),T)-L;
else
'procname'(args);
end if;
end proc:

fsolve(G(x), x=a..b);

All of those above should avoid the instance of G trying its solving for a nonnumeric input argument. You showed, on the other hand, a popular way to get the undesired symbolic computation, if you instead do

G:= X->S.LinearAlgebra:-LinearSolve(evalf(subs(x=X,R)),T)-L:

fsolve(G(x), x=a..b);

This is not particular to fsolve, and the same issues arise for `plot`, Optimization, etc. Commands which do not have special evaluation rules will evaluate their arguments before internally assigning them to the formal arguments of the procedure.

@Fritz I wrote to call fsolve(G, a..b) and not fsolve(G(x),x=a..b). The reason you'd still be seeing an attempt at symbolic solving is because of premature evaluation.

There are several ways to avoid that premature evaluation.

Take `a` and `b` as being of type `numeric`, below.

G:= X->S.LinearAlgebra:-LinearSolve(evalf(subs(x=X,R)),T)-L:

fsolve(G, a..b);

...or...

G:= X->S.LinearAlgebra:-LinearSolve(evalf(subs(x=X,R)),T)-L:

fsolve('G(x)', x=a..b);

...or...

G:= proc(X)
if type(X,numeric) then
S.LinearAlgebra:-LinearSolve(evalf(subs(x=X,R)),T)-L;
else
'procname'(args);
end if;
end proc:

fsolve(G(x), x=a..b);

All of those above should avoid the instance of G trying its solving for a nonnumeric input argument. You showed, on the other hand, a popular way to get the undesired symbolic computation, if you instead do

G:= X->S.LinearAlgebra:-LinearSolve(evalf(subs(x=X,R)),T)-L:

fsolve(G(x), x=a..b);

This is not particular to fsolve, and the same issues arise for `plot`, Optimization, etc. Commands which do not have special evaluation rules will evaluate their arguments before internally assigning them to the formal arguments of the procedure.

@serilas

You can fopen a file in APPEND mode.

restart:
randomize():

M:=LinearAlgebra:-RandomMatrix(2,generator=-100.0..100.0);

                   [ 54.9124213419298144  -70.7232480798100340]
              M := [                                          ]
                   [-69.0936342934238610   26.8200503616288160]

fopen("mm.txt",WRITE): # first time
fprintf("mm.txt", "%{c\t}.15f\n", M):
fclose("mm.txt"):

ImportMatrix("mm.txt");

                 [ 54.912421341929814  -70.723248079810034]
                 [                                        ]
                 [-69.093634293423861   26.820050361628816]

restart:
randomize():

M:=LinearAlgebra:-RandomMatrix(2,generator=-100.0..100.0);

                   [95.4874803506932892  -66.9723896140887404]
              M := [                                         ]
                   [71.1805382118355112  -20.0560011996916643]

fopen("mm.txt",APPEND): # next time
fprintf("mm.txt", "%{c\t}.15f\n", M):
fclose("mm.txt"):

ImportMatrix("mm.txt");

                 [ 54.912421341929814  -70.723248079810034]
                 [                                        ]
                 [-69.093634293423861   26.820050361628816]
                 [                                        ]
                 [ 95.487480350693289  -66.972389614088740]
                 [                                        ]
                 [ 71.180538211835511  -20.056001199691664]

@serilas

You can fopen a file in APPEND mode.

restart:
randomize():

M:=LinearAlgebra:-RandomMatrix(2,generator=-100.0..100.0);

                   [ 54.9124213419298144  -70.7232480798100340]
              M := [                                          ]
                   [-69.0936342934238610   26.8200503616288160]

fopen("mm.txt",WRITE): # first time
fprintf("mm.txt", "%{c\t}.15f\n", M):
fclose("mm.txt"):

ImportMatrix("mm.txt");

                 [ 54.912421341929814  -70.723248079810034]
                 [                                        ]
                 [-69.093634293423861   26.820050361628816]

restart:
randomize():

M:=LinearAlgebra:-RandomMatrix(2,generator=-100.0..100.0);

                   [95.4874803506932892  -66.9723896140887404]
              M := [                                         ]
                   [71.1805382118355112  -20.0560011996916643]

fopen("mm.txt",APPEND): # next time
fprintf("mm.txt", "%{c\t}.15f\n", M):
fclose("mm.txt"):

ImportMatrix("mm.txt");

                 [ 54.912421341929814  -70.723248079810034]
                 [                                        ]
                 [-69.093634293423861   26.820050361628816]
                 [                                        ]
                 [ 95.487480350693289  -66.972389614088740]
                 [                                        ]
                 [ 71.180538211835511  -20.056001199691664]

@Alejandro Jakubi Some things can be learned by inspection and experimentation as I know you, Alejandro, are quite aware.

Consider the output of

> showstat((IntegrationTools::Definite)::ParseIntegrationMethod);

for example.

> restart:

> infolevel[int]:=2:

> int(exp(-x)/(1-exp(-x)),x=0..infinity,method=[':-_RETURNVERBOSE']);

Definite Integration:   Integrating expression on x=0..infinity
IntegralTransform LookUp Integrator:   Integral might be a laplace transform with
 expr=1/(1-exp(-x)) and s=1. Cook LookUp Integrator: returning answer from cook pattern 1a Definite Integration: Method cook succeeded. Definite Integration: Method asymptotic succeeded. int/indef1: first-stage indefinite integration int/indef1: first-stage indefinite integration int/indef2: second-stage indefinite integration int/indef2: applying derivative-divides int/indef1: first-stage indefinite integration int/indef1: first-stage indefinite integration Definite Integration: Method ftoc succeeded. Definite Integration: Method ftocms succeeded. int/definite/contour: contour integration [ftocms = infinity, ftoc = infinity, cook = gamma, FAILS = (distribution, piecewise, series, o, polynomial, ln, lookup, ratpoly, elliptic, elliptictrig, meijergspecial, improper, meijerg, contour), asymptotic = infinity] > restart: > infolevel[int]:=2: > int(exp(-x)/(1-exp(-x)),x=0..infinity,method=[':-_VERIFYALL']); Definite Integration: Will return a result only if all integrators agree. Definite Integration: Integrating expression on x=0..infinity IntegralTransform LookUp Integrator: Integral might be a laplace transform with expr=1/(1-exp(-x)) and s=1. Cook LookUp Integrator: returning answer from cook pattern 1a Definite Integration: Method cook succeeded. Definite Integration: Method asymptotic succeeded. int/indef1: first-stage indefinite integration int/indef1: first-stage indefinite integration int/indef2: second-stage indefinite integration int/indef2: applying derivative-divides int/indef1: first-stage indefinite integration int/indef1: first-stage indefinite integration Definite Integration: Method ftoc succeeded. Definite Integration: Method ftocms succeeded. int/definite/contour: contour integration Definite Integration: The integrators computed possibly conflicting answers. Returning unevaluated. / exp(-x) \ int|-----------, x = 0 .. infinity, method = [_VERIFYALL]| \1 - exp(-x) / > int(exp(-x)/(1-exp(-x)),x=0..infinity,method=[':-_VERIFYFLOAT']); Definite Integration: Will attempt to verify the result numerically. Definite Integration: Integrating expression on x=0..infinity IntegralTransform LookUp Integrator: Integral might be a laplace transform with expr=1/(1-exp(-x)) and s=1. Cook LookUp Integrator: returning answer from cook pattern 1a Definite Integration: Method cook returned a result which could not be verified so other integrators will still be tried. gamma Definite Integration: Method asymptotic succeeded. Definite Integration: Finished sucessfully. infinity > int(exp(-x)/(1-exp(-x)),x=0..infinity,method=[':-_VERIFYTWO']); Definite Integration: Will return a result only if the first two integrators to return results agree. Definite Integration: Integrating expression on x=0..infinity IntegralTransform LookUp Integrator: Integral might be a laplace transform with expr=1/(1-exp(-x)) and s=1. Cook LookUp Integrator: returning answer from cook pattern 1a Definite Integration: Method cook succeeded. Definite Integration: Method asymptotic succeeded. Definite Integration: The integrators computed possibly conflicting answers. Returning unevaluated. / exp(-x) \ int|-----------, x = 0 .. infinity, method = [_VERIFYTWO]| \1 - exp(-x) /

I doubt that there is enough thread-safety to run these in parallel using Threads. But maybe using the Grid package `int` could make an end run around that.

@Alejandro Jakubi Some things can be learned by inspection and experimentation as I know you, Alejandro, are quite aware.

Consider the output of

> showstat((IntegrationTools::Definite)::ParseIntegrationMethod);

for example.

> restart:

> infolevel[int]:=2:

> int(exp(-x)/(1-exp(-x)),x=0..infinity,method=[':-_RETURNVERBOSE']);

Definite Integration:   Integrating expression on x=0..infinity
IntegralTransform LookUp Integrator:   Integral might be a laplace transform with
 expr=1/(1-exp(-x)) and s=1. Cook LookUp Integrator: returning answer from cook pattern 1a Definite Integration: Method cook succeeded. Definite Integration: Method asymptotic succeeded. int/indef1: first-stage indefinite integration int/indef1: first-stage indefinite integration int/indef2: second-stage indefinite integration int/indef2: applying derivative-divides int/indef1: first-stage indefinite integration int/indef1: first-stage indefinite integration Definite Integration: Method ftoc succeeded. Definite Integration: Method ftocms succeeded. int/definite/contour: contour integration [ftocms = infinity, ftoc = infinity, cook = gamma, FAILS = (distribution, piecewise, series, o, polynomial, ln, lookup, ratpoly, elliptic, elliptictrig, meijergspecial, improper, meijerg, contour), asymptotic = infinity] > restart: > infolevel[int]:=2: > int(exp(-x)/(1-exp(-x)),x=0..infinity,method=[':-_VERIFYALL']); Definite Integration: Will return a result only if all integrators agree. Definite Integration: Integrating expression on x=0..infinity IntegralTransform LookUp Integrator: Integral might be a laplace transform with expr=1/(1-exp(-x)) and s=1. Cook LookUp Integrator: returning answer from cook pattern 1a Definite Integration: Method cook succeeded. Definite Integration: Method asymptotic succeeded. int/indef1: first-stage indefinite integration int/indef1: first-stage indefinite integration int/indef2: second-stage indefinite integration int/indef2: applying derivative-divides int/indef1: first-stage indefinite integration int/indef1: first-stage indefinite integration Definite Integration: Method ftoc succeeded. Definite Integration: Method ftocms succeeded. int/definite/contour: contour integration Definite Integration: The integrators computed possibly conflicting answers. Returning unevaluated. / exp(-x) \ int|-----------, x = 0 .. infinity, method = [_VERIFYALL]| \1 - exp(-x) / > int(exp(-x)/(1-exp(-x)),x=0..infinity,method=[':-_VERIFYFLOAT']); Definite Integration: Will attempt to verify the result numerically. Definite Integration: Integrating expression on x=0..infinity IntegralTransform LookUp Integrator: Integral might be a laplace transform with expr=1/(1-exp(-x)) and s=1. Cook LookUp Integrator: returning answer from cook pattern 1a Definite Integration: Method cook returned a result which could not be verified so other integrators will still be tried. gamma Definite Integration: Method asymptotic succeeded. Definite Integration: Finished sucessfully. infinity > int(exp(-x)/(1-exp(-x)),x=0..infinity,method=[':-_VERIFYTWO']); Definite Integration: Will return a result only if the first two integrators to return results agree. Definite Integration: Integrating expression on x=0..infinity IntegralTransform LookUp Integrator: Integral might be a laplace transform with expr=1/(1-exp(-x)) and s=1. Cook LookUp Integrator: returning answer from cook pattern 1a Definite Integration: Method cook succeeded. Definite Integration: Method asymptotic succeeded. Definite Integration: The integrators computed possibly conflicting answers. Returning unevaluated. / exp(-x) \ int|-----------, x = 0 .. infinity, method = [_VERIFYTWO]| \1 - exp(-x) /

I doubt that there is enough thread-safety to run these in parallel using Threads. But maybe using the Grid package `int` could make an end run around that.

@Christopher2222 Alec's point was about global D being protected, so that you cannot by default assign to it.

You issue, about printing, is not because global :-D is protected. It is because D is assigned a procedure as value. (Both aspects relate to global D being in use by the system. But the aspects are different.)

It is easy (and gets better results) to solve your issue by using a local D. See the first printed line below, which is the local D.

f:=proc()
local D;
  print(D);
  print(:-D);
  print(':-D');
  print('':-D'');
  NULL;
end proc:

f();

                                      D
proc(f::{set, array, list, algebraic, equation, procedure})  ...  end proc;
proc(f::{set, array, list, algebraic, equation, procedure})  ...  end proc;
                                     'D'

You'd have the same issue if you wanted to use any other global name which was assigned a procedure as its value.

restart:

F:=x->x^2-sin(x):

f:=proc()
local F;
  print(F);
  print(:-F);
  print(':-F');
  print('':-F'');
  NULL;
end proc:

f();
                                      F
      2         
x -> x  - sin(x)
      2         
x -> x  - sin(x)
                                     'F'

It's also been mentioned before on this site that you can load a module which exports its own exported D (ie, bind that exported D). If you do that then you can freely assign to the name D at the top-level scope (while still having access to :-D if you need to call upon it). There's much less danger in unprotecting and/or assigning to this exported D, since doing so doesn't affect the protection and/or assignment of the global differential operator D.

restart:

m:=module () option package; export D; end module:
with(m):unprotect(D):

eval(D);
                               D

:-D(sin);
                              cos

D:=1.2;
                              1.2

eval(D);
                              1.2

dsolve({diff(f(x),x)=f(x),:-D(f)(0)=1},{f(x)});
                         f(x) = exp(x)

BTW, if you want your procedure to print out informational messages, do you have some special reason not to use printf or userinfo (at 0 level)?

@Christopher2222 Alec's point was about global D being protected, so that you cannot by default assign to it.

You issue, about printing, is not because global :-D is protected. It is because D is assigned a procedure as value. (Both aspects relate to global D being in use by the system. But the aspects are different.)

It is easy (and gets better results) to solve your issue by using a local D. See the first printed line below, which is the local D.

f:=proc()
local D;
  print(D);
  print(:-D);
  print(':-D');
  print('':-D'');
  NULL;
end proc:

f();

                                      D
proc(f::{set, array, list, algebraic, equation, procedure})  ...  end proc;
proc(f::{set, array, list, algebraic, equation, procedure})  ...  end proc;
                                     'D'

You'd have the same issue if you wanted to use any other global name which was assigned a procedure as its value.

restart:

F:=x->x^2-sin(x):

f:=proc()
local F;
  print(F);
  print(:-F);
  print(':-F');
  print('':-F'');
  NULL;
end proc:

f();
                                      F
      2         
x -> x  - sin(x)
      2         
x -> x  - sin(x)
                                     'F'

It's also been mentioned before on this site that you can load a module which exports its own exported D (ie, bind that exported D). If you do that then you can freely assign to the name D at the top-level scope (while still having access to :-D if you need to call upon it). There's much less danger in unprotecting and/or assigning to this exported D, since doing so doesn't affect the protection and/or assignment of the global differential operator D.

restart:

m:=module () option package; export D; end module:
with(m):unprotect(D):

eval(D);
                               D

:-D(sin);
                              cos

D:=1.2;
                              1.2

eval(D);
                              1.2

dsolve({diff(f(x),x)=f(x),:-D(f)(0)=1},{f(x)});
                         f(x) = exp(x)

BTW, if you want your procedure to print out informational messages, do you have some special reason not to use printf or userinfo (at 0 level)?

@hirnyk Slightly more clear is the comparison,

f :=proc(x, y)
      local d;
      sqrt(c*x^2+2*d*y^2+Pi);
    end proc:

indets(f(a,b),name) minus {constants};

                          {a, b, c, d}

{op(1, eval(f))};

                             {x, y}

{op(1, eval(f)), op(2,eval(f))};

                           {d, x, y}

It's up to the original poster to let us know which of these, if any, is wanted.

@hirnyk Slightly more clear is the comparison,

f :=proc(x, y)
      local d;
      sqrt(c*x^2+2*d*y^2+Pi);
    end proc:

indets(f(a,b),name) minus {constants};

                          {a, b, c, d}

{op(1, eval(f))};

                             {x, y}

{op(1, eval(f)), op(2,eval(f))};

                           {d, x, y}

It's up to the original poster to let us know which of these, if any, is wanted.

@Alejandro Jakubi Thanks for finding which version it broke in. when I wrote, "I don't understand the mix of try..catch and lasterror in lines 44-54 of `series/RootOf`" what I really meant was that it looked to me like an improper update from traperror&lasterror to try..catch. The traperror's obviously been replaced with try..catch but the lasterror check&followup hasn't been properly rolled into the catch clause.

@Alejandro Jakubi Thanks for finding which version it broke in. when I wrote, "I don't understand the mix of try..catch and lasterror in lines 44-54 of `series/RootOf`" what I really meant was that it looked to me like an improper update from traperror&lasterror to try..catch. The traperror's obviously been replaced with try..catch but the lasterror check&followup hasn't been properly rolled into the catch clause.

To be more careful in general, this approach should probably be more like,

indets(f(x,y),name) minus {constants};

The {x,y} that your approach obtains is only because you called f(x,y) and not because those are the formal parameters of f. If you'd called f(s,t) then you'd get back {s,t} instead.

So what you get back with this approach is a consequence of how you're calling f. That is to say, the names of the parameters of f are just "dummy" names in a sense, they don't affect the result of your approach.

But what you're doing might not be wrong, as far as this Question goes. since it isn't yet clear which the Asker really wants: the names of the formal parameters, or the indeterminate names in what gets returned by a call to f.

However, if the Asker just wants the indeterminate names in the returned result, then f doesn't have much to do with the question. If you'd assigned the result to `expr`, then indets([expr],name) minus {constants} is all that's required (with f out of the story at this point...).

To be more careful in general, this approach should probably be more like,

indets(f(x,y),name) minus {constants};

The {x,y} that your approach obtains is only because you called f(x,y) and not because those are the formal parameters of f. If you'd called f(s,t) then you'd get back {s,t} instead.

So what you get back with this approach is a consequence of how you're calling f. That is to say, the names of the parameters of f are just "dummy" names in a sense, they don't affect the result of your approach.

But what you're doing might not be wrong, as far as this Question goes. since it isn't yet clear which the Asker really wants: the names of the formal parameters, or the indeterminate names in what gets returned by a call to f.

However, if the Asker just wants the indeterminate names in the returned result, then f doesn't have much to do with the question. If you'd assigned the result to `expr`, then indets([expr],name) minus {constants} is all that's required (with f out of the story at this point...).

@hirnyk Well, there is still the issue of the order of terms in the expression (w.r.t power of beta).

I deliberately did not bother to add the terms in order of descending powers of beta. It's easy to make it do that. But the point is that orders of terms in a sum (SUM dag) depends on what's been been put in Maple's `simpl` table. If the ascending sum of powers of beta has been previously simpl'd in the same session then (due to uniquification) there's no point in trying to use `add` on its own to assemble a descending sum of terms. Trying that would result in the ascending sum, all the same. And vice-versa.

So, as you showed in your Answer, `sort` is a useful way to get the terms ordered.

restart:

add(a(3-i)*beta^(3-i),i=0..3);
                    3            2                   
           a(3) beta  + a(2) beta  + a(1) beta + a(0)

sort(%,beta,ascending);
                                       2            3
           a(0) + a(1) beta + a(2) beta  + a(3) beta 

add(a(3-i)*beta^(3-i),i=0..3); # compare with first!
                                       2            3
           a(0) + a(1) beta + a(2) beta  + a(3) beta 

restart:

add(a(i)*beta^i,i=0..3);
                                       2            3
           a(0) + a(1) beta + a(2) beta  + a(3) beta 

sort(%,beta,descending);
                    3            2                   
           a(3) beta  + a(2) beta  + a(1) beta + a(0)

add(a(i)*beta^i,i=0..3); # compare, again!
                    3            2                   
           a(3) beta  + a(2) beta  + a(1) beta + a(0)

So any forced ordering could be done, using `sort`, as a last step in `factorcoeffs` or on its returned result.

First 22 23 24 25 26 27 28 Last Page 24 of 81