Joe Riel

7637 Reputation

20 Badges

13 years, 298 days

MaplePrimes Activity


These are answers submitted by Joe Riel

Can you give an example?  If it is a differential equation you might be able to use DynamicSystem:-Linearize.

There are several things wrong with your usage:

  1. S, L, and B are not parameters, they are variables.  In the equations they should appear as S(t), etc. The use of ODETools[declare] might avoid that, but makes specifying the initial conditions more difficult.
  2. gamma has special meaning in Maple; use another variable (I used g)
  3. initial conditions must be equations, not inequalities

I may have forgotten another.  Here is a corrected version

init_conds := S(0) = 0, L(0) = 0, B(0) = 0;
sys := {init_conds
        , diff(B(t), t) = L(t)*g-g*mu
        , diff(L(t), t) = L(t)*S(t)*beta-(g+mu)*S(t)
        , diff(S(t), t) = -L(t)*S(t)*beta-`μS`+mu
       };
sol := dsolve(sys, 'numeric', 'parameters' = [mu, `μS`,beta, g], 'method = rkf45');

First, it is usually better to upload your worksheet (use the green arrow), that makes it much easier for us to try what you've done.

You can create an Array with elements from -5 to 5: 

n := 5:
U := Array(-n .. n, -n .. n):

You are executing convert(U, Matrix). By itself that returns a Matrix, however, it does not affect U, which remains an Array. That is fine, since a Maple Matrix always has indices that start at 1.

The pathname you show is almost certainly wrong in that backslashes (is this a Windows server?) need to be escaped in a Maple string. For  your example, the appropriate string would be "\\drivename\\filename.txt".  Using single forward slashes (Unix path separators) will generally work.

Part of the problem is that either computation is so fast it will be hard to see a difference. The other part is that your algorithm won't create separate tasks, you've done the entire computation in one thread. It looks to me like you are computing the sum of an integral for parameters in an array. A better way to write that would be the following, which allows computing each integral in a separate thread.

L1 := 10:
f := x ->evalf(Int(sin(beta)/(100 + ZZ*sin(beta) - x*cos(beta))^(5/2), beta = 0 .. 1, ZZ = 0 .. L1, 'epsilon' = 0.01, method = _cuhre)):

# Create a large array of parameters 
xx := Array(RandomTools:-Generate(list(float(range=0..98),10000))):
# Perform the computations and compare the times
CodeTools:-Usage(add(f(x), x=xx));
CodeTools:-Usage(Threads:-Add(f(x), x=xx));

With that, I get a real time speed up of about 2x

Yes, the model incorporates back-emf.  The K constant is used to compute the back emf from the rotational velocity, as well as the torque from the current. The device equations are shown in the help page.

However, you shouldn't believe me---it's better to test the model yourself.  Do it the same way as you'd measure the back-emf in an actual motor:  turn the shaft and measure the open-circuit voltage.

@Earl The form you gave is a discrete event with a conditional trigger.  Discrete events occur during event iteration, which only occurs when there are discrete variables.  Event iteration is initiated by a continuous trigger.

Here's a brute force attempt to solve this. To make it checkable, I generalized the problem to an n-sided die, with markings from 1 to n. To make the run-time reasonable, the procedure Check, which checks whether all the digits have occurred, is compiled. For n = 5 it runs in about 1 minute. I haven't tried it with n=6, but expect it to take quite a while. The print statement prints the length of the current run that is being tested, that is there to give a relative feedback on progress.

Straight := module()
    
export
    ModuleApply := proc(n :: posint)
    local C, N, R, T, cnt, len;
        
        C := Array(1..n, 'datatype' = integer[4]);
        
        for len from n do
            print(len);
            N := n^len;
            R := Iterator:-MixedRadixTuples([n $ len]);
            cnt := 0;
            for T in R do
                C[] := 0;
                if Check(T,C,len,n) then
                    cnt := cnt+1;
                end if
            end do;
            if cnt/N >= 1/2 then
                return len;
            end if;
        end do;
    end proc;

export    
    Check := proc(T :: Array, C :: Array, len :: posint, n :: posint)
    option autocompile;
    local k;
        for k to len do
            C[T[k]+1] := 1;
        end do;
        for k to n do
            if C[k] = 0 then
                return false;
            end if;
        end do;
        return true;
    end proc;

end module:

Straight(5);

While it presumably won't help here as the suggested solutions are efficient and avoid set building altogether, since Maple 2016 there is an object, MutableSet, that has efficient methods for manipulating sets in Maple.

Use profiling.  There are exports in CodeTools:-Profiling that will help, but I generally use the low level commands.  For example

foo := proc(n::posint)
local i;
   # inefficient way to build a sequence
   s := NULL; 
   for i to n do
       s := s,i;
   end do;
   s;
end proc:
# set up profiling on foo
debugopts('traceproc' = foo):
# execute the procedure
foo(100):
# display the results
printf("%s\n", debugopts('procdump'=foo)):
foo := proc(n::posint)
local i, s;
     |Calls Seconds  Words|
PROC |    1   0.000   5447|
   1 |    1   0.000      0| s := NULL;
   2 |    1   0.000      0| for i to n do
   3 |  100   0.000   5447|     s := s, i
                            end do;
   4 |    1   0.000      0| s

That example wasn't particularly enlightening, but try it on your own procedure. Depending on what your procedure does, you might want to set debugopts('tracerealtime'=true) first, it causes the profiler to measure the actual elapsed time, versus the time taken in the Maple kernel.

The call to evalf is outside your loop.  When the loop exits, i is assigned 9 (1 more than the to value).

Here's an alternative view.  I put as little code as practical in the embedded component, typically a call to a procedure, possibly with an argument that identifies the embedded component.  The functionality is contained in the procedure, an export of a module. As an example, a button may contain 

  _App:-btnLoadSystem();

while the startup region may contain

  _App := SomePackage:

where SomePackage is the name of a module that is saved in a Maple archive (mla). An advantage of this approach is that it's a lot easier to maintain the code. This may be overkill for your usage. A hybrid approach would be to insert the Maple code that defines the module into the startup region.

Followup The OP asked for an example. Here it is: DoubtOnLatestCodesinEmbeddedPlotAlt.mw. I modified his original to use a package assigned in the startup region, and included a call to with so that the package exports, used by the sliders, can be accessed without referring to the package name.  While I don't always use with, one advantage to doing so is that the code in the embedded components is then, essentially, inert and error-free until the package is assigned.  Otherwise, if MyApp:-ChangeA() was inserted as the code for the A slider, any time the slider was clicked an error would be raised (and raised repeatedly, making it a pain to fix) stating that MyApp was not a module.

For complicated applications, using a single procedure call in an embedded component has a lot of practical advantages.  One of them is that it facilitates debugging.  For example, in the worksheet you can add and execute the line

stopat(ChangeA):

then, when you move the A slider, the Maple debugger will be launched and you can step through ChangeA and, if desired, its call to UpdatePlot.

This happens because V, the formal parameter to your switch procedure, is passed a mutable object.  In the body of the procedure, the assignment W := V makes W point to the same structure that V points to.  So any changes in the procedure to W affects V. To avoid that you could use copy, for example, W := copy(V).  If V itself contains mutable structures you might do W := copy(V, 'deep'), where the deep option tells copy to recursively copy its content.

 Here's a more general way to reverse the content of a 1D rtable.

Reverse := proc(a :: rtable
                , { inplace :: truefalse := false }
                , $
               )
local b,i;
    if not a :: 'rtable(1..)' then
        error "expecting one-dimensional rtable that starts at one";
    elif inplace then
        b := a;
    else
        b := copy(a);
    end if;
    for i to iquo(upperbound(a),2) do
        (b[i],b[-i]) := (a[-i],a[i]);
    end do;
    b;
end proc:

I'd generally encode that as follows. Note the use of the remember option; that makes the operation much more efficient as previous results are reused.

v := proc(a)
option remember;
    v(a-1) + 6*v(a-2);
end proc:

# Assign the initial values (this writes to v's remember table)
v(1) := 1:
v(2) := 2:

for k to 20 do
    printf("v(%d) = %d\n", k, v(k) );
end do:

There is no formal parameter for the second positional argument. The dsolve routine does its own parameter processing and uses _rest, etc., to access the undeclared parameters. This might be because dsolve has been around for a long time and existed in some form before a lot of improvements to Maple's parameter processing were implemented. In this case, though, I suspect it has more to do with the second argument being optional.  An alternative would be to declare the second argument and give it a special default value then check for that, however, that isn't any better and the older code did the equivalent in a slightly different manner.

Followup

I'd change this to an answer, rather than a reply, if I knew how (thanks whoever did so).  The real confusion you are seeing is that you are using _nparams, rather than nargs or _npassed (a synonym). The _nparams value is based on the number of declared (formal) parameters, not the number of passed arguments.

1 2 3 4 5 6 7 Last Page 1 of 100