Joe Riel

7712 Reputation

22 Badges

14 years, 133 days

MaplePrimes Activity


These are answers submitted by Joe Riel

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:
CodeTools:-Usage(f1(n));
memory used=0.53GiB, alloc change=32.00MiB, cpu time=9.94s, real time=9.94s, gc time=196.00ms
                                                                                524288
CodeTools:-Usage(f2(n));
memory used=6.08KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns, gc time=0ns
                                                                                524288

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.

PackageTools:-Install(5723849212559360,'overwrite');

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
      next;
   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);
               f(x,a,b)^f(-1,a,b)

With current Maple you could just do

mul([1/x,y,z]);
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.

Followup 

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

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

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;

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

export
    `!` :: 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!;
                                                            1

> cnt1!;
                                                            2

> cnt2!;
                                                            1

> cnt1!;
                                                            3

> cnt2!;
                                                            2

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.

Use ifactors rather than ifactor.  It's consistent format is better suited for further processing.

str := "a := x+y;":
parse(str, 'statement');
              a := x + y
                x + y
a;
                x + y

Here's a somewhat different approach.

RtableToInverseMap := proc(R :: rtable)
local T, indx, v;
    T := table('sparse');
    for indx in indices(R) do
        v := R[op(indx)];
        T[v] := (T[v],indx);
    end do;
    eval(T);
end proc:

Given an rtable, it returns a table that provides an inverse map from a value to the indices in the rtable that contain that value. Each entry of the returned table is a sequence of the lists of indices that match, but the first element is always 0. If the entry in the table is exactly 0, then no entry in the rtable matched. This method isn't ideal; worst-case occurs when all elements of the rtable are identical.

Is C:\temp a directory?

Maple doesn't show a fraction over a fraction, so if you want that you'll have to enclose the numerator in the blank function (``):

K := lcoeff(denom(outOverin),s):
``(numer(outOverin)/K)/``(collect(denom(outOverin)/K,s,simplify));

Alternatively you can do

(numer(outOverin)/K)/(collect(denom(outOverin)/K,s,simplify));

The result is pretty close to what you want.

5 6 7 8 9 10 11 Last Page 7 of 100