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

It works for me using lists.

By the way, even if it did work for sets, it would not be best because the ordering of elements of sets is lexicographic, and they uniquify. So you could get an unintended color/expression pairing, depending on how the sets get ordered. And it's even possible (under assumptions, etc) that the set of expressions could end up with less entries than the set of color strings. It's better to use lists, if you have them only in the plotting call.

restart

kernelopts(version)

`Maple 2017.3, X86 64 LINUX, Sep 27 2017, Build ID 1265877`

f := proc (z) options operator, arrow; z^2 end proc

proc (z) options operator, arrow; z^2 end proc

w := f(I*x+y)

(I*x+y)^2

plots[implicitplot]([Im(w) = 2, Re(w) = 2], x = -5 .. 5, y = -5 .. 5, colour = ["Blue", "Red"])


Download impl_examp.mw

If you can show it working in 1D input, but not in 2D input, then it's usually a good idea to upload the full set of code-to-reproduce as an attachment (green arrow in Mapleprimes editor).

You may have been using a toy expression just to illustrate a difficulty, but in case you're interested your can get smooth curves by doing explicit plots here, eg.

sol1 := [solve(evalc( Re(w)=2 ),y)];
sol2 := [solve(evalc( Im(w)=2 ),y)];
plots:-display(
 plot(sol1, x=-5..5, view=-5..5, color="Red"),
 plot(sol2, x=-5..5, view=-5..5, color="Blue")
);

Lastly, if you're using 2D Input then you can do yourself a favour by using the arrow notation like f:=z->z^2 for assigning the procedure/operator. I mean, don't do f(z):=z^2 to define the operator.

Your worksheet is a bit of a muddle, I'm afraid. Please see the attached which is an attempt at revision.

Let us know when you want to set the example's general formula based on radio buttons.

doubt2_MathContainer_ac.mw

If you use the name form in a general context then you should use it as  ':-value'  which is the unprotected global name. That protects against the situation that either your or the end-user has assigned to value at the current scope.

If you use "value" then that should not be a concern (supposing that SetProperty works properly).

Other than that, it doesn't really matter.

As an experiment, assign something like 2.1 to value, outside your components. Then test which of these work:

  value    "value"    ':-value'

 

Let me know if I've misunderstood or made a mistake.

restart;

randomize(333):

`print/abs`:=proc(t1)
  local s;
  if nargs=1 and t1::polynom(anything,':-z')
    and degree(t1,':-z')>0 then
    s := sign(t1,[':-z']);
    'abs'(sort(s*t1,':-order'=':-plex'(':-z')));
  else
    'abs'(args);
  end if;
end proc:;

ran := rand(-5 .. 5):

(a,b) := ran(), ran();

-2, -2

p := z+a+b*i;

-2*i+z-2

abs(p);

abs(2*i-z+2)

for k from 1 to 4 do
  (a,b) := ran(), ran();
  p := z+a+b*i;
  print(p);
  print(abs(p));
  print();
end do:

-2*i+z+1

abs(2*i-z-1)

2*i+z+2

abs(z+2*i+2)

5*i+z+1

abs(z+5*i+1)

-i+z-1

abs(i-z+1)

 

Download abs_sort.mw

The default value for an entry of an rtable (Array, Vector, or Matrix) is zero.

Notice that you are using lprint.

There's not much benefit from rtable_elems returning (or lprint displaying) the indices that take on the default value.

There are a variety of ways.

And, if you have a list of lists (of the pairs of arguments) you can map or interleave.

[iquo,irem](p,q);

                    [iquo(p, q), irem(p, q)]

([iquo,irem]@op)([p,q]);

                    [iquo(p, q), irem(p, q)]

([iquo,irem]@op)~([[p,q],[s,t]]);

      [[iquo(p, q), irem(p, q)], [iquo(s, t), irem(s, t)]]

map([iquo,irem]@op, [[p,q],[s,t]]);

      [[iquo(p, q), irem(p, q)], [iquo(s, t), irem(s, t)]]

map(eval,[iquo(x,y),irem(x,y)],[x,y]=~[p,q]);

                    [iquo(p, q), irem(p, q)]

map(eval~,[iquo(x,y),irem(x,y)],map[2](`=`~,[x,y],[[p,q],[s,t]]));

      [[iquo(p, q), iquo(s, t)], [irem(p, q), irem(s, t)]]

It will run faster if the computation done by the objective function can run under the fast hardware double-precision evalhf interpreter.

One way to accomplish that is to remove SoS's global declarations, and instead have it accept those globals as extra parameters, and then call NLPSolve on an unevaluated function call that includes those (as well as the parameters) as arguments. I haven't done that.

Another, straightforward, way to get most of the same benefit is to create an inner procedure which is called by SoS under evalhf. By doing that I didn't have to change how you set up NLPSove to call SoS.

HN_fit_of_DMA_data_ss_proc_v5a_ac.mw

There are other ways to squeeze even better performance out of the objective procedure (adjust the loop code perhaps, use Compiler:-Compile, etc, none of which I've done), but making the bulk of the work be done under evalhf is one simple way to get a significant improvement.

A related, easy improvement comes from giving a hardware datatype to each of those data Vectors accessed by the objective. This slightly improves the benefit from the evalhf adjustment.
 HN_fit_of_DMA_data_ss_proc_v5a_ac2.mw 

You might find this interesting reading.

The revised objective evaluates quicker than does the original objective. So the benefit would also come into play if using an alternate optimizer such as the global optimizer from the DirectSearch add-on package. Global optimizers generally do many more objective evaluations, so in terms of absolute timing comparison the performance benefit would likely be greater. (I haven't been able to attain a better minimum using DirectSearch:-GlobalOptima and the same variable bounds, however. I also didn't examine the objective for possible convexity.)

 

If things get awkward when you assign a value to t, then don't do it.

Instead you can evaluate u at a numeric value for t, when you call plot.

This easier than having to repeatedly assign a value to t, and then unassign t, if you want to do multiple plot calls  (possibly for different t values) and plot3d calls.

In future, please either upload a worksheet (green button), or inline only 1D input and not the output. Also, please don't submit multiple posts of essentially the same problem.

restart;

l := 4: m := 1: n := 2:
k := 1/sqrt(-6*beta*l^2+24*beta*m*n):
w := alpha/(5*beta*sqrt(l^2-4*m*n)):
B[0] := -(1/25)*alpha*(5*l^3/(5*sqrt(l^2-4*m*n))
        -20*l*m*n/(5*sqrt(l^2-4*m*n))-l^2+2*m*n)
        *sqrt(-6*beta*l^2+24*beta*m*n)
        *(5*sqrt(l^2-4*m*n))/((l^2-4*m*n)^2*beta):
B[1] := -(12/5)*m*alpha*(5*l/(5*sqrt(l^2-4*m*n))-1)
        /sqrt(-6*beta*l^2+24*beta*m*n):
B[2] := -12*m^2*alpha/(sqrt(-6*beta*l^2+24*beta*m*n)
        *(5*sqrt(l^2-4*m*n))):
theta := sqrt(l^2-4*m*n):
xi[0] := 1:
F := -l/(2*m)-theta*tanh((1/2)*theta*(xi+xi[0]))/(2*m):
beta := -2:
alpha := -3:
xi := k*x-t*w:
u := B[0]+B[1]*F+B[2]*F*F;

plot3d(u, x = -30 .. .30, t = -30 .. .30);
plot( eval(u, t=0), x = -30 .. 30);

plot3d(u, x = -30 .. .30, t = -30 .. .30); # still works
plot( eval(u, t=1.5), x = -30 .. 30);

 

The reason it does not work is that add uses the global :-`+` and not the rebound `+` that is exported by the Tolerances package.

When you call with(Tolerances) the name `+` is rebound to the package export. But most Library code and (in this case) the kernel builtin add, still use the global :-`+`

Carl's Answer is saying that it would have worked if Tolerances also exported its own add implementation (which could be written to use its own `+`). That kind of Library code is hard to write correctly, however, if one tries to replicate the special evaluation rules that global :-`+` has.

I'll also note that (somewhat strangely) the simple calling sequence you've used for elementwise multiplication is picking up the global :-`*` rather than the rebound `*` from the Tolerances export.

I'd call the behavior of add a weakness, but the behavior of *~ might be a bug.

restart;

kernelopts(version);

`Maple 2018.0, X86 64 LINUX, Mar 9 2018, Build ID 1298750`

with(Tolerances):

a := 30 &+- 3;

INTERVAL(27 .. 33)

b := 40 &+- 4;

INTERVAL(36 .. 44)

add( [a,b] );

INTERVAL(27 .. 33)+INTERVAL(36 .. 44)

:-`+`(a,b);   # global :-`+`

INTERVAL(27 .. 33)+INTERVAL(36 .. 44)

`+`(a,b);     # Tolerances:-`+`

INTERVAL(63 .. 77)

restart:
with(Tolerances):
x := 10 &+-1:
y := 20 &+- 2:

[3, 2] *~ [x, y];

[3*INTERVAL(9 .. 11), 2*INTERVAL(18 .. 22)]

`~`[:-`*`]([3, 2], ` $`, [x, y]);    # global :-`*`

[3*INTERVAL(9 .. 11), 2*INTERVAL(18 .. 22)]

`~`[`*`]([3, 2], ` $`, [x, y]);      # Tolerances:-`*`

[INTERVAL(27 .. 33), INTERVAL(36 .. 44)]

zip(`*`,[3,2],[x,y]);                # Tolerances:-`*`

[INTERVAL(27 .. 33), INTERVAL(36 .. 44)]

 

Download tol2.mw

The functionality is pretty much the same, and for the example you have it is a matter of taste or judgement.

Personally, I much prefer using GetProperty and SetProperty instead of Do . I find it easier to read and understand code that utilizes GetProperty and SetProperty since the purpose is clear from the command name, whereas with code that utilizes Do I have to examine the structure of the arguments to figure out the purpose. This reason alone is enough for me to avoid utilizing Do .

I also find it best to use the string form of Component identities, such as "Plot0" to avoid evaluation issues. Utilizing the form %Plot0 seems like an extra burden, to me. In a related way, when I am building an App and using DocumentTools:-InsertContent then I find it more straightforward to utilize the returned table mapping of component identities as strings.

And lastly, the SetProperty command supports a bit of extra functionality with its option refresh . This can be useful when you want the visual display of the state of a Component to be updated before control returns from the kernel to the GUI, which can be the case when some Component's action code has multiple or compound effects. That is not the case for your example, however.

At the risk of stating something obvious: you can shift or transform the arguments.  For example, and only because I haven't seen it mentioned elsewhere in this thread,

restart;
Student:-VectorCalculus:-SetCoordinates('spherical'[r, theta, phi]):
Student:-VectorCalculus:-VectorField(<0, 0, phi+Pi>, output = plot,
                                     view = [-4..4, -4..4, -5 .. 5],
                                     fieldoptions = [arrows = THICK, color = black,
                                                     fieldstrength=maximal(1.0),
                                                     grid = [13, 13, 3],
                                                     view = [-4..4, -4 .. 4, -1 .. 1]]);

FP.mw

If you plan on doing something other than just display the results below then tell us the full context of what you're trying to do.

restart;

G:=proc(a,b)
     uses Typesetting;
     mrow(Typeset(EV(a)),
          mfenced(Typeset(EV(b)),
                  ':-open'="&lsqb;",':-close'="&rsqb;"));
end proc:

seq('op'(G(S,i)),i=1..5);

S

(1)

restart;

G:=proc(a,b)
     uses Typesetting;
     mrow(Typeset(EV(a)),
          Typeset(EV(b)));
end proc:

seq('op'(G(S,[i])),i=1..5);

S

(2)

 

Download TSexamp.mw

If you want you can also give the surfaces various degree of transparency, and if you want you can throw in the intersecting space-curves.

And, naturally, you can fiddle with the transparency levels or the colors.

restart;

f := x*w - z:
g := -z^2-w+x+2*z-1:
Op := 5*x-4-4*z+3*w:

A := map(solve, [f=0, g=0, Op=0], w);

[z/x, -z^2+x+2*z-1, 4/3-(5/3)*x+(4/3)*z]

S1:=solve(A[1]=A[3]):
C1 :=eval([x,z,A[1]], S1);

[x, x*(5*x-4)/(4*x-3), (5*x-4)/(4*x-3)]

S2 := solve(A[2]=A[3]):
C2 :=eval([x,z,A[2]], S2);

[(3/8)*z^2-(1/4)*z+7/8, z, -(5/8)*z^2+(7/4)*z-1/8]

plots:-display(
  plot3d(A[1], x=0..2, z=0..2, view=0..2, plotlist, color = red,
       transparency=0.8),
  plot3d(A[2], x=0..2, z=0..2, view=0..2, plotlist, color = blue,
       transparency=0.8),
  plot3d(A[3], x=0..2, z=0..2, view=0..2, plotlist, color = "#909090",
       transparency=0.2, style=surface),
  plots:-spacecurve( C1, x=0..2, color="#b00000", thickness=3),
  plots:-spacecurve( C2, z=0..2, color="#0000b0", thickness=3),
  lightmodel=none,
  view=[0..2,0..2,0..2]
);

plot3.mw

Suppose that you first use a color-function to generate a 3D plot with a custom HUE coloring (via your custom formula).

You could then extract its hue data, use plots:-surfdata to apply a color scheme onto that data, and then substitute the new color data for the old.

restart;
c := ph+th/16:
P := plot3d(1, th=0..2*Pi, ph=0..Pi, coords=spherical, color=c):
P;

T := plots:-surfdata(op([1,2,2],P),
                     colorscheme= ["zgradient",[black, red, yellow, white]]):
subsop([1,2]=op([1,4],T),P);

# op([1,2],P) is the COLOR substructure of PLOT structure P.
# op([1,4],T)  is the new COLOR substructure of PLOT structure T.
# We replaced the COLOR substructure in P by that in T.

You could also use the valuesplit choice within the colorscheme option list, instead of zgradient.

The call exp(I*Pi/3) evaluates to 1/2+I/2*3^(1/2) so you'll need to prevent that evaluation if you want it expressed that way.

You could use polar form, or inert %exp, or uneval quotes around and exp call.

restart;

local gamma:

A := I*sqrt(3) + 2*c*exp(I*(gamma+(1/3)*Pi))
     + 2*a*exp(I*alpha) - 2*a*exp(I*(alpha+(1/3)*Pi))
     - 2*b*exp(I*beta) - 1;

I*3^(1/2)+2*c*exp(I*(gamma+(1/3)*Pi))+2*a*exp(I*alpha)-2*a*exp(I*(alpha+(1/3)*Pi))-2*b*exp(I*beta)-1

B := I*sqrt(3) - 2*a*exp(I*(alpha+(1/3)*Pi))
     - 2*b*exp(I*beta) + 2*b*exp(I*(beta+(1/3)*Pi))
     + 2*c*exp(I*gamma) + 1;

I*3^(1/2)-2*a*exp(I*(alpha+(1/3)*Pi))-2*b*exp(I*beta)+2*b*exp(I*(beta+(1/3)*Pi))+2*c*exp(I*gamma)+1

T := radnormal(expand(A/B));

1/2+((1/2)*I)*3^(1/2)

convert(T, polar);

polar(1, (1/3)*Pi)

'exp'( simplify( ln(T) ) );

exp(((1/3)*I)*Pi)

 

Download simp_example.mw

 

First 159 160 161 162 163 164 165 Last Page 161 of 336