Joe Riel

7969 Reputation

22 Badges

14 years, 349 days

MaplePrimes Activity

These are answers submitted by Joe Riel

If you double-click the Probe Plots selection in the bottom left pane of the Simultion Results window, the plot will appear. I'm not sure why it isn't appearing automatically.


It appears as though the visibility of that plot is initially off.  Maybe it was accidentally toggled before the file was saved. Double-clicking toggles the visibility; you can also right-click to bring up a context menu.

You have a space or something between the first ::.  The following works

patt := x::symbol^n::symbol /  y::symbol^n::symbol: # verify this is parsed correctly
patmatch(x^n/y^n, patt, 'eqs');
       [n = n, x = x, y = y]

The result is, uhh, correct.  The condition a > b evaluates to 1 > 3 which is false, so the else clause is executed.

It seems to work here; moving the sliders updates the corresponding figure and adds data to the tables. 

A few comments.  There is no good reason to use with(DocumentTools) inside a use DocumentTools in ... end use; structure (that is done in the code for DataTable0). Putting a restart in embedded code has no effect; a restart is only available at the top level (that also exists in the code for DataTable0).

Further The code for the first slider is updating DataTable1, not DataTable0, which is the data table that is adjacent to it. So maybe that's your problem.

P operates on lists. To use it with map, the mapped structure should be a list of lists. So

map(P, [[A1, A2, A3, A4]], [B1, B2, B3, B4]);

frontend can be used here

y := -sin(alpha)*(sin(theta1)*cos(theta)-cos(theta1)*sin(theta)):
frontend(combine, [y], [{`+`,`*`},{theta,theta1}]); 
                        sin(alpha) sin(-theta1 + theta)

A better choice is to use add rather than sum.  Even better is to cache the results.  Consider

f1 := n->piecewise(n=0,1,n>=1,add(thisproc(k),k=0..n-1)):
f2 := proc( n :: nonnegint)
option cache;
local k;
    add(thisproc(k), k = 0..n-1);
end proc:
f2(0) := 1:  # Directly assign the value for n=1

n := 20:
memory used=0.53GiB, alloc change=32.00MiB, cpu time=9.94s, real time=9.94s, gc time=196.00ms
memory used=6.08KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns, gc time=0ns

The second version runs much faster.

Apologies for the belated reply.  The basic problem is that there are bugs in that version of CodeBuilder.  I've uploaded a new version to the MapleCloud (but not to the Maple Application Center).  With Maple 2017 you should be able to download it from the MapleCloud palette.  Alternatively, you can do execute the following statement, which should install it.


It's hard to be sure without knowing what the code is doing, but you can use a conditional to check for an empty solution from solve and then skip the rest of the loop.

for ... do
   sol := solve(...);
   if sol = NULL then
   end if;
end do;

You may have to modify the conditional (sol = NULL) to something appropriate for your usage of solve.

Your call expands to

map(`*`, 1/x, y, z);

which maps `*`, with additional arguments y and z, onto 1/x, which is equivalent to x^(-1). To better understand what happens, do

map(f, 1/x, a, b);

With current Maple you could just do

assign(op(op(Sol))): # this assigns a table to u.
U := Matrix(25, u):
plot([seq([i,U[i,20]], i=1..25)]);

No, that statement is generally true. When using a seq, add, or mul in a procedure, one should always declare the index as local to the procedure. Normally the value is not retained, however, because you are using an indexed name (which becomes a table reference when assigned to by the seq) values are being assigned to the table i. I'd avoid using an indexed name as the index variable.


To see that index in a seq is not local to the seq, do

seq(i, i=1..3);
Error, attempting to assign to `i` which is protected.  Try declaring `local i`; see ?protect for

does what you want.

Carl's solution is the standard way to handle this. If you need independent incrementers, one approach is to use a Maple object, which is an extension of a module.  A practical disadvantage to using an object is that the calling notation is a bit clunky, at least for something as simple as an incrementer. For example, rather than inc() to return the incremented value, one might have to call increment(inc).  To avoid that clunkiness, the following code overloads the unary Maple ! operator to act as the incrementer of the object. Overloading a unary + operator would be nicer, but that isn't possible (the unary - operator can be overloaded, but that seems backwards, though it would be useful for a decrement operation.).

Incrementer := module()
option object;

local cnt := 0;

    ModuleCopy :: static := proc(self :: Incrementer
                                 , proto :: Incrementer
        self:-cnt := 0;
    end proc;

    `!` :: static := proc(self :: Incrementer)
        self:-cnt := self:-cnt + 1;
    end proc;

end module:

The following is a typical usage

> cnt1 := Object(Incrementer):
> cnt2 := Object(Incrementer):
> cnt1!;

> cnt1!;

> cnt2!;

> cnt1!;

> cnt2!;

The curious reader may wonder why one cannot overload the unary + operator. The reason is that it doesn't really exist in Maple. The expression +x is handled by the Maple simplifier and converted to just x. One could overload the nary + operator by overloading the `+` function, but then the call to the incrementer would be `+`(cnt1), which is not so nice (at least from my perspective).

While the branch-and-bound routine that the TravelingSalesman procedure uses may be theoretically more efficient than a brute-force search, the implementation may not be.  The Iterator procedures were written to be fast, at least within the context of Maple procedures. Much of their speed comes from using a single Array as the data-structure (they also call, by default, a compiled routine, however, that generally only gives a speed-up of a few times).  Each iteration does not allocate more memory. Because your outer loop, which checks a selected path, was written efficiently, that is, also does not allocate additional memory, with the exception of replacing a better local solution [and note, that could be slightly improved by first allocating a vector for the best solution and then copying into it each time a local optimization is found], the entire method uses very little memory.  Contrast this with the TravelingSaleman approach (use CodeTools:-Usage to measure the memory usage). You'll find that quite a lot is being accessed and allocated.  The culprit appears to be the GraphTheory:-ReduceBound, which one can see is allocating a new Matrix with each call.  

Followup In this case, the minor improvement I suggested is inconsequential in that only 2 improvements are ever made.

First 7 8 9 10 11 12 13 Last Page 9 of 103