NeillSmith

142 Reputation

4 Badges

14 years, 21 days

MaplePrimes Activity


These are replies submitted by NeillSmith

@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

 

Page 1 of 1