What you're seeing in E looks like premature evaluation. (Is striving to change p.e. tilting at windmills? I'm not sure.)

Presumably your point is that you want E to be C, without having to set Digits to 20 beforehand. While an uneval (or evaln) argument to a procedure, like sin(Pi) can be prevented from evaluating, the 1/6. inside sin(Pi/6.) is another story.

> pe := proc(x::uneval) lprint(x); x; end proc:

> pe(sin(Pi));
sin(Pi)
                                    sin(Pi)
 
> pe(Pi/6.);
.1666666667*Pi
                                0.1666666667 Pi

acer

What you're seeing in E looks like premature evaluation. (Is striving to change p.e. tilting at windmills? I'm not sure.)

Presumably your point is that you want E to be C, without having to set Digits to 20 beforehand. While an uneval (or evaln) argument to a procedure, like sin(Pi) can be prevented from evaluating, the 1/6. inside sin(Pi/6.) is another story.

> pe := proc(x::uneval) lprint(x); x; end proc:

> pe(sin(Pi));
sin(Pi)
                                    sin(Pi)
 
> pe(Pi/6.);
.1666666667*Pi
                                0.1666666667 Pi

acer

After those changes E will still come out the same.

> unprotect(`*`);
> `*`:=(a,b)->a*b:
> protect(`*`);
> `&/`:=(a,b)->b(a):
> C := sin( Pi/6 ) &/ evalf[20];
                          C := 0.50000000000000000000
 
> C := sin( Pi/6. ) &/ evalf[20];
                          C := 0.50000000009068996821

One might label automatic simplification as one form of p.e.

note. Alec's response was edited while I was composing the above reply, and the first 5 input lines above removed. Sorry, Alec! I suppose that it was realized that automatic simplification cannot be turned off by us mortals.

acer

After those changes E will still come out the same.

> unprotect(`*`);
> `*`:=(a,b)->a*b:
> protect(`*`);
> `&/`:=(a,b)->b(a):
> C := sin( Pi/6 ) &/ evalf[20];
                          C := 0.50000000000000000000
 
> C := sin( Pi/6. ) &/ evalf[20];
                          C := 0.50000000009068996821

One might label automatic simplification as one form of p.e.

note. Alec's response was edited while I was composing the above reply, and the first 5 input lines above removed. Sorry, Alec! I suppose that it was realized that automatic simplification cannot be turned off by us mortals.

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

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