acer

32373 Reputation

29 Badges

19 years, 334 days
Ontario, Canada

Social Networks and Content at Maplesoft.com

MaplePrimes Activity


These are answers submitted by acer

You could also re-use your existing code, with a caveat:
It's not clear what you want to happen at the transition. I'm not sure whether you want either, none, or both of the animations to show at t=0. You could change the total number of frames to the odd number 141, say, to get either at t=0 (depending on a strict vs nonstrict inequality). You could also modify the `if` (nesting it, say) to display both at t=0, though I'd guess you might not want that.

(I'm supposing that you would not want to merge two separate animations which both had a t=0 frame.)

restart

DBG> quit

r1 := .35; m := 626; g := -9.807; u0 := -20; v0 := -20; x0 := 0; z0 := 15
omega0 := -24
J := (2/5)*m*r1^2

"vx(t):=t*2+15:"

"vz(t):=t*2+15:"

x1 := int(vx(t), t)

z1 := int(vz(t), t)

eqx1 := m*(diff(u(t), t)) = 0.; eqz1 := m*(diff(v(t), t)) = m*g

eqx0 := diff(x(t), t) = u(t); eqz0 := diff(z(t), t) = v(t)

eqr1 := J*(diff(omega(t), t)) = 5000*sin(t)

with(plots)

ini := x(0) = x0, u(0) = u0, z(0) = z0, v(0) = v0, omega(0) = omega0

sol1 := dsolve({eqr1, eqx0, eqx1, eqz0, eqz1, ini}, {omega(t), u(t), v(t), x(t), z(t)}, type = numeric, output = listprocedure)

p1 := odeplot(sol1, [[x(t), z(t)]], 0 .. 1, color = black, linestyle = dot)

t from 0 to 1

 

F1 := proc (tau) local pos, rot, j, cols; cols := [red, blue, red, blue]; if type(tau, numeric) then pos := [(eval(x(t), sol1))(tau), (eval(z(t), sol1))(tau)]; rot := (eval(omega(t), sol1))(tau); return plottools:-rotate(plots:-display([seq(plottools:-sector(pos, 1, (1/2)*(j-1)*Pi .. (1/2)*j*Pi, color = cols[j]), j = 1 .. 4)]), rot, pos) else return 'thisproc(tau)' end if end proc

x1 := animate(display, [F1(t), scaling = constrained], t = -1 .. 1, frames = 70)

t from -1 to 0

 

F2 := proc (tau) local pos, rot, j, cols; cols := [green, blue, green, blue]; if type(tau, numeric) then pos := [(eval(x(t)+1, sol1))(tau), (eval(z(t)+1, sol1))(tau)]; rot := (eval(omega(t), sol1))(tau); return plottools:-rotate(plots:-display([seq(plottools:-sector(pos, 1, (1/2)*(j-1)*Pi .. (1/2)*j*Pi, color = cols[j]), j = 1 .. 4)]), rot, pos) else return 'thisproc(tau)' end if end proc

x2 := animate(display, [F2(t), scaling = constrained], t = -1 .. 1, frames = 70)

animate(display, [`if`(t < 0, F2(t), F1(t)), scaling = constrained], t = -1 .. 1, frames = 140)

NULL

Download how_transition_ac.mw

The reason that it works in the procedure is that inside the procedure the (local) name x has been assigned using the set X, ie. lhs~(X). Once you get back to the top-level, outside your procedure, the global name x lacks that value.

Your subsequent top-level replacement could also be accomplished as (simpler, IMO),

    subsindets([dd], suffixed(x), ee -> ee(t))

I think that using globals is awkward, when not necessary. I prefer to use multiple return values, and have the substituted expressions be an additional return value. This would be my preferred approach.  elementwise_equal_ac.mw

Try this, for purely numeric integration:

evalf(Int(abs(1/(x - 2) + 0.5333 + 0.3333*x + 0.1333*x^2), x = -1 .. 1));

                         0.06041415825

By simplifying the integrand (which here sees that x>-1, x<1) before doing the symbolic integration the issue can be avoided.

value(simplify(Int(abs(1/(x - 2) + 0.5333 + 0.3333*x + 0.1333*x^2), x = -1 .. 1)));

                     0.06041419887

That symbolic integration of the simplified inert definite integral happens to produce a correct result and avoid the underlying symbolic problem, but I suggest you not rely on that technique, especially if you are willing to accept a solution with floats. Instead, I'd suggest you try to rely on the first approach I gave of performing purely numeric quadrature.

The following manipulation obtains the same erroneous negative result, and illustrates how it can go awry by, say, failing to split piecewise at every sign change in the integrand. (I used Maple 2022.2).

restart;
int(abs(1/(x - 2) + 0.5333 + 0.3333*x + 0.1333*x^2), x = -1 .. 1);

-0.5685437800e-1

restart;
Int(subsindets(convert(convert(abs(1/(x - 2) + 0.5333 + 0.3333*x + 0.1333*x^2),
                               rational,exact),Heaviside,x),specfunc(Heaviside),
               u->convert(u,piecewise)), x=-1..1);
H:=simplify(%);
value(%);
evalf(%);

Int(-1/(x-2)-5333/10000-(3333/10000)*x-(1333/10000)*x^2+2*piecewise(x <= 2, 0, 2 < x, 1)/(x-2)+(5333/5000)*piecewise(x <= 2, 0, 2 < x, 1)+(3333/5000)*piecewise(x <= 2, 0, 2 < x, 1)*x+(1333/5000)*piecewise(x <= 2, 0, 2 < x, 1)*x^2, x = -1 .. 1)

-(1/10000)*(Int((1333*x^3+667*x^2-1333*x-666)/(x-2), x = -1 .. 1))

-4333/3750+ln(3)

-0.56854378e-1

Download int_neg_ex0.mw

If you plot the integrand in H you can see that it has the wrong sign, for some values.

I will submit a bug report. [edit] It may already be fixed in the version under deveopment.

One way is to use an anonymous procedure.

If the operation involves a command that passes extra arguments at the end then your particular implementation of `&/` allows a terser solution.

restart;

 

`&/`:=()->args[-1](args[1],args[2..-2]):

 

0.76 &/ (u->convert(u,fraction))

19/25

0.76 &/ (fraction,convert)

19/25

(a*x+x*b) &/ simplify &/ (u->subs(a=2,b=3,u))

5*x

(a*x+x*b) &/ simplify &/ (u->eval(u,[a=2,b=3]))

5*x

(a*x+x*b) &/ simplify &/ ([a=2,b=3],eval)

5*x

Download infix_fun.mw

1) You could change the initial creation of A to,

   A := Matrix(11,11);

and then do your loop.

2) Or you could get rid of the loop altogether and create it as,

   A := Matrix(11,11,(i,j)->i+j-2);

3) Or you could just change the entry assigning line to,

   A(i,j) := i+j;

It happens because A2 is a Matrix, a mutable data structure.

The assignment inside your procedure makes A1 a reference to A. And Matrix A2 is not copied when it is passed in as an argument to the procedure call, so A is a reference to A2.

So your updates to entries of A1 are updates to entries of A, and thus are actually updates to entries of A2. This is part of something that is sometimes called in-place semantics.

If you don't want that behaviour then you can use copy semantics instead, by replacing the line that assigns to A1 as,

   A1 := copy(A);

Changing just that aspect of your example,

restart

diagonalize := proc (A) local A1; A1 := copy(A); A1(1, 1) := 0; A1(2, 2) := 0; A1(3, 3) := 0; return A1 end proc

A2 := Matrix([[-3, -.1, -.2], [.1, 7, -.3], [.3, -.2, 10]])

diagonalize(A2)

Matrix(%id = 36893628348005758484)

A2

Matrix(%id = 36893628348005757404)

Download d_ac.mw

In-place semantics allow for reduced memory use, by not creating a copy unless necessary. This can be a useful and convenient default for mutable data structures; it can gain efficiency for large examples that do not require the copy (because, say, they might not need the original data preserved).

@zenterix How about using ExportMatrix to export purely numeric data to files? You could compare the timing by using (or not) binary (Matlab) file formats supported by that command.

If there are headers (containing nonnumeric data) for the rows or columns then you could save those separately. For large amounts of float data I suspect that it'd be more efficienct to export/re-import without headers (datatype=float[8], say), as Matrix or Array (not DataFrame or anything fancy).

You could generate the filenames in the parent process, and pass one into each Grid process.

Here's how your stated target can be found using collect, as well as some alternative metrics.

I also show an alternative result, which scores better than your proposed target on all four metrics shown.

restart;

L := ee->[length(ee),`simplify/size/size`(ee),
          MmaTranslator:-Mma:-LeafCount(ee), codegen[':-cost'](ee)]:

 

expr := G1*P3 + G1*P5 + G1*P6 + G2*P3 + G2*P6 + G3*P2 + G3*P5 + G4*P2 + G4*P3 + G4*P5 + G4*P6 + G5*P2 + G5*P3 + G5*P5 + G5*P6 + G6*P3 + G6*P6 + G7*P2 + G7*P5 + G8*P2 + G8*P3 + G8*P5 + G8*P6;

G1*P3+G1*P5+G1*P6+G2*P3+G2*P6+G3*P2+G3*P5+G4*P2+G4*P3+G4*P5+G4*P6+G5*P2+G5*P3+G5*P5+G5*P6+G6*P3+G6*P6+G7*P2+G7*P5+G8*P2+G8*P3+G8*P5+G8*P6

L(expr);

[323, 138, 70, 22*additions+23*multiplications]

thaw(simplify(collect(expr,indets(expr,suffixed(P)),freeze)));

(P3+P6)*(G1+G2+G4+G5+G6+G8)+(G3+G4+G5+G7+G8)*P2+(G1+G3+G4+G5+G7+G8)*P5

L(%);

[134, 82, 29, 17*additions+3*multiplications]

thaw(simplify(collect(expr,[G1, P2, P5],freeze@simplify)));

(P2+P5)*(G3+G4+G5+G7+G8)+(P3+P5+P6)*G1+(P3+P6)*(G2+G4+G5+G6+G8)

L(%);

[123, 71, 27, 14*additions+3*multiplications]

Download crush_ex0b.mw

@zenterix 

If you keep/create your packages in the following pattern then the lib subdirectories get added to libname automatically upon relaunch.

  $(HOME)/maple/toolbox/mypackage/

where the .mla for that package is put in a subdirectory named lib.

You can also put the source under that directory.

And so all the source, along with the .mla, can be under that mypackage directory.

And similarly for mypackage2, mypackage3, etc.

In new Maple sessions the kernel will pick up the lib subdirectories for all such, and add them to libname.

The key here is putting them under this special location: whatever this returns,

  cat(kernelopts(homedir),"/maple/toolbox");

This approach removes the need to use any initialization file. Thus any tricky editing of an initialization file is wholly unnecessary.

And it lets you keep each package's source and .mla under its own directory. (Which you wanted, for github.)

The value of libname gets further augmented (in subsequent sessions) simply by adding another package in another such directory tree.

Side-note: You can also programatically create a self-installing file which unpacks any or all of .mla, .help, source, and build-scripts to the equivalent directory on someone else's machine. (This knows where to place these toolbox files regardless of operating system: Linux, MS-Windows, or OSX.)

This is the scheme Maple uses for its own add-on toolboxes. Why reinvent the wheel?

As documented on the procedure Help page, within a procedure a reference to a local gets only single level evaluation.

In contrast a declared global gets fully evaluated.

Here are a few notes:

restart;

gen := () -> 4.5:

p := proc()

  global g;
  local a,b,c;

  g := b;
  c := b;

  b := a;

  a := 'gen()';

  print( a, b, c, g );

end proc:


Inside the procedure p,
   a gets single level evaluation, obtaining its value,
      which is the unevaluated function call gen().
   b gets single level evaluation, obtaining just `a`
   c gets single level evaluation, obtaining just  `b`
   g gets fully evaluated, obtaining 4.5

p();

gen(), a, b, 4.5

restart;

gen := () -> 4.5:

g := b:
c := b:

b := a:

a := 'gen()':


At the top-level (ie. outside any procedure), these all
get fully evaluated.

a, b, c, g;

4.5, 4.5, 4.5, 4.5

The following mimics the kinds of evaluation that
occured within the call to procedure p. Compare
with the result above of calling p().

eval(a,1), eval(b,1), eval(c,1), g;

gen(), a, b, 4.5

Even at the top-level we can control the level of
evaluation, or perform full evaluation as usual.

eval(g,1), eval(g,2), eval(g,3), g;

b, a, gen(), 4.5

eval(c,1), eval(c,2), eval(c,3), c;

b, a, gen(), 4.5

Here's a tip for top-level programming:
Suppose we want to test whether sol gets assigned a
solution, or whether fsolve has returned unevaluated,
(since no solution is found).

sol := fsolve({x+y=0, sin(x)+sin(y)=3}, {x,y});

fsolve({x+y = 0, sin(x)+sin(y) = 3}, {x, y})

The following appears reasonable, but in fact this
top-level reference to sol induces a full evaluation of sol.
This makes fsolve get needlessly called again, which
is inefficient.

if op(0,sol) = fsolve then
  print("it returned unevaluated");
end if;

"it returned unevaluated"

The following gets the same test, but doesn't make
fsolve get called again. (You could trace(fsolve), or
run in the debugger, to see that this is so.)

if op(0,eval(sol,1)) = fsolve then
  print("it returned unevaluated");
end if;

"it returned unevaluated"

In contrast, the following code -- within a
procedure, with sol declared local -- makes
only the initial call to fsolve. There is no repeated,
(inefficient) attempt by fsolve during the if...then
test since the local named sol gets only single level
evaluation.

restart;
##trace(fsolve):
h := proc()
  local sol;
  sol := fsolve({x+y=0, sin(x)+sin(y)=3}, {x,y});
  if op(0,sol) = fsolve then
     print("it returned unevaluated");
   end if;
end proc:

h();

"it returned unevaluated"

 

Download local_eval_notes.mw

The problem is caused by the algorithm behind the (new to Maple 2022) default adaptive=geometric option.

You can get around this by supplying the option adaptive=true (or its shorter equivalent, merely the keyword option name, adaptive).

(I have submitted a bug report against this example.)

plots:-setoptions(size = [500, 300])

f := x -> arcsin(2*x/(1 + x^2))

proc (x) options operator, arrow; arcsin(2*x/(1+x^2)) end proc

plot(f(x), x, view = [-10 .. 10, -10 .. 10], adaptive = true)

plot(f(x), x, view = [-10 .. 10, -10 .. 10], adaptive)

Your original attempt:

plot(f(x), x, view = [-10 .. 10, -10 .. 10])

The same as what you got:

plot(f(x), x, view = [-10 .. 10, -10 .. 10], adaptive = geometric)

Download arcsin_ac1.mw

Yes, providing a .mla file (Maple Library Archive) and a .help file (Maple Help database) is a relatively common way to share one's data/procedues/modules/help-worksheets with other people.

It's up to you whether you also wish to provide the source code for your procedures/modules, or any special script that might read such into a session.

I suggest that you keep the .mla archive libirary files all in one common directory, and use the subdirectory structure for the various source files.

As for how to manage the subdirectories, I sometimes do it as follows:

I have my various packages' module (parent) definition files in a common location, eg.
    src/pack1.mpl
    src/pack2.mpl

The src/pack1.mpl file looks like this,

pack1 := module()
   export f1,f2;
   local f3;
$include "../pack1/src/f1.mm"
$include "../pack1/src/f2.mm"
$include "../pack1/src/f3.mm"
   end module;

And similarly for the src/pack2.mpl file.

All in all, I get the following

   lib/pack1.mla
   lib/pack2.mla
   src/pack1.mpl       # module defn
   src/pack2.mpl       # module defn
   pack1/src/f1.mm   # module member, eg. proc defn or submodule defn
   pack1/src/f2.mm   # proc defn
   pack2/src/g1.mm   # proc defn
   pack2/src/g1.mm   # proc defn

This way I only have to have that single top "src" directory in the include-path. The other files are picked up when I read either of the two parent .mpl files because I used relative names in the $include directives. I don't ever have to concern myself with "searching" for parent source files, or adding multiple locations to the include path.

And I only have a single location added to libname.

(Eventually I move the .mla files over to a ($HOME)/maple/toolbox subdirectory  on my machine, so that libname gets augmented automagically.  I seldom bundle them up as a package redistributable via the Maple Cloud or someone else's Maple GUI, but if I did I would never use a Maple workbook as the only copy of my sources.)

[edit] You might wonder why I bother at all with having the files in a "src" subdirectory. It's because I also have "doc" and "tst" subdirectories at those same levels, for documention&notes and for unit test files.

You can alter various aspects of this, to suit your taste.

plot(0, sample=[$1..10], adaptive=false, color=blue,
     style=point, symbolsize=25, symbol=solidcircle,
     axis[1]=[tickmarks=[$1..10], color=black],
     axis[2]=[tickmarks=[], color=white],
     view=[0..10,default], size=[600,75]);
 

Download 1d_numberline.mw

It's not the only way to get such an effect.

If you already have some existing, computed list of points (which does not simply include all the naturals up to some number), then the above code can be adjusted to get a few alternate appearances. [Thanks, dharr, for referencing this case.]

For example,

pts := [1, 3, 5, 9]:

plot(0, sample=pts, adaptive=false, color=blue,
     style=point, symbolsize=25, symbol=solidcircle,
     axis[1]=[tickmarks=[$1..10], color=black],
     axis[2]=[tickmarks=[], color=white],
     view=[0..10,default], size=[600,75]);
 

plot(0, sample=pts, adaptive=false, color=blue,
     style=point, symbolsize=25, symbol=solidcircle,
     axis[1]=[tickmarks=pts, color=black],
     axis[2]=[tickmarks=[], color=white],
     view=[0..10,default], size=[600,75]);

Download 1d_numberline2.mw

Your syntax for creation of Arrays for A and B is faulty. Your code creates them as lists, not Arrays.

Also the approach of using of a loop to repeatedly augment a list is inefficient. And you ended up with name t being assigned a numeric value, which then makes using the F formula awkward.

Here is one (of several) ways get it:

restart;

with(SignalProcessing):with(plots):

omega:=10*2*Pi:

F:=add(n/5*cos(n*omega*t),n=1..5);

(1/5)*cos(20*Pi*t)+(2/5)*cos(40*Pi*t)+(3/5)*cos(60*Pi*t)+(4/5)*cos(80*Pi*t)+cos(100*Pi*t)

X:=0.01;Y:=0.5

0.1e-1

.5

A:=Array([seq(0..Y,X)]);

A := Array(1..51, {(1) = 0, (2) = 0.1e-1, (3) = 0.2e-1, (4) = 0.3e-1, (5) = 0.4e-1, (6) = 0.5e-1, (7) = 0.6e-1, (8) = 0.7e-1, (9) = 0.8e-1, (10) = 0.9e-1, (11) = .10, (12) = .11, (13) = .12, (14) = .13, (15) = .14, (16) = .15, (17) = .16, (18) = .17, (19) = .18, (20) = .19, (21) = .20, (22) = .21, (23) = .22, (24) = .23, (25) = .24, (26) = .25, (27) = .26, (28) = .27, (29) = .28, (30) = .29, (31) = .30, (32) = .31, (33) = .32, (34) = .33, (35) = .34, (36) = .35, (37) = .36, (38) = .37, (39) = .38, (40) = .39, (41) = .40, (42) = .41, (43) = .42, (44) = .43, (45) = .44, (46) = .45, (47) = .46, (48) = .47, (49) = .48, (50) = .49, (51) = .50})

B:=Array([seq(F,t=0..Y,X)]);

B := Array(1..51, {(1) = 3, (2) = -1.547213596, (3) = .5000000003, (4) = -.6527864051, (5) = .5000000028, (6) = -.6000000000, (7) = .4999999973, (8) = -.6527864066, (9) = .5000000010, (10) = -1.547213590, (11) = 3.000000000, (12) = -1.547213594, (13) = .5000000048, (14) = -.6527864056, (15) = .4999999987, (16) = -.6000000000, (17) = .5000000023, (18) = -.6527863990, (19) = .4999999936, (20) = -1.547213586, (21) = 3.000000000, (22) = -1.547213599, (23) = .5000000034, (24) = -.6527864063, (25) = .5000000022, (26) = -.6000000000, (27) = .4999999989, (28) = -.6527863994, (29) = .4999999892, (30) = -1.547213580, (31) = 3.000000000, (32) = -1.547213604, (33) = .4999999897, (34) = -.6527864153, (35) = .4999999964, (36) = -.6000000000, (37) = .5000000047, (38) = -.6527863987, (39) = .4999999562, (40) = -1.547213587, (41) = 3.000000000, (42) = -1.547213579, (43) = .5000000338, (44) = -.6527864182, (45) = .4999999880, (46) = -.6000000000, (47) = .4999999849, (48) = -.6527863804, (49) = .4999999960, (50) = -1.547213619, (51) = 3.000000000})

pointplot(<A,B>,connect=true);

DD := DFT(B);

DD := Array(1..51, {(1) = .42008402179171944+.0*I, (2) = .42175153453166814+0.260127386732813e-1*I, (3) = .4273854433108563+0.529217918211225e-1*I, (4) = .439904132785008+0.8223233375459758e-1*I, (5) = .47323108886278337+.11902238832572307*I, (6) = 1.0877924551184714+.3460516889265493*I, (7) = .3569320370031822+.1382762050895581*I, (8) = .4148338889065726+.1908538823428024*I, (9) = .4619399099671241+.2480565000272187*I, (10) = .5560941614839366+.3443189070181002*I, (11) = 1.4698363115945032+1.0404755675645527*I, (12) = .1354050516836275+.10896003639239854*I, (13) = .3109084304533812+.28343048302699486*I, (14) = .3994997970246128+.4119978120383033*I, (15) = .532233172411374+.6212251967601387*I, (16) = 1.3813301699553153+1.8291767721959242*I, (17) = -.14619781495367054-.22063465161597345*I, (18) = .14702941821882043+.254662412254526*I, (19) = .251510503173138+.5051011909405684*I, (20) = .3632279493696535+.8581599783585913*I, (21) = .8576247440707302+2.433762362192655*I, (22) = -.24629996741195287-.8656546262097845*I, (23) = 0.3677142408705413e-1+.1679034515700907*I, (24) = .10208684041263871+.6576543746261295*I, (25) = .12844054276315037+1.3860942388899873*I, (26) = .13882940709643427+4.50603323174799*I, (27) = .13882940709643493-4.50603323174799*I, (28) = .12844054276315028-1.3860942388899873*I, (29) = .10208684041263884-.6576543746261296*I, (30) = 0.36771424087054055e-1-.16790345157009076*I, (31) = -.2462999674119529+.8656546262097844*I, (32) = .8576247440707302-2.433762362192655*I, (33) = .36322794936965364-.858159978358591*I, (34) = .25151050317313806-.5051011909405685*I, (35) = .14702941821882043-.254662412254526*I, (36) = -.1461978149536705+.22063465161597343*I, (37) = 1.3813301699553155-1.829176772195924*I, (38) = .532233172411374-.6212251967601383*I, (39) = .3994997970246128-.41199781203830343*I, (40) = .3109084304533811-.2834304830269948*I, (41) = .13540505168362754-.10896003639239851*I, (42) = 1.4698363115945032-1.0404755675645527*I, (43) = .5560941614839372-.34431890701810014*I, (44) = .46193990996712386-.24805650002721866*I, (45) = .41483388890657275-.1908538823428024*I, (46) = .35693203700318216-.13827620508955804*I, (47) = 1.0877924551184714-.3460516889265493*I, (48) = .47323108886278337-.11902238832572289*I, (49) = .43990413278500806-0.8223233375459792e-1*I, (50) = .4273854433108562-0.52921791821123e-1*I, (51) = .42175153453166814-0.2601273867328127e-1*I}, datatype = complex[8])

 

Download DFT_Test_ac.mw

First 57 58 59 60 61 62 63 Last Page 59 of 336