Joe Riel

8121 Reputation

22 Badges

15 years, 57 days

MaplePrimes Activity


These are answers submitted by Joe Riel

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.

Restart the kernel.  In the GUI, click that restart button on the toolbar, or execute the restart command. That will cause the initialization file to be reexecuted.

One possible way to handle this is to use codegen:-optimize to generate a series of equations that produce the final expression. For example

 

tmp1 := subs(hypergeom=%hypergeom, expr): # make hypergeom inert
tmp2 := [`codegen/optimize/rtable`(tmp1,'resultname=M')]:
(eqs, defs) := selectremove(type,tmp2,specindex(M)=anything):
MM := Matrix(10,10, {seq(op([1,..],eq) = rhs(eq), eq = eqs)}):

At this point you would save the list of defs and MM to the external file.

Try Optimization:-Maximize, it quickly finds the local maximum in the region.

For this particular case you might be able to use LinearAlgebra:-IdentityMatrix(5). That won't work if you plan to later modify the Matrix.

That's a really old maplev version.  The current latest is, as John says, available at my GitHub site. A newer version will be uploaded in the near future. Note that I'm still using GNU Emacs 24.4.1, not 25. If you do have issues, please contact me directly. Thanks. 

Using the Iterator package one can do

# 2 0's and 3 1's
iter := Iterator:-Chase(2,3):
seq(p[], p=iter);
   [0, 0, 1, 1, 1], [1, 0, 0, 1, 1], [0, 1, 0, 1, 1], [0, 1, 1, 0, 1], 
   [1, 0, 1, 0, 1], [1, 1, 0, 0, 1], [1, 1, 1, 0, 0], [1, 1, 0, 1, 0], 
   [1, 0, 1, 1, 0], [0, 1, 1, 1, 0]
  
n := 8650368:
P := sort(map2(op,1,ifactors(n)[2]));
                 [2, 3, 2503]
sort(ifactor(n), ``~(P));
                 ``(2)^7*``(3)^3*``(2503)

Here's why

 eval((1/s^2)^N = s^(-2*N), [s=-1,N=1/2]);  
                                           1 = -1
First 9 10 11 12 13 14 15 Last Page 11 of 104