@hirnyk This seems to work in 1D notation in Maple 13.02, 12.02, or 11.02 using the default interface(prettyprint) level of 3 in a Standard Worksheet,

> proc () local t; t := proc () debugopts('callstack')[9] end proc; printf("%s;\n",eval(t)()) end proc();
proc () local t; t := proc () debugopts('callstack')[9] end proc; printf("%s;\n",eval(t)()) end proc();

I wonder if these are suitable for inclusion here? By coincidence, a work colleague recently wrote a paradox using the term quine on my whiteboard, when I was expressing my liking of some works of the late philosopher W.V.Quine.

@hirnyk This seems to work in 1D notation in Maple 13.02, 12.02, or 11.02 using the default interface(prettyprint) level of 3 in a Standard Worksheet,

> proc () local t; t := proc () debugopts('callstack')[9] end proc; printf("%s;\n",eval(t)()) end proc();
proc () local t; t := proc () debugopts('callstack')[9] end proc; printf("%s;\n",eval(t)()) end proc();

I wonder if these are suitable for inclusion here? By coincidence, a work colleague recently wrote a paradox using the term quine on my whiteboard, when I was expressing my liking of some works of the late philosopher W.V.Quine.

@hirnyk Which language did you have in mind, 1D or 2D?

In the 2D Math, where a trailing semicolon is not required, here are two examples (rendered here as plaintext, but can be keyed in as seen here),

proc() Typesetting:-Typeset(thisproc()) end proc()

proc() 'thisproc'() end proc()

And for 1D Maple Notation (keeping interface(prettyprint) at its default value of 3, and operating in a Worksheet in the Standard GUI),

> proc () printf("%a;\n",('thisproc')()) end proc();
proc () printf("%a;\n",('thisproc')()) end proc();

At interface(prettyprint=1) in a Worksheet, or in the commandline interface, one of the earlier 1D notation examples works,

> proc() print(eval(thisproc)); end proc;
proc() print(eval(thisproc)); end proc;

@hirnyk Which language did you have in mind, 1D or 2D?

In the 2D Math, where a trailing semicolon is not required, here are two examples (rendered here as plaintext, but can be keyed in as seen here),

proc() Typesetting:-Typeset(thisproc()) end proc()

proc() 'thisproc'() end proc()

And for 1D Maple Notation (keeping interface(prettyprint) at its default value of 3, and operating in a Worksheet in the Standard GUI),

> proc () printf("%a;\n",('thisproc')()) end proc();
proc () printf("%a;\n",('thisproc')()) end proc();

At interface(prettyprint=1) in a Worksheet, or in the commandline interface, one of the earlier 1D notation examples works,

> proc() print(eval(thisproc)); end proc;
proc() print(eval(thisproc)); end proc;

Is your Matrix symmetric? The CLAPACK function dsyevx does this.

If you are using Linux (and maybe OSX or Solaris) then I can likely write a define_external that does it straight from stock Maple. I don't know offhand whether it'd be as simple for MS-Windows, since I'm unsure whether the symbol `dsyevx_` is an export of clapack.dll as bundled with Maple. (...still possible with a little C work, though.)

You wrote of "large" Matrices. How large is that? How long are you prepared to wait? I was able to compute all eigenvectors of a nonsymmetric float[8] 2000x2000 Matrix, and sort the complex eigenvalues and select the eigenvector corresponding to one of those. That took about 2 minutes on a fast machine. Do you need it much faster?

acer

Using a Plot Component and a nice choice of Manipulator you can quickly click along a country's border to get the simple data for your POLYGONs. (It's really convenient when adjusted to set clickx,clicky to the value of the "Nearest datum".

coastplotter.mw

There's probably some slick, purely programming approach too. I liked this because it reminded me of watching Geography students doing the same thing by hand, decades ago...

nb. I chose the "Matlab" format, at that website you cited.

acer

What do you mean by, "a better figure aspect"?

Are you saying that the rendered curve is not smooth enough for your liking, or that some other part of the generated plot is not adequate? (I mean your actual plot, not the linear example posted, naturally.)

acer

Ideally, surfdata would handle a Matrix automatically.

And of course, one could create an Array in the first place. Or use rtable_options(G1,subtype=Array) to alter a Matrix G1 inplace.

G1:=Array(1..101,1..93,(i,j)->evalhf(sin(i/7)+cos(j/5)),datatype=float[8]):
plots:-surfdata(G1, axes=boxed);

acer

Ideally, surfdata would handle a Matrix automatically.

And of course, one could create an Array in the first place. Or use rtable_options(G1,subtype=Array) to alter a Matrix G1 inplace.

G1:=Array(1..101,1..93,(i,j)->evalhf(sin(i/7)+cos(j/5)),datatype=float[8]):
plots:-surfdata(G1, axes=boxed);

acer

@mnhoff It worked for me, in Maple 14.01. It gave sol2 as a call to 2-argument arctan.

arctan(sin(w*t)-sin(w*t)*exp(-r/d)*cos(w*r)+exp(-r/d)*sin(w*r)*cos(w*t),
       cos(w*t)-cos(w*t)*exp(-r/d)*cos(w*r)-exp(-r/d)*sin(w*r)*sin(w*t));

@mnhoff It worked for me, in Maple 14.01. It gave sol2 as a call to 2-argument arctan.

arctan(sin(w*t)-sin(w*t)*exp(-r/d)*cos(w*r)+exp(-r/d)*sin(w*r)*cos(w*t),
       cos(w*t)-cos(w*t)*exp(-r/d)*cos(w*r)-exp(-r/d)*sin(w*r)*sin(w*t));

Hitting the arctan expression q with both of cos and sin, to see if either might get rid of the undesirable radical form, was not a completely accidental trick.

There might be a consensus of opinion that the particular form of nested radical is awkward to handle in Maple.

acer

Hitting the arctan expression q with both of cos and sin, to see if either might get rid of the undesirable radical form, was not a completely accidental trick.

There might be a consensus of opinion that the particular form of nested radical is awkward to handle in Maple.

acer

@hirnyk

The first thing to notice is that your modified usage no longer finds the exact answer of 2*Pi/5 and by merely converting the expression from an arctan to an arcsin call the original goal of obtaining the exact value of 2*Pi/5 is not met.

> restart:

> identify(evalf(arctan((10+2*5^(1/2))^(1/2)/(5^(1/2)-1)),30));

                       /                 (1/2)\
                       |1 /        (1/2)\     |
                 arcsin|- \10 + 2 5     /     |
                       \4                     /

The difficulties and dangers of `identify` are intrinsic to the method. Raising the working precision for `evalf` may improve the odds but "counter-examples" may still be found. So in order to be completely confident of the result's exact correctness some follow-up check is still necessary. Hence it's not always an easy way to get a sure exact result.

> restart:

> z:=arctan((11039/15+2*5^(1/2))^(1/2)/(5^(1/2)-1));

                      /                  (1/2)\
                      |/11039      (1/2)\     |
                      ||----- + 2 5     |     |
                      |\ 15             /     |
                arctan|-----------------------|
                      |       (1/2)           |
                      \      5      - 1       /

> y:=identify(evalf(z,30));

                         (1/2)        9
                        5      Zeta(5) 
                        ---------------
                                (1/6)  
                         2 ln(3)       

> evalf[500](z-y): evalf[5](%);
                                    -8
                          -1.0474 10  

A more careful approach might be to increase the working precision under which `identify` operates, and not just the floating-point evaluation of the original expression. Raising Digits to say 15, prior to calling identify, might be more careful. (For one thing, matches are less "commonplace".) But it's still not completely foolproof. And raising Digits too high can also cause a miss.

acer

@hirnyk

The first thing to notice is that your modified usage no longer finds the exact answer of 2*Pi/5 and by merely converting the expression from an arctan to an arcsin call the original goal of obtaining the exact value of 2*Pi/5 is not met.

> restart:

> identify(evalf(arctan((10+2*5^(1/2))^(1/2)/(5^(1/2)-1)),30));

                       /                 (1/2)\
                       |1 /        (1/2)\     |
                 arcsin|- \10 + 2 5     /     |
                       \4                     /

The difficulties and dangers of `identify` are intrinsic to the method. Raising the working precision for `evalf` may improve the odds but "counter-examples" may still be found. So in order to be completely confident of the result's exact correctness some follow-up check is still necessary. Hence it's not always an easy way to get a sure exact result.

> restart:

> z:=arctan((11039/15+2*5^(1/2))^(1/2)/(5^(1/2)-1));

                      /                  (1/2)\
                      |/11039      (1/2)\     |
                      ||----- + 2 5     |     |
                      |\ 15             /     |
                arctan|-----------------------|
                      |       (1/2)           |
                      \      5      - 1       /

> y:=identify(evalf(z,30));

                         (1/2)        9
                        5      Zeta(5) 
                        ---------------
                                (1/6)  
                         2 ln(3)       

> evalf[500](z-y): evalf[5](%);
                                    -8
                          -1.0474 10  

A more careful approach might be to increase the working precision under which `identify` operates, and not just the floating-point evaluation of the original expression. Raising Digits to say 15, prior to calling identify, might be more careful. (For one thing, matches are less "commonplace".) But it's still not completely foolproof. And raising Digits too high can also cause a miss.

acer