@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.

@acer 

That is very instructive. I used complexplot3d for convenience but the plot3d with re and im is easier to understand and even shorter.

This link is unfortuneately not working Download plot3d_cplx.m

Thank you!

@Carl Love 

Some thoughts:

A simple flag could be implementend for each Maple input line this way: If Maple_input_has_changed AND Input_not_send_to_Maple_server then set flag=true.

(and: If_output_received then set flag=false)

This would be an improvement but will fail in the following screnario:

A user opens a document and changes one input line at the end of the document, because the input refers to equation numbers and no entiere execution of the document is required to generate "correct". The user oversees that also names are used in the input that have been assigned to a value. After exceution of the input line the new output will show the name but not its value.Then the user saves the document with "wrong" output.

To adress this, Maple's GUI must somehow be capable to analyse the input for situations where execution of a single line will potentially give an output that is different from the execution of the whole document and at least inform the user. I am not sure if this is easily possible.

In any case, the benefit of whatever implementation must be weighed against the effort and that is a product management decision rather than a developers choice.

@Carl Love 

I compared to subs but forgot the eval...

eval(subs(int = 1, expr))

All clear now.

Thanks

@Carl Love 

Does the help page of eval describes this special syntax?

@dharr 

With plottools/rotate also equatorial poles should be possible. Below is an assembled sphere with plots/display animated with plots/display. I can test a few things with it.

Thank you