Very nice. You say "ln(-1) = -i*Pi (by using the standard branch)", but Maple's convention gives ln(-1) = I*Pi.

I am using Windows 11 with latest updates and Maple 2026.1. I can successfully interrupt multiple times in two open worksheets.

However, like @acer, I frequently find I cannot interrupt running calculations except by exiting the running tab and choosing to save (or not).

A frustrating feature is that when I go to the stop button, sometimes the tool tip pops up to tell me the button is to "interrupt the current operation" and that blocks me from pushing the button.

There may be some tradeoff between performance and the ability to interrupt, so perhaps the answer is not so clear cut.

@Ronan Interesting. I didn't follow it all. I added (unnormalized) quadrance to my worksheet above, but I'm not certain whether or not this is a normalized quantity - you seem to have deliberately normalized it in your code. The projective quadrance (taking two vectors as arguments) certainly seems to be independent of vector scaling.

@one man Thanks - there is a more specific Wikipedia page on the automatic differentiation here, incuding using dual numbers. Not sure what Maple has along those lines.

What do you mean by a "dual number"? An example of what you want would be helpful.

@Ronan Not much use, since it is not as "natural" as a determinant. Has some combinatorial uses, such as the dimer covering problem: How many ways for dominoes to cover a chessboard (each domino covering two squares)?

@Rouben Rostamian  I take session-dependent to mean it can be different the next time I run the worksheet, but is consistent throughout a session, so would not change during a line of code.

@C_R @acer 

Interesting discussion. As you note, facility with Maple enters into that - short code that is easily understood by a Maple expert can just be cryptic for a beginner. There is also a tradeoff between "shorter and simpler" and more rigorous (in the sense that all input cases are covered). So the use case is important.

In responding to Mapleprimes questions or for my own use in the middle of a worksheet, I usually use procedure parameter type checks, but just to cover the common cases and not fully rigorous, in order to keep it simple (readable). As an educator, I've found that students are usually looking for a simpler answer than I think, and will ask for more depth if they want more. On Mapleprimes there is always the hope that they learn something useful, which is less likely with complicated code. But for a more experienced questioner, my answer will have less simple/more rigorous code.

For my own worksheets, if a procedure becomes more complicated, I usually relegate it to the startup code region so it doesn't interrupt the worksheet flow. But if I am going to put it there "out of mind" and forget its details, I'll usually do more argument checking. Often, say with a graph theory procedure, the argument checking can be a significant fraction of the procedure code.

In the present case, inbaseunits could be relegated to startup code, then I think the result is "simpler" in some sense. I put the argument checking partly so I didn't have to think too much outside the use case, such as what is wanted for x + 3*Unit(kg)? Also I reluctantly added the numeric type check since in this context Nr = 20 is supposed to pass, but really is that in base units? Once I realised that if a non-SI unit system is in use it doesn't work, I changed the name but didn't add any code, not so much to keep it simple, but because @C_R could recognize if something went wrong because of that and modify accordingly.

I would always put the evalb in, because then the procedure is self-contained, but I agree it is less readable, especially to a Maple novice.

I also gave some thought to if simplify and convert(..,unit_free) might, for some complicated expressions with many units, lead to numerical round-off errors that would make the two sides not equal. One solution is not to check the numerical part but to somehow check the unit part for base units. So here is my non-readable, non-simple version that recklessly uses an undocumented feature, which operates on the units part and checks for SI. (And avoids evalb.)

inbaseSI := p::{numeric, with_unit(numeric)} -> 
p::numeric 
or
  subsindets(attributes(Units:-Split(p)[2])[1],
             specfunc(Units:-UnitStruct),
             q -> if op(3, q) <> "SI" then undefined
                  elif op(2, q) = "gram" and op(1, q) = 1000 then 1
                  else op(1, q)
                  end if)
  = 1;

You ask "Why is a list returned>", but you are operating on a list, so that is not surprisng to me.
You ask "What happened to the units?". Units:-Split produces a sequence, say "2, Units(mm)" so you are doing simplify(2, Units(mm)) and simplify ignores the second argument.

You first solution seems reasonable to me. I'm a bit mystified as to why you want to do this. Since simplify puts everything into base units, just put the numbers into your integral or whatever and simplify before converting to unit_free.

Joe's user profile has disappeared. Not sure what that means, if anything.

@C_R Well I generally have low expectations of 2D, and for the finer aesthetics I usually don't care. The form converted to 2D seems to be functioning correctly even if it looks strange.

Generally if you have a pre-existing expression defined earlier, then you should use MakeFunction rather than the arrow operator to avoid confusion between local and global variables. But the arrow operator should be good for a one-line expression entered as you used. There is something more subtle here with Units that I don't understand.

@C_R If you put

mm := 5;
Unit(mm);

you get Unit(5), so generally speaking you do need the uneval quotes. But you don't need them inside the piecewise within the procedure definition; you can just omit them.  My answer was working under the assumption you wanted them there; if not then just leave them out as you found.

@C_R The weights are chosen so that exact solutions would be obtained for solutions that were polynomial in the space "x" coordinate of degree up to n-1. This gives you freedom to choose the x node locations. (I assume this is what you mean by elastic; that's new terminology for me.) (The method of lines uses finite differences in the x direction instead; neither of them are FEM) Of course intuitively you will do better if they are more closely spaced near where the solution is changing most rapidly. Just as in regular integration, you can do better if you choose the node locations optimally (gaussian quadrature) - then you get agreement to polynomials with twice the degree. 

The following paper doi: 10.1016/0098-1354(89)85051-3 has a nice discussion of some of the tradeoffs. Of course anything can be improved but at some point someone (or at least for me) becomes too involved in the numerical method development rather than the problem solving; and there are often good routines existing out there.

@Aliocha So it seems you are interested in the definite integral? Mariusz's answer can be modified to show the definite integral is n*Pi. I used simplify(...,symbolic), which isn't optimum. There are probably some series of smaller simplifications/conversions with assumptions that might get there instead of simplify/symbolic.

Download definite_integral.mw

@Rouben Rostamian  This runs identically in 2026.1