@acer 

Sorry, I was too short. I only wanted to say that _Z in a RootOf expression (my first example) is only a placeholder that has not been assigned to anything whereas _Zxx from my second example comes with assumptions. Both are outputs of solve but completely different things. I unconsciously mixed them up switching between the two examples.  

_Z is of course a complex unkown. Now that you've said it. It makes sense not to change to something else. The RootOf help page would profit form this mention even if it is obvious for readers with a solid mathematical back ground.

@acer 

Studying your last reply, I just realised the double use of _Z... That clears up some open points! Can _Z be changed to _X?

restart;
solve(sin(x)/x, allsolutions);
about(_Z1);
solve(x^x = 1/sqrt(2), allsolutions);
about(_Z);
                        Pi (2 _Z1 + _B1)

Originally _Z1, renamed _Z1~:
  is assumed to be: integer


                          /     _Z    (1/2)\
                    RootOf\-2 _Z   + 2     /

_Z:
  nothing known about this object

@acer 

I want to query subexpressions of a special type but did not get there with the originally posted example. I understand now that this can be fixed by using indets@@2 only because _Z is the argument of ln. 

What I want finally to achieve: I would like to extract names of the kind _name~ or _name from solve output and replace it by something better readable (i for example) and then stating right to the ouput that i is element of N or Z. For example for

restart;
solve({tan(x)/x,x>0},allsolutions)[];
a:=indets(%);
whattype(a[1]);
whattype(_Z1~);# I cannot see an index in the output of solve

The goal would be to generate textbook style output like

I tought about using a type identifier on the output of indets that selects all _name~ or _name expressions and then generating subsitutions. Doing this by hand only works once. When new dummies are created the manual substitutions fail.

I have tried to identify the type of the dummies to use the returned type to filter out only dummies but if it is true that the dummies are of type symbol then this type is too unspecific. This is a bit off topic: Are there other identifiers that could work?

I still do not fully understand the meaning of index in "dummy index name".

Update:

I have found an identifier that works: indets(..., suffixed(_, symbol))

I think I also understand now the meaning of index. If I am not mistaken it is the number after _Z in _Zindex. It is not an indexed name (?indexed). The output of whattype(_Z12~) is still unclear. This is not explained ?type,indexed. Anyway

Thank you for your time!

@emendes 

I got the same remark about the download size from one of my colleagues who only needed to view a document but not to play it.

Viewing Maple documents on a wide screen is often better than viewing pdf with page breaks.

Have you tried to set the page to A3 or A2 and to landscape to make the table fit on one page? This could be an alternative if it is only for viewing on a screen.

Can you share an example of a worksheet that looks good?

@Rouben Rostamian  

Maybe you can share parameters of your animation. I have tried to reproduce the logarithmic (is it?) spiral of the OP with MapleSim but there is something wrong my interpretations of the worksheet (or the rotating ticks are fixed on the ground which would then mean that the spiral I get is a superposition of the logarithmic spiral and the rotation of the disc).

@Rouben Rostamian  

The example you posted here visualizes much better a tumbling motion than a monochrome polyhedron. 

I add it here because it seems to be a good test case for patterns. A very, very nice animation!

@dharr 

Our replys crossed.

I see. I was wondering why there is redundant syntax. int/numeric is more self explaining but evalf(Int(...)) makes more sense if the way Maple handles integrals is better understood. 

Units partially work as I had to learn here. For this reason I did not gave units a try on these integrals. So there might be annother reason (appart from looking for singularities) why Maple decides not to go straight to numerics. Intersting.

Whenever I get stuck with units I convert unit_free which worked so far good (values seem to be converted before units are removed). Unit integration is quite a task. I have to be patient and wait for future versions.

Udate:

Following your remark on the numeric option, I have removed dispensable evalf's

Complex_radiant_excitance_-_integer_vs_real_03.mw

@Nicole Sharp 

I agree that someone should have a look at it.

Part of the problem comes from the singularity at the origin that a lead Maple to apply analytic methods (altough explicitly asked to solve numerically) involving series that generated the complex term. Interestingly, Maple converts the real temperature to a rational expression which is only slightly different from the integer version but is subsequently treated differently leading to complex output.

The other part comes from int working most of the time but not always. If this is considered to be the root cause then (idealy and if possible) the user should get some hints to modify the input.

I have attached an overview of combinations that work and don't.

Complex_radiant_excitance_-_integer_vs_real_02.mw

@Scot Gould 

There is an identity that explicitly states -ln(1/c)<>ln( c)
 

-subs(y = -1, FunctionAdvisor(identities, ln(c))[5]);
subs(c = -1, %);
eval(%);
           /1\                       /Pi + argument(c)\
        -ln|-| = ln(c) - 2 I Pi floor|----------------|
           \c/                       \      2 Pi      /

                                      /Pi + argument(-1)\
       -ln(-1) = ln(-1) - 2 I Pi floor|-----------------|
                                      \      2 Pi       /

                         -I Pi = -I Pi

Therefore p__1<>p__2 and is(…) should not have returned true according to the assume help page.

However, p__1<>p__2 seems only to be the case if c is part of the branch cut of the ln function (i.e. the negative real axis).

is(-ln(1/c) = ln(c)) assuming 0 < Re(c);
                              true

Plotting with complexplot3d, as I did in my first answer, hides the branch cut. Plotting only the imaginary part reveals the discontinuity responsible for different outputs of p__1 and p__2 for a,b,c:= 1,1,-1  

It looks to me that is(...) assumes real for p__1=p__2 in Maple 2023 for whatever reasons.

An idea to finish:

Instead of assuming real in some cases, is(…) could internally test, before returning false or FAIL, if coulditbe returns true and then inform the user that under certain additional assumptions on the variables the proposition is satisfied.

coulditbe(-ln(1/c) = ln(c));
                              true

@acer 

I have overlooked this page. Thanks

Good to read that I am not the only one who wishes a printed one. I need this feature to format input parameters in technical documentation for non-Maple readers. If you need this as well you can find a way using inert function here.

For lists without a unit-without-value, evalf(list1) is an alternative to your procedure. So, is it really the 1 A you want to achieve or something else I overlooked.

There might be ways to use typesetting to reformat the output the way you want but that is beyond what is documented. Worth a question to typesetting experts if you do not get an answer here.

@acer 

I was looking for a 3d-effect. The orientation is a start value to easier rotate manually to orientations where the real axis runs from left to right.

Thank you for the colorsheme option. 

@Thomas Richard

The goal was to improve a quantitative interpreation of the color coding of complexplot3d. What I had initially in mid was a color bar with values. Since this is very tricky I thought about a simpler colorcoding which clearly distinguishes -Pi, 0 and Pi. Either with less colors (blending from red to blue for example) or with a discrete scale. The second idea comes with rendering artefacts which would require switching from a grid to a mesh of plotpoint that follows contourlines. Tricky as well. Maybe I should switch to a polar plots with a radial grid and abandon colorplot3d which I like for the simple reason that "all" is contained in one plot.

I will give plotcompare a try.
 

step:=12;
plot3d(argument(re+I*im), re=-2..2, im=-2..2,
       color=round(step*argument(re+I*im)/2/Pi)/step,
       style=surfacecontour, lightmodel=none,
       labels=[Re(z),Im(z),``], orientation = [-90, 0, 0],grid=[40,40]);

To my answer above I can add that the expressions you apply solve on have, depending on the parameters a,b,c, more than one solution. Solve cannot return all solutions.

p__1 and p__2 are therefore only solutions for one root and not necessarily identical (in the complex domain).

@Scot Gould 

Your parameter set describes roots on a unit circle

subs(c = -1, a = 1, b = 1, c = p^a*p^b);
solve(%);
                                  2
                            -1 = p 

                             -I, I

By conicidence the two solutions p_1 and p__2 prodcue the same roots as the polynom. With b=2 all would have been less mysterious. It took me a while to recognize this discrepancy between my answer and yours.