@acer 

I would be interested if this was done intentionally. Thank you!

@acer 
In the above have replaced x by alpha:  

x=0.08718861663 alpha=0.08718861663

This is the value for alpha that plot computes for the second plot point and used in the JacobiCN call.

a := RootOf(JacobiCN(sqrt(2)*sqrt(alpha), sqrt(2)*_Z/2)^2*_Z^2 + _Z^2 - 2):
subs(alpha=0.08718861663,a);
      /                                          2              \
      |        /              (1/2)  1  (1/2)   \    2     2    |
RootOf|JacobiCN|0.2952771861 2     , - 2      _Z|  _Z  + _Z  - 2|
      \        \                     2          /               /

Sorry again for not beeing clear.

@acer

Sorry, for beeing not clear.

Tracing your example,
plot(a, alpha=0..0.5, adaptive=false, numpoints=7)
I see that plot calls fsolve for the second plot point this way

fsolve(JacobiCN(0.2952771861*2^(1/2), 1/2*2^(1/2)*t)^2*t^2 + t^2 - 2);

where 0.2952771861=sqrt(alpha).
This squared

0.2952771861^2 <> 0.5/(7 - 1);
                 0.08718861663 <> 0.08333333333

does not match exactly the sampling I would have expected for numpoints=7 over the length of 0.5 (of the range).

@one man 

The animation runs with the changes.

INSCRIBED_SPHERES_CILL_FOR_-_2025.mw

@acer 

I now understand that fsolve returns two roots at alpha=0. With the following conversion I cannot reproduce the change of roots anymore

a := RootOf(JacobiCN(sqrt(2)*sqrt(alpha), sqrt(2)*_Z/2)^2*_Z^2 + _Z^2 - 2);

b := convert(a, Elliptic_related);
         
plot(b, alpha = 0 .. 0.5);

This might be because sn looks considerably different in the above range and no change of sign of D(f)(x) might occur.

plot3d(JacobiSN(sqrt(2)*sqrt(alpha), sqrt(2)*_Z/2), alpha = 0 .. 0.2952771861^2, _Z = -20 .. 20);

The problem occurs elsewhere (with an unexpected drop in magnitude that should not be there; but this is off-topic).

I have no more rootfinding questions but still cannot explain why numpoints comes up with x=0.08718861663 alpha=0.08718861663 for the second plot point.

@Christopher2222

Thank you! 
I agree. With all the great tools we have at hand today we get numerical accuracy for free which does not mean that the fidelity of the models require it. Education should emphasize on what a particular problem requires in terms of accuracy.

Not so long ago the slide rule was good enough to bring man to the moon ... and back.
In Maple parlance Digits:=4

@one man 
The output of Isolate is different. Any idea why?

@acer 

Thank you. This is very helpful.
Before asking I tried plot(...) assuming positive. I see from

trace(fsolve);# I thought fsolve is builtin and therefore not traceable
a := RootOf(JacobiCN(sqrt(2)*sqrt(alpha), sqrt(2)*_Z/2)^2*_Z^2 + _Z^2 - 2);
(plot(b, alpha = 0 .. 0.5, adaptive = false, numpoints = 7) assuming positive);

that assuming has no effect on the calls to fsolve.
What I still do not understand is the second call to fsolve that returns a negative value whereas the first call returns a sequence (last element positive) and the third call to fsolve returns a positve value.
Even outside the plot call I see this pattern.

untrace(fsolve);
fsolve(sol^2 - 1);
fsolve(JacobiCN(0.2952771861*2^(1/2), 1/2*2^(1/2)*t)^2*t^2 + t^2 - 2);
fsolve(JacobiCN(0.4037956981*2^(1/2), 1/2*2^(1/2)*t)^2*t^2 + t^2 - 2);
                        -1.000000000, 1.

                          -1.042514994

                          1.077400841

Comparing this with

allvalues(RootOf(JacobiCN(0*2^(1/2), 1/2*2^(1/2)*t)^2*t^2 + t^2 - 2));
allvalues(RootOf(JacobiCN(0.2952771861*2^(1/2), 1/2*2^(1/2)*t)^2*t^2 + t^2 - 2));
allvalues(RootOf(JacobiCN(0.4037956981*2^(1/2), 1/2*2^(1/2)*t)^2*t^2 + t^2 - 2));
                             1, -1

                   1.042514994, -1.042514994

                   1.077400841, -1.077400841

gives a consistent ordering.

Increasing the plot range and the grid point proportionally

plot(a, alpha = 0 .. 0.5*30, adaptive = false, numpoints = 7*30)

shows the same negative value for the second plot point.
What makes the value of 0.2952771861 special that fsolve returns a negative value? Maybe it is cn that can get close to 1.

plot3d(JacobiCN(sqrt(2)*sqrt(alpha), sqrt(2)*_Z/2), alpha = 0 .. 0.2952771861^2, _Z = -20 .. 20)

 P.S.: there is something else that I cannot explain about the sampling of the seond point

0.2952771861^2 <> 0.5/(7 - 1);
                 0.08718861663 <> 0.08333333333

The animation is not working with Maple 2024 and 2025. That's what I get. Former versions work well

@Terry 

https://www.mapleprimes.com/posts/222314-Who-Says-Maple-Doesnt-Have-Dark-Mode-

This has been asked often. Can you clarify to which user interface you refer. The new Maple 2025 interface is considerably darker. Is it still too bright for you (appart for the canvas which has not changed)?

Have you tried to cut down on blue color content in your monitor settings? Some monitors allow for a low blue or night mode.

The Screen Reader worked for me on Windows 10 four month ago. Then I had to update to Windows 11.

Your problem seems to be related to the access to the file system. I would be surprised if the numbers of monitors play a role. You could check by disconnecting one of them.

Maybe (and that is a pure guess) this remedy also related to file system operations

https://www.mapleprimes.com/questions/242045-Are-These-Hyperlink-Crashes-With-Maple

could work for you as well.

@Samir Khan 

The installation of the redistribution did not work. It was interrupted when it searched the network for an MSI file. Subsequently, the installation programme was unable to delete the previous version of the redistribution .
I cancelled the installation, whereupon Windows informed me that the system had to be restarted in order to repair the installation.

This must have worked. The hyperlinks now function as expected.

Thank you!

@one man 
The mechanism was not driven with constant angular velocity. I gave it an initial kick.

Rotating the input link uniformly would require to exert an varring torque on the mechanism. In this video it looks like that two shafts are driven with elliptic gear drives to keep the momentum on the motor constant.

@one man 

Unfortunately, I did not see your last replies from 2023 and 2025. They show that you were as dissatisfied as I was that we could not find a better agreement. In the meantime I could identify the true root cause which I mentioned here. 

The prismatic joint that I introduced is not equivalent to you deformations. I should have added elasticity to some joints or the supports for a better agreement.
By the way, good hearing from you!