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

There does not seem to exist an explicit formula that Maple can find for the roots of that degree 7 characteristic polynomial. This is not very surprising, because in general polynomials of degree >5 are not solvable for explicit forms of the roots. The RootOf construct is Maple's placeholder for this.

But look, you've already had an answer containing a procedure that takes any float value for z and returns the eigenvectors. Ok, so it returns both eigenvalues and eigenvectors. But put [...][2] around it and it gives the eigenvectors. Wrap that with some procedure that takes a Matrix of eigenvectors and produces your float t (time evolution thingy), and you're done.

That kind of numeric approach is often more accurate than obtaining some formulae (here, in z) which might themselves be even more sensitive to roundoff.

acer

There does not seem to exist an explicit formula that Maple can find for the roots of that degree 7 characteristic polynomial. This is not very surprising, because in general polynomials of degree >5 are not solvable for explicit forms of the roots. The RootOf construct is Maple's placeholder for this.

But look, you've already had an answer containing a procedure that takes any float value for z and returns the eigenvectors. Ok, so it returns both eigenvalues and eigenvectors. But put [...][2] around it and it gives the eigenvectors. Wrap that with some procedure that takes a Matrix of eigenvectors and produces your float t (time evolution thingy), and you're done.

That kind of numeric approach is often more accurate than obtaining some formulae (here, in z) which might themselves be even more sensitive to roundoff.

acer

One has to be extra careful with identify(). A small edit to the above example gets this (incorrect) conclusion,

> identify(evalf(arctan((11+2*5^(1/2))^(1/2)/(5^(1/2)-1))));

                            (1/3)  (1/3)
                        49 2      7     
                        ----------------
                                  (5/6) 
                        80 Zeta(3)      

That returned symbolic value shares only 8 decimal digits with the true value.

Hence for the given example an identify() apporach is only suitable if the result is subsequently tested. But if you tack on the act of converting the relevant trig call back to radical then the method as a whole is no longer so simple.

acer

One has to be extra careful with identify(). A small edit to the above example gets this (incorrect) conclusion,

> identify(evalf(arctan((11+2*5^(1/2))^(1/2)/(5^(1/2)-1))));

                            (1/3)  (1/3)
                        49 2      7     
                        ----------------
                                  (5/6) 
                        80 Zeta(3)      

That returned symbolic value shares only 8 decimal digits with the true value.

Hence for the given example an identify() apporach is only suitable if the result is subsequently tested. But if you tack on the act of converting the relevant trig call back to radical then the method as a whole is no longer so simple.

acer

I forgot to mention that there is an item in the TypeSetting:-RuleAssistant command's pop-up window that might relate. It's a checkbox labeled "Subscript Derivatives".

The help-page ?Typesetting,RuleAssistant has this,

   Subscript Derivatives - Use a subscripted sequence of variable names for partial derivatives
                           of functions with suppressed dependencies.

Unfortunately I don't fully understand what this means. The ?Typesetting,Suppress help-page doesn't mention it, and using that command to suppress f(x) say, and checking that described RuleAssistant box, doesn't appear to enable any subscripted f as a derivative of an operator f. I had my document typesetting level set to "Extended", and the Typesetting setting of userep=true.

In fact this rule seems described as going in the opposite way from what this post is all about, by taking something like del f/del x and printing out f_x. It doesn't look like it's intended to do anything for f_x as 2D Math input. (PDEtools[declare] looks like it too is acting in the opposite direction from this post's topic.)

acer