@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

@belief111 

I'm sorry to disappoint you, but there really isn't much information to be had on this.

This topic is a bit advanced. It hinges on the fact that Maple uses a special form of structure, as intermediary object, for the purpose of 2-dimensional mathematical typesetting (a.k.a. 2D Math). There aren't a full set of commands to construct such objects in a program. I accomplished it above by programmatically (crudely) concatenating together the various portions of such objects.

There are a few other ways to construct such objects (which get interpreted by Maple's GUI as things to pretty-print as 2D Math). In a 2009 workshop, Paulina Chin described some of the basics, labelling the internal form of typeset objects as TypeMK. That is the form that has been used in this post. So I could also do the following:

You might get some insight by issuing these commands as 1D Maple Notation input in a Worksheet.

expr:=f[x]; # a table reference, not an atomic identifier
lprint(expr); # demonstrating that it is a table reference
Typesetting:-Typeset(f[x]); # now as function calls to unassign Typesetting exports
lprint(%); # demonstrating the last claim
convert(%,`global`); # now as function calls to global function names
cat(`#`,convert(%,name)); # now a so-called atomic identifier
lprint(%);
`#msub(mi("f"),mi("x"))`;

Apart from such translation of an expression as a whole to TypeMK (as done above) there are few if any other commands for stitching together TypeMK structures. Hence the few people who accomplish that in programs usually do so by brute-force concatenation.

acer

@epostma sort[inplace] is still nifty, and a nice suggestion, even if it only sorts in a few possible ways for float[8].

If I recall, the BLAS function daxpy might not accept negative strides on all platforms' implementations. But an `adder` might still be compiled, and made to act on the various negative and/or positive parts of the Aliased Array. It could be made to perform specialized adding, striding backward or forward from the neg/pos boundary as you suggest.

@epostma sort[inplace] is still nifty, and a nice suggestion, even if it only sorts in a few possible ways for float[8].

If I recall, the BLAS function daxpy might not accept negative strides on all platforms' implementations. But an `adder` might still be compiled, and made to act on the various negative and/or positive parts of the Aliased Array. It could be made to perform specialized adding, striding backward or forward from the neg/pos boundary as you suggest.

I believe that it can all be done easily, both for using the 'method' option of evalf/Int as well as avoiding cut and paste (perhaps via a handy use of `subs`, even if not more easily). If you upload the worksheet, we could more easily demonstrate it to you. That's less work for us than having to cook up an example, and besides which your sheet may have other aspects that pertain. The upload avoids guesswork.

acer