It would make guessing the intended meaning easier if you supplied the missing pieces of the post.

> convert(1/(z^2+9),parfrac,I);
                               1/6 I      1/6 I
                              -------- + -------
                              -z + 3 I   z + 3 I
> normal(1/%);
                             -(-z + 3 I) (z + 3 I)

> factor(z^2+9,I);
                             -(-z + 3 I) (z + 3 I)

Follow the links to relevant individual routines in the help for the VectorCalculus package. Look at the Examples for those routines.

Follow the links to relevant individual routines in the help for the VectorCalculus package. Look at the Examples for those routines.

I'm not sure what you mean by "label". You can enter the symbol in (default) 2D Math mode by subscripting a regular M. Use the appropriate subscript symbol found on the Operator palette.

In 1D notation, it could be like this,

`#msub(mi("M"),mo("⊙"))` := 0.198892e31*Units:-Unit(kg);

I'm not sure what you mean by "label". You can enter the symbol in (default) 2D Math mode by subscripting a regular M. Use the appropriate subscript symbol found on the Operator palette.

In 1D notation, it could be like this,

`#msub(mi("M"),mo("⊙"))` := 0.198892e31*Units:-Unit(kg);

I really hope that the replacement concept is seriously considered. Just as now, the 2D Math parser could detect

 f(x) := ...

and show the dialogue box with the same two choices of function definition vs. remember table assignment. But upon selection of "function definition" it could replace the entered code, right there in the Worksheet/Document, with this.

 f := x -> ...

In that scenario, the code would be distributable without needing Settings calls. It would also be visually unambiguous without need for hover-overs/bubble-help/tooltips, which should not be undervalued. And it would teach the user how to enter future similar code directly and without any need to switch hand to the mouse pointer so as to respond to the popup dialogue. That's a great deal of benefit for such a simple modification.

And the new user would still be allowed to type in f(x):=... without getting into a mess. And that's really all the benefit that was desperately needed. The new alternative syntax doesn't really have other great merit, per se. It's primary characteristic is its ambiguity.

I can't help but feel that there's danger in 1D vs 2D parsing differences which occur only in "text code" (non-diagramatic or non-typeset pieces). If someone looks at f(x):=... (on the web, or a Maple help page, or in a textbook, in the Online Help, etc) then there is a real risk that the person might not notice that it is 2D Math input. The situation is not similar to that of typeset Sigma for summation, or an integral sign. The person might simply try and enter the code by hand as 1D Maple notation input, and so get the wrong meaning entirely.

I really hope that the replacement concept is seriously considered. Just as now, the 2D Math parser could detect

 f(x) := ...

and show the dialogue box with the same two choices of function definition vs. remember table assignment. But upon selection of "function definition" it could replace the entered code, right there in the Worksheet/Document, with this.

 f := x -> ...

In that scenario, the code would be distributable without needing Settings calls. It would also be visually unambiguous without need for hover-overs/bubble-help/tooltips, which should not be undervalued. And it would teach the user how to enter future similar code directly and without any need to switch hand to the mouse pointer so as to respond to the popup dialogue. That's a great deal of benefit for such a simple modification.

And the new user would still be allowed to type in f(x):=... without getting into a mess. And that's really all the benefit that was desperately needed. The new alternative syntax doesn't really have other great merit, per se. It's primary characteristic is its ambiguity.

I can't help but feel that there's danger in 1D vs 2D parsing differences which occur only in "text code" (non-diagramatic or non-typeset pieces). If someone looks at f(x):=... (on the web, or a Maple help page, or in a textbook, in the Online Help, etc) then there is a real risk that the person might not notice that it is 2D Math input. The situation is not similar to that of typeset Sigma for summation, or an integral sign. The person might simply try and enter the code by hand as 1D Maple notation input, and so get the wrong meaning entirely.

Just look at that link I mentioned. Scroll down to the Threads examples there. Use that, but replace any "while true do" with "while x do". It's not complicated.

Just look at that link I mentioned. Scroll down to the Threads examples there. Use that, but replace any "while true do" with "while x do". It's not complicated.

I'm not sure what you're trying to "see" for question 2.

> exp(((I*2)*Pi)); evalf(%);
                                       1

                                      1.
> exp(I*0.0); simplify(%);
                                   1. + 0. I

                                      1.

For question 3, convert/parfrac shows it.

> ee:=1/(z^2*(z^2+9));
                                          1
                               ee := -----------
                                      2   2
                                     z  (z  + 9)

> convert(ee,parfrac);
                                    1         1
                              - ---------- + ----
                                    2           2
                                9 (z  + 9)   9 z

I'm not sure what you're trying to "see" for question 2.

> exp(((I*2)*Pi)); evalf(%);
                                       1

                                      1.
> exp(I*0.0); simplify(%);
                                   1. + 0. I

                                      1.

For question 3, convert/parfrac shows it.

> ee:=1/(z^2*(z^2+9));
                                          1
                               ee := -----------
                                      2   2
                                     z  (z  + 9)

> convert(ee,parfrac);
                                    1         1
                              - ---------- + ----
                                    2           2
                                9 (z  + 9)   9 z

You say that you want to differentiate eta just once. But with respect to which parameter of eta, the first or the second? That's what D[1](eta) and D[2](eta) do.

Or perhaps you mean once w.r.t each in turn? If so, consider D[1,2](eta) or D[2,1](eta).

Or are you thinking of some total differential? (It's hard to see what you want, sorry.)

You say that you want to differentiate eta just once. But with respect to which parameter of eta, the first or the second? That's what D[1](eta) and D[2](eta) do.

Or perhaps you mean once w.r.t each in turn? If so, consider D[1,2](eta) or D[2,1](eta).

Or are you thinking of some total differential? (It's hard to see what you want, sorry.)

The red X is excluded because it is displayed, and not returned, by that `print` call.

[`$`(X,20), cat(`#mn("`,X,`", mathcolor="red", fontweight="bold")`)]

The red X is excluded because it is displayed, and not returned, by that `print` call.

[`$`(X,20), cat(`#mn("`,X,`", mathcolor="red", fontweight="bold")`)]