Did you forget to first issue with(plots) or to call it as plots:-implicitplot3d ?

Did you forget to first issue with(plots) or to call it as plots:-implicitplot3d ?

The first is really

LinearAlgebra:-Modular:-Create(127,n,n,'random',('integer')[]);

That is just one Library function call. And it can get straight to an external compiled C routine. Due to the size of the integer 127, that external routine can know that it can operate in hardware types of small length. So, super efficient.

In contrast, the second call is really

LinearAlgebra:-Modular:-Mod(127,LinearAlgebra:-RandomMatrix(n),integer);

That is two Library function calls. The first creates a Matrix. The second has to create an entirely new Matrix by applying mod operations to the first Matrix. It also likely walks the first Matrix to discover the type and size of the entries, just to figure out whether it can apply mod using hardware integer calls. And, once finished, the first inner Matrix becomes garbage to get collected, which is another expense. So, not so efficient.

By the way, it may be useful to also examine why the recursive solution in itself is not an efficient technique. In Maple's own (Advanced, or Introductory?) Programming Manual, there is a discussion of techniques to compute Fibonacci numbers. The recursive method looks slick, but is not more efficient. It adds lots of memory use. It adds lots of Library function calls. Those create unnecessary expense in your example too. But, with large Matrix objects there is another concern. Notice that the code I wrote would have to produce an invalid, singular Matrix before calling itself. That invalid Matrix cannot be collected as garbage (I believe) until it's no longer referenced at its particular call-level or until control returns from that level. This happens again with each level of recursion, potentially resulting in a lot of allocated objects that cannot yet get collected. So recursive programming with lots of temporary Matrix/Array objects can produce an undesirable bulge in memory allocation. The intermediate objects cannot get collected until the control reverts (with final result returned, say).

The first is really

LinearAlgebra:-Modular:-Create(127,n,n,'random',('integer')[]);

That is just one Library function call. And it can get straight to an external compiled C routine. Due to the size of the integer 127, that external routine can know that it can operate in hardware types of small length. So, super efficient.

In contrast, the second call is really

LinearAlgebra:-Modular:-Mod(127,LinearAlgebra:-RandomMatrix(n),integer);

That is two Library function calls. The first creates a Matrix. The second has to create an entirely new Matrix by applying mod operations to the first Matrix. It also likely walks the first Matrix to discover the type and size of the entries, just to figure out whether it can apply mod using hardware integer calls. And, once finished, the first inner Matrix becomes garbage to get collected, which is another expense. So, not so efficient.

By the way, it may be useful to also examine why the recursive solution in itself is not an efficient technique. In Maple's own (Advanced, or Introductory?) Programming Manual, there is a discussion of techniques to compute Fibonacci numbers. The recursive method looks slick, but is not more efficient. It adds lots of memory use. It adds lots of Library function calls. Those create unnecessary expense in your example too. But, with large Matrix objects there is another concern. Notice that the code I wrote would have to produce an invalid, singular Matrix before calling itself. That invalid Matrix cannot be collected as garbage (I believe) until it's no longer referenced at its particular call-level or until control returns from that level. This happens again with each level of recursion, potentially resulting in a lot of allocated objects that cannot yet get collected. So recursive programming with lots of temporary Matrix/Array objects can produce an undesirable bulge in memory allocation. The intermediate objects cannot get collected until the control reverts (with final result returned, say).

The reason that I wrote that particular proc was because it seemed to fit the snippets of code that had been posted. I figured that the OP was trying to develop and understand basic syntax and a particular technique. Trying to convey top efficiency seemed too lofty an immediate goal. Addressing the directly present issues seemed more germane.

The reason that I wrote that particular proc was because it seemed to fit the snippets of code that had been posted. I figured that the OP was trying to develop and understand basic syntax and a particular technique. Trying to convey top efficiency seemed too lofty an immediate goal. Addressing the directly present issues seemed more germane.

How does the debugger work alongside Threads? I suppose that Threads:-Self can be used. Are there different effects when using the Task model than using just Threads? Does it show in the callstack results from the the 'list' command inside the debugger? Do all other Threads get blocked from entering any proc in the callstack of the Thread being currently debugged? Is there any risk of switching Thread unintentionally while "inside" the debugger? Is there any way to force/attempt a Thread switch while inside?

The whole point is to show us how s is created. That means all the code, including the commands to form s. That means any Spline calls. And calls to with(CurveFitting) or with(VectorCalculus), etc. All of it.

The whole point is to show us how s is created. That means all the code, including the commands to form s. That means any Spline calls. And calls to with(CurveFitting) or with(VectorCalculus), etc. All of it.

In 2D Math mode, you can use the key-bindings for command-completion in the typed input to get from typed varpi to the symbol.

On Linux, the command-completion keystrokes in Maple's Standard GUI are Ctl-Shift-spacebar. I'm not sure about MS-Windows.

So, you could type

varpi<Ctl>-<Shift>-<spacebar>

note: someone mentioned that not all palette entries are available in Worksheet mode. That's not quite correct terminology. They are not all available in "1D Maple input" mode. In a Worksheet, you can toggle between 2D Math and 1D Maple input modes  (F5 key on Linux).

In 2D Math mode, you can use the key-bindings for command-completion in the typed input to get from typed varpi to the symbol.

On Linux, the command-completion keystrokes in Maple's Standard GUI are Ctl-Shift-spacebar. I'm not sure about MS-Windows.

So, you could type

varpi<Ctl>-<Shift>-<spacebar>

note: someone mentioned that not all palette entries are available in Worksheet mode. That's not quite correct terminology. They are not all available in "1D Maple input" mode. In a Worksheet, you can toggle between 2D Math and 1D Maple input modes  (F5 key on Linux).

The downloadable pdf document for that application brief says, "Using proprietary software, we could use the values defined by the covariance matrices in V1 and W1 to calculate the Kalman filter gain Kf ." And then it shows a printed Matrix Kf, with values. And that is key to the definition of the linear quadratic Gaussian controller.

How was Kf computed?

Also, that pdf document seems to produced from a Maple Document. It says, "The state space matrices (A, B, C, and D) used to define the LQG controller can be found by expanding the following code edit region." The cited URL has no downloadable .mw file. Is MapleSim necessary, to view code embedded in the .msim model file?

How can the code in that referenced code-edit region be viewed?

Do other application briefs have downloadable pdf files with references to code-edit regions but no accompanying downloadable .mw Document?

The downloadable pdf document for that application brief says, "Using proprietary software, we could use the values defined by the covariance matrices in V1 and W1 to calculate the Kalman filter gain Kf ." And then it shows a printed Matrix Kf, with values. And that is key to the definition of the linear quadratic Gaussian controller.

How was Kf computed?

Also, that pdf document seems to produced from a Maple Document. It says, "The state space matrices (A, B, C, and D) used to define the LQG controller can be found by expanding the following code edit region." The cited URL has no downloadable .mw file. Is MapleSim necessary, to view code embedded in the .msim model file?

How can the code in that referenced code-edit region be viewed?

Do other application briefs have downloadable pdf files with references to code-edit regions but no accompanying downloadable .mw Document?

So, what were the results of Doug's visit? Was it productive?

Since Maximize promises only local maxima for multivariate problems, you may have to guard against false negatives. If it returns a positive max, then you're done. But if it returns a nonpositive max then you might have to fall back to verify (or is).