I think a new integer subtype is needed: integer greater than one, gtoint.

isgto := proc(x::anything)
  local X;
  X:=x;
  return type(X,integer) and (X>1);
end:

AddType(gtoint,z->not isgto(z));

Major deficiency in Physics[Vectors]; Distinct sets of basis vectors are not recognized!

You can't define vectors in alternative bases like: {\hat{i}',\hat{j}',\hat{k}'} or {\hat{i}_{1},\hat{j}_{2},\hat{k}_{3}}.

This deficiency has been around for a while. I have found other posts regarding this problem.

The deficiency greatly reduces the allowable calculations with Physics[Vector].

Are there any plans to fix this?

Here is my example which shows this deficiency in more detail.

physics_vectors_and_multiple_unit_vectors.mw
 

Download physics_vectors_and_multiple_unit_vectors.mw

This post is about the visualization of a gyroscopic phenomenon of a rotating body. MapleSim models and a description for those who do not have MapleSim are provided for their own analysis. Implementation with other tools like Maple might give further insight into the phenomenon.

With appropriate initial conditions, a ball thrown into a tube can pop out of the tube. This can be reproduced with a MapleSim model

Throwing_a_ball_into_a_tube_A.msim

To hit a perfect shot without trial and error, time reversal was applied for the model (reversed calculation results of a ball exiting the tube are used as initial conditions for the shot). This worked straight away and shows that this model is sufficiently conservative.

This phenomenon has recently attracted attention on YouTube. For example, Steve Mold demonstrates the effect and provides an intuitive explanation which he considers incomplete because the resulting vertical oscillation of the ball does not match theory and his experiments. He suspects that the assumption of a constant axis of rotation of the ball is responsible for this discrepancy.

However, he cannot demonstrate a change of the axis of rotation. In general, the visualization of the rotation axis of a ball is difficult to achieve in an experiment. On the contrary, visualization is much easier in a simulation experiment with this model:

Throwing_a_ball_into_a_tube_B.msim

The following can be observed for a trajectroy that does not exit the tube:

At the apex (the top) of the trajectory, the vector of rotation (red bold in the following images) points downwards and is essentially parallel to the axis of the cylinder. The graph to the left shows the vertical (in green) position and one horizontal position (in red). The model applies gravity in negative y direction.

On the way down, the axis of rotation points away from the direction of travel (the ball orbits counterclockwise in the top view).

At the bottom, the vector of rotation points towards the axis of the cylinder.

On the way up, the axis of rotation points in the direction of travel.

These observations confirm that the assumption of a constant axis of rotation is too simplified. Effectively the ball performs a precession movement know from gyroscopes. More specifically, the precession movement of the rotation axis rotates in the opposite direction of the rotation of the ball.

However, the knowledge and the visualization of this precession movement do not provide more insight for a better intuitive explanation of the effect. As the ball acts like a gyroscope, a second attempt is to visualize forces that perturb the motion of the ball. Besides gravity, there are contact forces exerted by the tube. The normal force at the contact as well as the gravitational force cannot generate a perturbing momentum since they point to the center of the ball. Only frictional forces at the contact can cause a perturbing momentum.

Contrary to the visualization of the axis of rotation, visualization of contact forces is not straight forward in MapleSim, because neither the contact point nor the contact forces are directly provided by components of the MapleSim library. Only for a single contact point, a work-around is possible by measuring the reactive forces on the tube and then displaying these forces in a moving reference frame at the contact point. The location and the orientation of this frame are calculated with built-in mathematical components. To illustrate the additional effort, the image below highlights in yellow the components only needed for the visualization of the above images, all other components were required to visualize the contact forces and frictional moments.

Throwing_a_ball_into_a_tube_C3.msim
It required many attempts to get to a working model. Several kinematic models for a rotating reference frame at the contact point failed. Finally, mathematical operations on kinematic signals (measured by sensors) and motion drivers were successful.  

In the following, the model is used to visualize the right-hand rule for the following vectors:

• in green the disturbing frictional moment
• in red (now with a double headed arrow) the angular velocity (for a sphere it points in the same direction as the vector of the angular momentum and the axis of rotation)
• in pink the vector of the angular velocity of the precession movement

At the top, the vector of precession indicates that the axis of rotation is diverted away from the direction of travel (i.e. pointing backwards). This is in line with the above image of the ball “on the way down”.

At the bottom, the vector of precession indicates also that the axis of rotation is diverted away from the direction of travel. This however cannot be seen in the above image of the ball “on the way up”. This discrepancy is an indication that the vector of angular velocity of the precession movement might not sufficiently predict the future orientation of the axis of rotation.

Overall, there is little symmetry in the two extreme positions at the top and at the bottom. A bending of the trajectory downwards (pitching down) at the top indicated by the vector of precession, cannot be seen at the bottom: The vector of precession does not indicate a bending of the trajectory in an upward direction.

It turns out that the right-hand rule does not provide the hoped-for better explanation either. However, the model was not a complete waste of time since it provided two unexpected and very counterintuitive observations:

• At the bottom, the speed of the balls center is the lowest. For an object descending in a gravitational field, one would expect a gain in speed. A closer look at the graph of the angular velocity (lower graph) reveals that the ball is spinning at the highest rate at the bottom. This means that potential and kinetic energy at the top are converted to rotational energy at the bottom.
• Although the ball slows down (and speeds up in angular velocity) while descending there is no frictional force component in circumferential direction. Seen from above, the ball orbits at constant velocity. Only a vertical frictional force component acts all the time. Frictional forces in circumferential direction slowing down the ball can only be seen at the beginning of the simulation when the ball slips on the tube up to the moment when it rolls without slippage.

Overall, the closer one looks, the less intuitive it gets. What makes this phenomenon so difficult to understand is the constantly changing constraint of the ball. At each time increment the location and orientation of the contact changes with respect to the direction of the (instantaneous) direction of precession. This makes the phenomenon so obscure. It might be easier to find an “intuitive” explanation for the tennis racket paradox (or intermediate axis theorem) where no external forces act.

Even with a physics background and the right-hand rule of precession at hand, it requires allot of imagination to predict the movement of the ball. This is, in my opinion, not intuitive at all for most people. After all, the premotor cortex of the human brain seems to have constant difficulties to learn precession – for sure precession prediction is not hardwired. If it was, the paradox wasn’t so perplexing, and we could imagine/predict what the golf ball does next.

In summary, this simulation experiment revealed details not known before (at least to me) about the phenomenon. The experiment did not provide more insight for a better intuitive explanation but on the contrary raised more questions. It is another case of “knowing more, but not getting smarter”.

At the very least, the simulations also show the benefits of carrying out virtual experiments under various conditions that are difficult or even impossible in an experiment. In any case, such experiments are of educational value  - not only in classical physics.

Comments on the product:

It was possible to verify results of MapleSim: The model reproduces the magic numbers sqrt(7/2) and sqrt(5/2) for the ratios of circular rotation and vertical oscillation frequencies for a full and a hollow sphere respectively. See the first model.

The (laborious) work-around presented here cannot be applied to most real-world contact problems. Visualization of the contact point, contact forces and contact slippage are therefore a desirable extension to MapleSim’s contact capabilities. I do not think that this is provided by other tools.

A surface pattern for the ball would have been helpful to better visualize the rotation of the ball.

A moving observer view (in this case an observer in the reference frame of the contact) could facilitate observation.

Further viewing:

• The physical engine of Blender was used in a video to reproduce the phenomenon qualitatively.
• There is an ”improved” intuitive explanation of Steve Mold’s explanation which uses frictional forces and provides physical background. It is not clear to me which part of the visualization is animated and which is physically simulated. At least some sequences do not make sense: The vector of the external frictional moment on the ball suddenly changes direction. The “improved” intuitive explanation also states that the rotational axis leans constantly toward the contact point. I do not see this in my simulation (the contact point is indicated with a red dot in the images above). Also, the precession vectors in my simulation did not reveal an intuitive explanation for a reduction in vertical oscillation frequency.

Further work:

• Is the vertical oscillation truly sinusoidal as the horizontals are?
• Is the point of contact always in the northern hemisphere of the ball? More general: In one hemisphere?
• In a simulation without gravity: Does the vector of precession better predict the trajectory?
• ...
   

I’m thrilled to introduce the updated Q&A Cards Creator! Michael Barnett had created the original Flash Cards Creator, inspired by the quiz creators in the Maple Learn gallery. I added some of the features (mentioned later in this post) that will help you use this tool to make more comprehensive quizzes. Students can use the creator to quiz themselves before a test, and instructors can integrate more practice quizzes into their lesson plans. One feature I particularly love is the ability to link full solutions to the back of each card, allowing users to understand the answers in depth (as shown in this document). Additionally, you can link a general solutions package (as seen here) if individual solutions aren’t necessary for each question. Below is an example of what the Q&A cards can look like from the users point of view.
This creator is a great example of the Maple Learn documents you can create through scripting in Maple. With a single script, you can create an infinite amount of content and quizzes. If you are interested in Maple scripting, here is a link to the Q&A cards script. If this script looks intimidating, feel free to check out this blog post on the basics of Maple scripting!


If you are interested in creating your own Q&A quiz, you can go to this document to get started. If you get stuck at any point creating your card set, check out the instructions included in the document for clarification. We hope you enjoy creating some quizzes with this document!

We have just released an update to Maple. Maple 2024.1 includes improvements to the math engine, PDF export, the Physics package, command completion, and more. As always, we recommend that all Maple 2024 users install this update. In particular, please note that this update includes fixes to ODESteps and simplifying integrals, as reported on Maple Primes. Thanks for helping us, and other users, by letting us know!

At the same time, we have also released an update to MapleSim. MapleSim 2024.1.1 includes improvements to FMU import/export, plotting, co-simulation, and more, as well as enhancements to the Web Handling Library.

These updates are available through Tools>Check for Updates in Maple or MapleSim, and are also available from the Download Product Updates section of our web site, where you can find more details.

It can happen when an operation is interrupted by  that Maple does not return to  and still shows .

This can give the false impression that the Maple server in charge of the evaluation did not get the message to stop whatever it was doing.

By giving Maple an impossible task to solve analytically

f1 := x1 - x1*sin(x1 + 5*x2) - x2*cos(5*x1 - x2);
f2 := x2 - x2*sin(5*x1 - 3*x2) + x1*cos(3*x1 + 5*x2);
solve({f1, f2});

I have noticed in the Windows Task Manager that freeing allocated memory can take much longer than one might think.

In one case it took 30 minutes to free 24 Gb of total allocated memory (21 Gb of it in RAM/physical memory). In this case the interrupt button became active (turned from grey to red ) two times and memory continued piling up  again.

Lessons learned for me:

• The task manager is not only a valuable indicator for task activity but also for the interruption/memory freeing process.
• Before killing a whole Maple session and potentially losing the last state of a worksheet it can pay off to wait and repeatedly interrupt an operation.

Suggestion: When the maple server gets an interrupt request, it could report to the GUI that it is in an interruption state and is no longer evaluating input. For example changing the message in the status bar from Evaluating... to Interrupting...

The original app center was excellent, they were .. "finessed" so to speak.  Then they changed it (like so many websites today most are clunky and they're all terrible, they don't work well, and I'm not just singling out maplesoft)  Most websites that are finely tuned are most likely based on old school programming, just recall the old days of mapleprimes - the forum was nicely done - but that's a debate for later. Now to the nitty gritty.

I did a search at maplesoft app center of a particular author, and I know he has at least 20 applications.  Only 3 came up, and the last app entry said more apps by this author but it kept disappearing and I kept getting thrown back to application #1 all the meanwhile looking like I'm scrolling further down in the list. 

Maybe this is browser issue?  I'm using firefox.  Maybe Microsoft Edge works better? 

Plots of physical quantities has significantly improved with Maple 2022. The updated useunits option makes unit conversion errors in plots very unlikely. A lot of time is saved when creating plots of physical quantities where values and units must be correct.

One final source of user errors remains: The manual entry of incorrect units in labels.

Below is a way to avoid such errors by computing labels with units for three prevalent axis labeling schemes.

Other desireable labels are given as a suggestion for future plot label enhancements where plot commands could provide formating functionality.

The rendering on this website adds double brakets ⟦ ⟧ wherever units are used. You have to open the document to see how Maple renders.

Simple plot example: Solar irradiance in space (1) (2) This plot has inconsistent axis labeling: •  The vertical axis has units but no name •  The horizontal axis has a name and units but they are not easily distinguishable. Misinterpretation is possible. Due to the close spacing the label could be read as a product of the dimension "time squared" (the time t times hours h is of the dimension time squared). Or the reader confounds name and units. (The use of italic fonts for names and roman fonts for units might not be noticeable and is a convention that is not used everywhere.)   The above labeling should be improved for communication, documentation or publication purposes.   A quick attempt using strings and the options useuints and labels. Axes are now consistent and can be interpreted unambiguously. Formatting can still be improved.   Unfortunately, using the options useunits (for unit conversion) and labels this way introduces a new source of user error when labels are entered with the wrong units.   A way to address this and to ensure unit error-free plotting of expressions of physical quantities is the following:   Step1: Define two lists, one for the units to display and the other for the names to display (3) Step2: Compute labels from the lists This step avoids the labeling error: No manual entry of units in labels required. (4)   Dimensionless labels  Double brackets Parenthesis The axis values equal physical quantities divided by their units. The algebraic equation , for example, is physically speaking correct. Most functions of Maple can process dimensionless expression of the kind  if G is given with appropriate physical units. This way of using physical quantities is consistent with ISO 80000.   Used in Maple to enter units in 2D-Math input mode Can be confounded with functional notation. Units are therefore often written as a whole word (e.g. seconds instead of s).     The time to produce the above three plots was about 10 Minutes. The most part was spent to get the typesetting of the second and third plot correct.   What takes significant more time (more a question of hours when Typesetting is used for the first time) are   Labels with or  formatting.   This formatting might be preferred but is unfortunately again not free from user errors. (I would probably use it if there was a simple and safe way). (5)       Remarks •  For two reasons, I have not given an example with the often used square brackets [ ] because:          Maple uses square brackets already for lists and indexing purposes,     and ISO 80000 uses square brackets as an operator that extracts the unit from a physical quantity (e.g.       ). •  Adding a unit to each value at axes ticks would definitely be a nice labeling feature for simple units. •  Programmatically analyzing the units defined in list  above and converting them in a generic way to a typesetting structure is not possible with a few high-level commands.   •  For inline quotients like in , an additional backslash must be entered in 2D-Math: \/   (6)      This will not prevent evaluation to a normal quotient but the input can be used to create an atomic variable (select with mouse -> 2-D Math -> Atomic Variable) (7)      This makes labeling much easier as compared to typesetting commands (compare to the above statements). (8) In any case it is a good idea to read ?plot,typesetting before experimenting with typesetting.

Axes_with_unit_labels.mw

My personal preference is for dimensionless labels.

Note:

The solution to avoid labeling errors works only for Maple 2022 and higher.

Some plot commands do not support plotting with units, or they do not fully support it yet.

I was playing around with plotting volumes of revolution for calculus.  My opinion is that the defaults for Student[Calculus1][VolumeOfRevolution] could be improved by a couple simple changes.  My hope is that the people here can make my plots better to give Maplesoft a good idea of how to change the defaults.  

The standard code and output are

Download Volum_rev_2023_trial1.mw

Changing the surface style to patch and the surfce colors to different colors creates a plot that I find easier to interpret.

Download Volum_rev_2023_trial2.mw

What do you think about getting the defaults changed?  I hope someone can give better suggestions for the plot defaults.

Perhaps you could consider a Coding theory Package.  I'm working on Coding theory at the moment.

Maple introduced "Copy as LaTeX" a few versions ago and I have used this feature exensively when it suddenly stopped working.

After som experiments I found the root cause and easy (but irritating) workaround for OSX

Problem:

"Copy as LaTeX" suddenly stops working ("Copy as MathML" still works fine)

Cause:

This problem appears if in “Display Setting”-tab in settings dialogue the “Input display” is set to “Maple Notation”

In that case all attempts on “Copy as LaTeX” will be a null-function and not move anything at all into the copy buffer.

The “Copy as MathML” is not affected by this in the same way.

I have confirmed this on OSX in Maple versions 2022, 2023, and 2024

Workaround:

Adjusting “Display Setting”-tab in settings dialogue so that the “Input display” is set to “2-D Math” and “Apply Globally” makes it work again.

A bit annoying as a prefer the maple notation input and I cannot have this setting if I want the copy to latex to work.

Note:

in OSX this can also be fixed by removing the Maple preferences file and letting Maple restore it.

~/Library/Preferences/Maple/2023/Maple Preferences

Edit: Added 2024 as affected version.

I have been working in the building construction industry for more than 30 years, and one of the big things which has been coming up is parametric design.

While every major big software company has come up with its own package (Bentley with Generative Components, Autodesk with Dynamo), there is one software now that has won over all them - Grasshopper 3D.

Nowadays all major software products are trying to write bidirectional links to Grasshopper. Inhouse we do have Tekla on the BIM side and FEM-Design on the calculation side where both are capable to link to Grasshopper.

Grasshopper itself is also capable of running Python code, though in a reduced kind of way.

I would very much like to see Maple to have a Grasshopper link, probably achievable through Python.

At least Maplesoft should have a quick look at it, to see if this is possible or not.

MapleFlow is showing the exact same icon in the taskbar as Maple when both are open.  Be nice if they were slightly different.

Maple 2023: The colorbar option for contour plots does not work when used with the Explore command. See the example below.

No_colorbar_when_exploring_contour_plots.mw
 

The inverse problem of a mathematical question is often very interesting.

I'm glad to see that Maple 2023 has added several new graph operations. The GraphTheory[ConormalProduct], GraphTheory[LexicographicProduct], GraphTheory[ModularProduct] and GraphTheory[StrongProduct] commands were introduced in Maple 2023.

In fact, we often encounter their inverse problems in graph theory as well. Fortunately, most of them can find corresponding algorithms, but the implementation of these algorithms is almost nonexistent.

I once asked a question involving the inverse operation of the lexicographic product.

• https://www.mapleprimes.com/questions/235863-An-Inverse-Problem-Of-Lexicographic

Today, I will introduce the inverse operation of line graph operations. (In fact, I am trying to approach these problems with a unified perspective.)

To obtain the line graph of a graph is easy, but what about the reverse? That is to say, to test whether the graph is a line graph. Moreover, if a graph  g is the line graph of some other graph h, can we find h? (Maybe not unique. **Whitney isomorphism theorem tells us that if the line graphs of two connected graphs are isomorphic, then the underlying graphs are isomorphic, except in the case of the triangle graph K_3 and the claw K_{1,3}, which have isomorphic line graphs but are not themselves isomorphic.)

Wikipedia tells us that there are two approaches, one of which is to check if the graph contains any of the nine forbidden induced subgraphs. 

Beineke's forbidden-subgraph characterization:  A graph is a line graph if and only if it does not contain one of these nine graphs as an induced subgraph.

This approach can always be implemented, but it may not be very fast. Another approach is to use the linear time algorithms mentioned in the following article. 

• Roussopoulos, N. D. (1973), "A max {m,n} algorithm for determining the graph H from its line graph G", Information Processing Letters, 2 (4): 108–112, doi:10.1016/0020-0190(73)90029-X, MR 0424435

Or: 

•   Lehot, Philippe G. H. (1974), "An optimal algorithm to detect a line graph and output its root graph", Journal of the ACM, 21 (4): 569–575, doi:10.1145/321850.321853, MR 0347690, S2CID 15036484.

SageMath can do that: 

   root_graph()

Return the root graph corresponding to the given graph.

    is_line_graph()

Check whether a graph is a line graph.

For example, K_{2,2,2,2} is not the line graph of any graph.

K2222 = graphs.CompleteMultipartiteGraph([2, 2, 2, 2])
C=K2222.is_line_graph(certificate=True)[1]
C.show() # Containing the ninth forbidden induced subgraph.

Another Sage example for showing that the complement of the Petersen graph is the line graph of K_5.

P = graphs.PetersenGraph()
C = P.complement()
sage.graphs.line_graph.root_graph(C, verbose=False)

(Graph on 5 vertices, {0: (0, 1), 1: (2, 3), 2: (0, 4), 3: (1, 3), 4: (2, 4), 5: (3, 4), 6: (1, 4), 7: (1, 2), 8: (0, 2), 9: (0, 3)})

Following this line of thought, can Maple gradually implement the inverse operations of some standard graph operations? 

Here are some examples:

•   CartesianProduct
•   TensorProduct
•   ConormalProduct
•   LexicographicProduct
•   ModularProduct
•   StrongProduct
•   LineGraph
•  GraphPower