This is so nice and simple. Much more Maple-like than my `&N` above.

It's a pity about the parentheses, sometimes necessary on account of Maple's immutable operator precedence rules. Now maybe it'd be far too much effort, but could one write an analyzer/replacer that took input and inserted brackets so as to force a particular choice of alternative operator precedence rules? I'm not sure whether ToInert could work easily. Perhaps converting a procedure's evaln argument to a string might be a start.

ps. I believe that it is possible to treat top-level input as if it were an evaln parameter of a procedure (for 1D input, at least). The hint is to look closely at the source of the Warnings package on mapleapps.

acer

This is so nice and simple. Much more Maple-like than my `&N` above.

It's a pity about the parentheses, sometimes necessary on account of Maple's immutable operator precedence rules. Now maybe it'd be far too much effort, but could one write an analyzer/replacer that took input and inserted brackets so as to force a particular choice of alternative operator precedence rules? I'm not sure whether ToInert could work easily. Perhaps converting a procedure's evaln argument to a string might be a start.

ps. I believe that it is possible to treat top-level input as if it were an evaln parameter of a procedure (for 1D input, at least). The hint is to look closely at the source of the Warnings package on mapleapps.

acer

Yes, that sounds better.

acer

Yes, that sounds better.

acer

I interpreted the request similar to this, Jean-Marc.

In addition to Alec's common sense suggestion using evalf(%) below, one might also try various infix hacks. For example,

> `&N` :=proc(a,b)
> if type(b,posint) then
>   evalf[b](a);
> else
>   evalf(a);
> end if;
> end proc:

> sin(Pi/3) &N 20;
                            0.86602540378443864675
 
> sin(Pi/3) &N ``;
                                 0.8660254040
 
> sin(Pi/3);
                                      1/2
                                     3
                                     ----
                                      2
 
> % &N 20;
                            0.86602540378443864675

Perhaps someone else can suggest a prettier solution.

acer

I interpreted the request similar to this, Jean-Marc.

In addition to Alec's common sense suggestion using evalf(%) below, one might also try various infix hacks. For example,

> `&N` :=proc(a,b)
> if type(b,posint) then
>   evalf[b](a);
> else
>   evalf(a);
> end if;
> end proc:

> sin(Pi/3) &N 20;
                            0.86602540378443864675
 
> sin(Pi/3) &N ``;
                                 0.8660254040
 
> sin(Pi/3);
                                      1/2
                                     3
                                     ----
                                      2
 
> % &N 20;
                            0.86602540378443864675

Perhaps someone else can suggest a prettier solution.

acer

New for Maple 12, I believe. See here, for Maple 11 system requirements.

Windows XP 64-bit is a strange platform, in some respects. As you probably know, it has 64bit pointers but retains the 32bit long. (Hence, the bug described could still conceivably have a 32bit/64bit dependence, regardless of the behaviour of Windows XP 64-bit.)

acer

There is a (native) 64bit Windows version of Maple12.02. The kernelopts(system) command returns "X86 64 WINDOWS" on it.

> kernelopts(version);
            Maple 12.02, X86 64 WINDOWS, Dec 10 2008 Build ID 377066

> with(LinearAlgebra[Modular]):
> A4 := Random(31, 0, 5, float[8]);
                           A4 := [0., 0., 0., 0., 0.]

acer

> 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

> 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