The union is simple

with(plottools):
with(plots):
display([torus([1,1,1], 1, 2),torus([1,6,1], 1, 2)], scaling=constrained, lightmodel=light1, shading=zgrayscale,color=[red,red]);

but how to plot the intersection?

This happened on Windows 10 clicking on *.mws documents while Maple 2023 was not running.

My observations with one document (I do not have others at hand at the moment):

No freeze when Maple is already running.

No freeze when the startup page (Start.mw) is disabled.

Older versions opened in Windows file explorer with “right click and open with” did not show this behavior.

Since there are ways to open such old documents, my intention is to document my observations and to find out if others can reproduce it. If not, my setup might differ from default or the file has an issue.

Converting index expressions to atomic worked.
I then tried to uncheck atomic in the context menu which did not work.

I opened a new worksheet to try it again but now conversion to atomic disappeared from the menu

no_conv_to_atomic.mw

A restart of Maple did not bring convert to atomic back. Any idea why this happened and how to restore Maple?

My world of trigonometric functions has a very simple structure: sin, cos and tan are what I need.

That's why I very much welcomed the simplification of sin/cos to tan recently introduced with Maple 2023.

What I neither need nor want is the simplification of 1/sin and 1/cos to sec and csc. I'm not used to that (and probably won't get used to it).

Can this simplification to sec and ccs be turned off (and preferably the simplification to tan be kept)?

In the following example, the information in which range fsolve should search for a solution and the range in which a function is defined is somehow redundant. (This example has been adopted from here where fsolve without assumptions does not throw an error but evaluates forever.)

Why can’t fsolve not always assume that the range equals the domain of interest? This would make life easier and provide more solutions to inexperienced users who have not yet learned the need for assumptions.

If there are good reasons (and there probably are) that such an implicit assumption (i.e. range equals domain) would be too restrictive: can’t fsolve give a hint or provide an new option to use ranges as assumptions?

Download ranges_as_assumptions.mw