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

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