> T := module() option package;
> export sin, arcsin;
>   sin := proc(x) :-sin(x*Pi/180); end proc:
>   arcsin := proc(x) 180/Pi * :-arcsin(x); end proc:
> end module:
> with(T):

> sin(30);
                                      1/2
 
> arcsin(%);
                                      30
 
> sin(60);
                                      1/2
                                     3
                                     ----
                                      2
 
> arcsin(%);
                                      60

acer

No particular reason (except possibly to show that it could be done that way, and that I have a cold). Further down, I used unapply(expr,t) which does look more straightforward.

I recall another post in the past few months with the same issue and suggested workaround, although I didn't search for it.

BTW, the OP asked about which methods work best. Passing a procedure instead of an expression seems to allow evalf@Int to treat the integrand more as a black box and appears to have had the benefit of preventing a stall during symbolic expansion to the large power. But in general that might conceivably also prevent some useful analysis of the integrand and thus possibly even prevent evalf@Int from deducing an appropriate method (eg. an oscillatory method, or one which deals better with detected singularities in the range).

acer

No particular reason (except possibly to show that it could be done that way, and that I have a cold). Further down, I used unapply(expr,t) which does look more straightforward.

I recall another post in the past few months with the same issue and suggested workaround, although I didn't search for it.

BTW, the OP asked about which methods work best. Passing a procedure instead of an expression seems to allow evalf@Int to treat the integrand more as a black box and appears to have had the benefit of preventing a stall during symbolic expansion to the large power. But in general that might conceivably also prevent some useful analysis of the integrand and thus possibly even prevent evalf@Int from deducing an appropriate method (eg. an oscillatory method, or one which deals better with detected singularities in the range).

acer

Is a floating-point numeric result adequate? If it is, then the example below might help show how you can get fsolve to handle it. If you want an exact result that doesn't contain RootOf notation, then we might be able to help if you post the code itself.

> myproc := proc(x)
> if x < 1 then (x-1)^2;
> else -(x-1)^2;
> end if;
> end proc:

> fsolve(myproc(x)-1,x);
Error, (in myproc) cannot determine if this expression is true or false: x < 1

> fsolve(x->myproc(x)-1);
                                      0.

> myproc := proc(x)
> if not type(x,numeric) then return 'procname'(args); end if;
> if x < 1 then (x-1)^2;
> else -(x-1)^2;
> end if;
> end proc:

> fsolve(myproc(x)-1,x);
                                      0.

> kernelopts(version);
           Maple 10.00, IBM INTEL LINUX, May 13 2005 Build ID 190196

acer

Look:

> P:=(f,x,a,m,n)->convert(series(f,x=a,m+n+1),'ratpoly',m,n):
> P(exp(x),x,0,4,2);
                                     2         3          4
                    1 + 2/3 x + 1/5 x  + 1/30 x  + 1/360 x
                    ---------------------------------------
                                                2
                              1 - 1/3 x + 1/30 x

But that's exactly what numapprox:-pade does (with more argument checking, and a try..catch).

> eval(numapprox:-pade);
proc(
f::algebraic, eqn::{name, name = algebraic}, deg::{integer, list(integer)}
)
local x, a, m, n, s;
    if type(eqn, '`=`') then x, a := op(eqn) else x := eqn; a := 0 end if;
    if type(deg, 'integer') then m, n := deg, 0
    elif nops(deg) = 2 then m, n := op(deg)
    else error
        "third argument must be an integer or a list of two integers"
    end if;
    try s := series(f, x = a, m + n + 1) catch:  end try;
    if not type(s, 'series') then error "unable to compute series" end if;
    convert(s, 'ratpoly', m, n)
end proc

ps. The all-caps is unnecessary.

acer

Look:

> P:=(f,x,a,m,n)->convert(series(f,x=a,m+n+1),'ratpoly',m,n):
> P(exp(x),x,0,4,2);
                                     2         3          4
                    1 + 2/3 x + 1/5 x  + 1/30 x  + 1/360 x
                    ---------------------------------------
                                                2
                              1 - 1/3 x + 1/30 x

But that's exactly what numapprox:-pade does (with more argument checking, and a try..catch).

> eval(numapprox:-pade);
proc(
f::algebraic, eqn::{name, name = algebraic}, deg::{integer, list(integer)}
)
local x, a, m, n, s;
    if type(eqn, '`=`') then x, a := op(eqn) else x := eqn; a := 0 end if;
    if type(deg, 'integer') then m, n := deg, 0
    elif nops(deg) = 2 then m, n := op(deg)
    else error
        "third argument must be an integer or a list of two integers"
    end if;
    try s := series(f, x = a, m + n + 1) catch:  end try;
    if not type(s, 'series') then error "unable to compute series" end if;
    convert(s, 'ratpoly', m, n)
end proc

ps. The all-caps is unnecessary.

acer

It is possible to create a customized system (derived from SI, say) in which seconds are represented as 1/hertz and 1/seconds are represented as hertz.

> Units:-AddSystem(mySI,Units:-GetSystem(SI),Hz,1/Hz):

Once such a system has been created, one can forcibly convert single expressions in that new system (without changing default behaviour),

> x := Unit(kg/s*m^2);
                                      [    2]
                                      [kg m ]
                                 x := [-----]
                                      [  s  ]

> convert(x,system,mySI);
                                  [       2]
                                  [kg Hz m ]

One can also change the ("default") behaviour of combining units in new expressions,

> Units:-UseSystem(mySI):

> x := Unit(kg/s*m^2);
                                     [       2]
                                x := [kg Hz m ]
 
> x := Unit(kg*s/m^2);
                                      [ kg  ]
                                 x := [-----]
                                      [    2]
                                      [Hz m ]

acer

It is possible to create a customized system (derived from SI, say) in which seconds are represented as 1/hertz and 1/seconds are represented as hertz.

> Units:-AddSystem(mySI,Units:-GetSystem(SI),Hz,1/Hz):

Once such a system has been created, one can forcibly convert single expressions in that new system (without changing default behaviour),

> x := Unit(kg/s*m^2);
                                      [    2]
                                      [kg m ]
                                 x := [-----]
                                      [  s  ]

> convert(x,system,mySI);
                                  [       2]
                                  [kg Hz m ]

One can also change the ("default") behaviour of combining units in new expressions,

> Units:-UseSystem(mySI):

> x := Unit(kg/s*m^2);
                                     [       2]
                                x := [kg Hz m ]
 
> x := Unit(kg*s/m^2);
                                      [ kg  ]
                                 x := [-----]
                                      [    2]
                                      [Hz m ]

acer

You don't need to issue with(Units) for this particular computation.

You might want to try these alternatives for some of the later commands in your worksheet (where it appeared to have problems),

plot(convert(combine(subs(const, L[vpeak](T)), 'units'), 'unit_free'), T = 2000 .. 5500);
plot(convert(simplify(subs(const, L[vpeak](T))), 'unit_free'), T = 2000 .. 5500);

evalf(combine(subs(const, L[vpeak](2000.0)), 'units'));
evalf(simplify(subs(const, L[vpeak](2000.0))));

map(t -> map(convert, combine(t, 'units'), 'unit_free'), const);
map(t -> map(convert, simplify(t), 'unit_free'), const);

When you attempted a units replacement at the end, using the context-menus, did you intend to replace kg/(s^2*K^3) by kg*Hz^2/K^3 ?

acer

You don't need to issue with(Units) for this particular computation.

You might want to try these alternatives for some of the later commands in your worksheet (where it appeared to have problems),

plot(convert(combine(subs(const, L[vpeak](T)), 'units'), 'unit_free'), T = 2000 .. 5500);
plot(convert(simplify(subs(const, L[vpeak](T))), 'unit_free'), T = 2000 .. 5500);

evalf(combine(subs(const, L[vpeak](2000.0)), 'units'));
evalf(simplify(subs(const, L[vpeak](2000.0))));

map(t -> map(convert, combine(t, 'units'), 'unit_free'), const);
map(t -> map(convert, simplify(t), 'unit_free'), const);

When you attempted a units replacement at the end, using the context-menus, did you intend to replace kg/(s^2*K^3) by kg*Hz^2/K^3 ?

acer

The reason that it looks shorter in python is because someone's already written its functions urlencode, urlopen, etc.

So one might reasonably ask how hard it would be to write the equivalent functions in maple, so as not to have to type all that out like John did. That's how to use Maple effectively -- to write re-usable procedures for repeating queries. Also possible is to distribute them (as the python community does) for others to use.

For example, are the undocumented HTTP:-Post and HTTP:-URLEncode close, or do they require changes in order to do this task?

acer

Is vim's maple mode primarily for editing (eg, syntax highlighting, autoindent, etc)? Does it also provide macros for pumping the buffer into a new commandline Maple session?

Perhaps people could post some of their favourite .vimrc gems that relate to Maple.

acer

Is vim's maple mode primarily for editing (eg, syntax highlighting, autoindent, etc)? Does it also provide macros for pumping the buffer into a new commandline Maple session?

Perhaps people could post some of their favourite .vimrc gems that relate to Maple.

acer

Live and learn. Thanks. Sorry to have doubted you, Alec.

acer

> StringTools:-Soundex("links");
                                    "L520"
 
> StringTools:-Soundex("lynx");
                                    "L520"

Alec may have been thinking of the lynx browser.

acer