Thank you all for your responses. Special thanks to Dr. Cheb-Terrab as his fix worked perfectly! The Maple community always come through!

Thanks again,

Neill Smith

Thank you both.  In particular mmcdara's reparameterization works perfectly for whai I wanted. You are also correct that I need the sqrt to get elliptical caps. I will check out SurfaceOfRevolution.

Thanks again to both of you.

Neill Smith

@acer 

Thanks very much. Just as I didn't know about Suppress, it would never occur to me to use convert.  This does just what I want. You are absolutely correct that I do not want to touch 'print/D'.

I know about the green arrow for attaching files. The other night it just didn't want to work correctly.  However, ever way that I tried to inline my small MW file's output into the message window failed. The formatting was always changed.  The only thing that worked was a screen capture that I pasted in my reply to @rlopez.

Thanks again.

@acer 

Thanks for the reply.  See my comments to the other responder.  Your point that D(f)(0) will display as f'(0) was very helpful. However, I have cases where I have an equation where both sides depeds on x like

lhs(x) = rhs(x).     Eq#

I do a diff command on the whole equation and then use eval or Eal to set x = a.

eval(diff(Eq#, x), x=a)

Eval(diff(Eq#, x), x=a)

See the screen shot of my exampe file that put in my reply to @rlopez

Thanks

@rlopez 

Sorry about my reply delay as I do appreciate the help. I was up to3:00 AM working the problem another way that doesn't look clean.

I am attaching a image of my little MW file. I cannot seem to be able to copy & paste a Maple session into this window.

Your Suppress command now makes an input f'(0) actually display as f'(0).

However, diff(f(x),x) does not display as f'(x). Any use of eval or Eval to set x= 0 in the diff(f(x), a) does not work.

See the image of my little MW file below. Any help on how to post small MW files here would be most welcome.

@acer 

I already can get the D form but I just don't like the looks. Plus, I think that f'(a) is what you should see when you set x = a in f'(x). I am only going up to second derivatives so besides f'(a) i need to have f''(a).

@acer Thanks again. I was thinking in terms of defining the procs in an initialization file because you don't explicitly invoke them by some "function name". I already have a .mla Library archive file, but I only have procs in it that are explicitly referenced by calling them by their function name. 

For example, I have a proc called cpmat that stands for "cross product matrix". It creates a skew-symmetrix matrix from a vector so that instead of writing a cross product as

                       (Vector C) := (Vector A) x (Vector B)

you create the skew-symetric matrix

                       (Matrix A) := cpmat((Vector A))

and then get (Vector C) from

                       (Vector C) := (Matrix A) . (Vector B)

This form of the vector cross product is extremely useful when actually progamming vehicle equations of motion.

I must confess that I come from the world of "output = function(input) in computer programming.  My brain gets totally twisted when trying to figure out any thing more than extremely simple Maple programming.

@acer This is eaxactly what I need. The evalm of the linalg packag allowed one to manipulate matrix/vector equations before doing a full evaluation.  The LinearAlgebra package seems to be really aimed at numerical computations. The examples given for converting from linalg to LinearAlgebra make a big deal of no longer needing evalm. The need to be able to manipulate matrices and vectors as unexpanded objects seems to have completely fallen by the wayside.

The Physics package examples make a big deal of being able to write relativistic tensor equations "just like in the classical texts". I wish I could write vehicle dynamical equations of motion in matrix/vector form "just like in the classical aircraft dynamics text books". Every time I have tried I have bounced.

I even looked at using the Physics Vector and Tensor subpackages, but to no avail. I suppose that if I were doing relativistic vehicle dynamics they might be of some use ;-).

Thanks again.

@acer Thanks for the help. I am going to see where I can get with your procs. One question though. How would you go about making these procs available without having to insert them into each new Maple file? I was thinking of trying to add them to my .mapleinit file (I am using 2016.2 on a Mac).

@tomleslie I appreciate your responses, but @acer is quite correct. I don't want an unevaluated output that looks like Typesetting:-delayCrossProduct(R,V).  I want to get an unevaluated output that is R x V. I also played with Typesetting options with no luck.

@acer. I appreciate your reponse very much. What I am trying to achieve is an output equation that looks like

[> 'R x V' = R x V

            R x V =  [-vz + wy, uz - wx, -uy + vx]                   (1)

in terms of the column vector notation that I defined in my original post. For display of an equation with a "single level cross product" your "print" procs work very nicely. However, if I I have an unevaluated extended cross product (which occurs often in rotating body dynamics) like

            'R x (R x V)'

I get the Typesetting:-delay type of output.

If I refer to the lhs(1) later in a worksheet, I get the expanded output shown as the rhs(1).  If I try to delay evaluation to "2 levels" I get

[>  ''R x V''

                     'Typesetting:-delayCrossProduct(R,V)'

I keep finding that the LinearAlgebra package "lost" a lot of the capability that was in the linalg package.

One final note to @acer. I did try to upload my own example worksheet using the green up-arrow, but the procedure stalled after I selected my test case MW file to upload. In step 3 the buttons for linking the file or uploading the file contents into my "post space" did not work.

Thanks again to both of you.

Thanks for clearing this up. It looks like that getassumptions is the safest way to go. I'll avoid using about in the future.

Neill S.

Thanks for the quick reply. I wasn't aware of the _EnvExplicit:= true option. Your solution from solve looks very similar to my implementations of the analytic quartic solution. The trick is trying to be sure that I have extracted the real positive root. I was hoping someone would know of a cleaner way to get the real positive root. I like your scaling trick. It makes the analytic quartic solution a little cleaner. As for your second solution -- I wouldn't know a pohhammer or hypergeom function if it bit me ;-).

Thanks for the help.

Neill S.

Thanks for the quick reply. I wasn't aware of the _EnvExplicit:= true option. Your solution from solve looks very similar to my implementations of the analytic quartic solution. The trick is trying to be sure that I have extracted the real positive root. I was hoping someone would know of a cleaner way to get the real positive root. I like your scaling trick. It makes the analytic quartic solution a little cleaner. As for your second solution -- I wouldn't know a pohhammer or hypergeom function if it bit me ;-).

Thanks for the help.

Neill S.

Thanks Dr. Israel. It never occurred to me to try signum. The issue with about is kind of troubling given how simple the sample problem is.

Neill

I have to admit that I do not understand your piece of "not pretty" Maple code. I understand that you are somehow replacing the operator '*' with the operator '&*', but just how your code achieves this is beyond me. What bothers me is that the linalg package changed my '&*' operator to the non-matrix operator '*' in the creation of EoM1.

> EoM := `&*`(MAM, S);

                                EoM := MAM &* S

> EoM1 := evalm(EoM);

                                 [TAM Vel + TRAM Omg]

                                 [RTAM Vel + RAM Omg]

 This seems to me to be a really bad flaw in the linalg package for it not to preserve the '&*' operator in what should be perfectly valid matrix multiplications. If it weren't for this flaw, I could use the linalg package to do what I need o do.

I actually had thought about your suggestion for "creating Matrices/matrices with only names as entries for the blocks"  so that I could use the LinearAlgebra package. I don't need to do "blocks of blocks" in my matrices -- the level of "blocking" in my example is as far as I need to go. However, I do need to combine addition of block matrices with mutiplication. The more correct form of EoM above should be

EoM = [M + MAM] &* S

where M is another block matrix similar to MAM. Actually M is the standard mass matrix (including moments and products of inertia since it is a 6x6 matrix when expanded), and MAM is "added mass" matrix. I may still go that route using the LinearAlgebra package, but I would really prefer to deal with acutual matrices with the linalg package if someone can suggest a "pretty" way to get around the '&*' becoming '*' problem.

Thanks again for your help,

Neill Smith