It may be possible to contrive alternative names for a snark.

I recall seeing both a French and a German translation of Jabberwocky in The Annotated Alice. The French name was given as le Jaseroque, and the German as der Jammerwoch.

This page indicates that someone thought that Snark remains the same in French, but becomes Schnark in German. (But, what's wrong with Snarque)?

acer

It may be possible to contrive alternative names for a snark.

I recall seeing both a French and a German translation of Jabberwocky in The Annotated Alice. The French name was given as le Jaseroque, and the German as der Jammerwoch.

This page indicates that someone thought that Snark remains the same in French, but becomes Schnark in German. (But, what's wrong with Snarque)?

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

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