@jestrup 
Where do see the Non-Ececutable Math.
In the below example I could apply a command to it.

(This bug must be reported)

@Rouben Rostamian  

Very nice!!! It will be hard to beat that in terms of clarity and compactness. AI would probably have produced pages of pages of code with plenty of procedures for the same problem.

Worth noting, the parameter s is not necessarily the arclength. In the attached I tried



brain_damaged_lissajous.mw

No conversion works with the context pannel. I compare below to the former user interface.

@Gillee

Below is a screen shot of the GPU graph (from process explorer -> properties of the corresponding mserver.exe task) when excecuting the example from ?cuda.
At the blue line, a restart was pefrormed. The red arrow points to the excecution of

That is supposedly the matrix multiplication performed by the GPU. No increase of GPU usage is visible. Whatever the GPU does, only a fraction close to 0% of its modules are involved not in an efficient way.

I would contact support. Something is not working as intended.

@FDS_ERT 

I spend quite some time on it, but was not sure if that is worth the effort. Thank you for confirming.

@nm @acer @dharr

For the above testcase (and other codes) I have found a workaround on my installation: A first worksheet must be opened before the execution of code can be interrupted in a second worksheet.

The first worksheet can be a blank sheet or the start page. It is not required to enter code in the first worksheet sheet and run it before the code is executed in the second worksheet. It is even possible to close the first worksheet (after starting Maple) without any execution or entering code before a second worksheet is opened in which execution is interruptible.

Is that reproducible on other installations?

I also realized the following: The UI (jawa.exe) provides only one interrupt button that must connect to separate kernels (mserver.exe).

The communication to the first worksheet (magenta, worksheet automatically opened after startup) works apart from interrupting. Input can be entered and output is returned

The second worksheet (blue), is interruptible with the major difference that much less dlls are attributed to this task. Notably, no NVIDIA dlls are attributed to this task (and using the GPU including GPU memory).
Opening a third worksheet does not show any differences to the second worksheet (threads and dll are the same apart from the process ID of the mserver task).

Contrary to what I have feared before (“could be JAVA related”) I am now more inclined to say that the first worksheet is setup differently and MapleSoft should be in the position to fix the interrupt issue.

Edit: loaded NVIDIA dlls in yellow in the thread view before executing anything. (Thread 11284 is active all the time.)

@dharr 
I had a closer look at the interrupt button.

The tool tip pops up with a delay of about one second. The tool tip is displayed right to the tip of the mouse pointer. Left to the pointer there is a faction of the button accessible to interrupt. The tiny buttons do not make it easy to left-shift the mouse pointer to interrupt (one has to stay within the activated button).

@nm 
I was not clear.
Maple 2020 was developed under Oracle.

Maple 2021 under Eclipse

The change was visible on the UI which looked differently. Since then a few UI functions are not working temporaily after start-up from hibernation (palettes do not open). That is annoying and persist with the new UI. However, I think we a dealing here with something new.

@dharr

My current thinking is the following:

I do not think that we are facing performance trade-offs here, because polling the OS for "has this button been pushed" will not slow down computation as there are many more items on the screen that have to be checked frequently for changes. In this case the mouse button will generate an interrupt (click occured) and then the windows manager of the OS will determine if a windows element that can change its state has been at the mouse pointer position. To pass the states between an activated button (the windows element) and the applications the buttons belong to, the system uses handles. Handles can brake for several reasons which depend on system settings (graphics driver, internal or external graphics adapter, memory managment in general).

This worked with the old UI. My hypothesis is that the new UI uses other windows elements than before that do not function as robust as the old ones. Mouseover the interrupt button changes the grey tone of the button and the tool tip shows that the button is activated to receive a "click". However the click does not propagete to Maple in some situations. 
The use of Java complicates the situation because it is a layer between the application (Maple) and the system. Java is supposed to make the application hardware independent. In the worst case we a facing here an issue with the Java IDE (integrated development environement) that Maplesoft cannot fix. For years, since MapleSoft uses the Eclipse IDE, there are menu items that do not work all the time (context menus not opening, e.g. convert to; plot tab on ribbon not visible when a plot is selected, context panel not updating).

@vv 

My default is Maple 2025.2 for screen readers. Unfortunatley such screen reader versions (the old UI) are not shipped anymore with Maple 2026. 
I use Maple 2026 at the moment to check code for compatibilty and to see if AI has benefits. I also want to give the improved new UI second chance. However, if it comes to productive work, I still go back to the former UI. Less clicks, better flow.

I am strongly hoping for improvements.

@acer

If I had a say, fixing that would be priority one. Does the management understand that they are selling a car without reliable brakes for more than a year (if I understand correctly). Does the pride in the product end here?

Anyway, have you turned off the start-up page (as I did)? Maybe this makes a difference. No clue where this can be turned on again.

@Carl Love

Yes, you are right. With respect to functional programming this is probably the most compact code but I did not want to go too far away from the original question of adding a given list.

I only picked the add because it is selfexplaining and it links to `+` and to `%+` . It also does not require op

dabug's question is an intersting one because it touches many Maple aspects which might be (one day) of interest for a Maple starter:

• automatic simplification
• inert functions
• prefix n-ary operator `+` vs infix binary operator +
• The non-existance of Add (which I tried straight away, realising later that such an uppercase construct would create similar output as %add if it was implemented in-line with Maple's inert conventions).
• mathematical functions, Maple functions, operators, functional operators and function names

I also tired to find out whether `+` and add point to the same Maple prodecure. I do not think so because  `+`(L) - add(L) does not simplify to zero.

By the way: Maple AI crashes when asked to explain your code

This is great. It seems that by using terse functional forms we have a way to identify whether the code was written by a human. We can still create code that is alien to machines!

I made the same observation with the example from ?CUDA.

@janhardo 
That way is similar to this way. Both ways define a local intermediate variable that permits to point from passed names to passed values.  I will see which one is better to debug when it comes to coding.
Thank you

@Carl Love 

That is tricky. Defining a local name to have something to refer to local variables created during run time. 

To complete my list of attempts:

• conversion to string -> replacement of "=" with ":=" StringTools -> parse
• local evaln(lhs~params)~:=(rhs~params)
• replacing operators `=` with `:=` 

I think I finally know now why nothing worked.

Thank you very much!