## 17282 Reputation

14 years, 113 days

On google groups. (comp.soft-sys.math.maple and sci.math.symbolic)

On stackoverflow.

On math.stackexchange.com.

## collect...

The very first request's target (expected result) has the c4 factored out but not nurdel. That is not consistent with the later examples' expected results.

I am not seeing a consistent definition of how the OP expects the input expressions to be handled, so I don't see a common approach. Have I missed a consistent definition of the treatment?

 > restart;
 > ee := c4*dnub*kpbr*ksr*nur*nurdel + c4*dnur*kpbr*ksr*nub*nurdel + (c4*nus0 + c5)*dnub+dnub;

 > targee := c4*kpbr*ksr*nurdel*(dnub*nur + dnur*nub) + (c4*nus0 + c5+1)*dnub: targee;

 > collect(ee,[ksr,kpbr],simplify); evalb(%=targee);

 > ff := c4*dnub*kpbr*ksr*nur*nurdel + c4*dnur*kpbr*ksr*nub*nurdel + nub;

 > targff := c4*kpbr*ksr*nurdel*(dnub*nur + dnur*nub)+nub: targff;

 > collect(ff,[ksr,kpbr],simplify); evalb(%=targff);

The OP's expected result (target expression) for this next example (his original) doesn't treat nurdel consistent with the other examples.

 > gg := c4*dnub*kpbr*ksr*nur*nurdel + c4*dnur*kpbr*ksr*nub*nurdel;

 > targgg := c4*kpbr*ksr*(dnub*nur*nurdel+dnur*nub*nurdel): targgg;

 > collect(gg,[ksr,kpbr,c4]); evalb(%=targgg);

For the latter two examples these also suffice.

 > collect(ee,[nurdel],simplify); evalb(%=targee);

 > collect(ff,[nurdel],simplify); evalb(%=targff);

 >

## @@, foldl...

The use of unapply on an applied function call (involving name x, or a picked-off parameter name) -- where the application serves no other purpose -- is madness. If the particular names of the procedure's parameters matter, then the approach seems wrong.

Your examples may well not illustrate precisely all or what you're trying to achieve.

But this may cover some of it. Note that the foldl example illustrates calling the iterating procedure, not constructing it.

```restart;

Q := sin@@3;
Q := @@(sin, 3)

Q(0.25);
0.2424474664

K:=proc(F,X,L2,n)
foldl(L->F(L,op(_rest)),X,L2\$n);
end proc:

for k from 0 to 3 do
K(f, a, [b,c], k);
end do;
a
f(a, b, c)
f(f(a, b, c), b, c)
f(f(f(a, b, c), b, c), b, c)
```

Do you have other, more involved examples that you haven't shown us yet, which have additional demands?

My concerns are not just that I think that the names of the parameters of a procedure ought to act like dummy names (ie. the particular name choice should largely not matter). You should also be careful that a methodology which extracts the parameter names doesn't break just because, say, the global names have already been assigned values. (I mean where the construction breaks because some procedure's parameter names like x have been assigned.)

## randomize...

Look at the Help for the randomize command.

Compare what happens when you run these several times:

```restart;
f:=rand(1..100):
seq(f(),i=1..10);

restart;
randomize():
f:=rand(1..100):
seq(f(),i=1..10);
```

The randomize command has a similar effect on Random Number Generators (RNGs) in the Statistics and RandomTools packages.

You don't need to implement your own RNGs simply to get different random sequences from different sessions.

## two ways...

Here are two ways, using your original assignments to SOLNSuy.

 > restart;
 > SOLNSuy[1, 1] := 2.5872902469406659197*10^(-20)-.65694549571241255901*y +1.9708364871372376767*y^2-1.3138909914248251176*y^3-1.6010739356637904911*10^(-19)*y^4:
 > SOLNSuy[2, 1] := -4.002204462000*10^(-20)-1.7879176897079605225*y +5.3637530691192141414*y^2-3.5758353794044226250*y^3-6.8309939211286845440*10^(-12)*y^4:
 > SOLNSuy[3, 1] := -1.1953264450000*10^(-19)-3.2481690589079594122*y +9.7445071767154794599*y^2-6.4963381177952273213*y^3-1.2292726248071398400*10^(-11)*y^4:
 > SOLNSuy[4, 1] := -2.6720465500000*10^(-19)-4.9239979672954025921*y +14.771993901873204315*y^2-9.8479959345587718955*y^3-1.9029826928878336000*10^(-11)*y^4:
 > SOLNSuy[5, 1] := 3.416928541000*10^(-20)-6.7268498492441931137*y +20.180549547714413714*y^2-13.453699698443639810*y^3-2.6580790570532587008*10^(-11)*y^4:
 > SOLNSuy[6, 1] := -2.554122292000*10^(-20)-8.5884528335125514887*y +25.765358500514014457*y^2-17.176905666966875698*y^3-3.4587270427710613504*10^(-11)*y^4:
 > SOLNSuy[7, 1] := -9.206107680000*10^(-20)-10.456823708331499352*y +31.370471124965259849*y^2-20.913647416590986491*y^3-4.2774005353527132160*10^(-11)*y^4:
 > SOLNSuy[8, 1] := 1.9644186790000*10^(-19)-12.293003938471349390*y +36.879011815379230436*y^2-24.586007876856948223*y^3-5.0932823222176363520*10^(-11)*y^4:
 > SOLNSuy[9, 1] := -3.775112769000*10^(-19)-14.068404975282556550*y +42.205214925807397100*y^2-28.136809950465931724*y^3-5.8908824448577377280*10^(-11)*y^4:
 > SOLNSuy[10, 1] := 1.146281780000*10^(-19)-15.762658869974768890*y +47.287976609878780960*y^2-31.525317739837422477*y^3-6.6589592851037286400*10^(-11)*y^4:
 > plots[animate](plot, [SOLNSuy[floor(A), 1], y = 0 .. 1], A = 1 .. 10, frames=10);

 > L:=[seq(plot(SOLNSuy[A,1],y=0..1),A=1..10)]: plots:-display(L,insequence=true);

 >

It's not a big deal, but you could also use trunc rather than floor in the first approach above. However I find the second approach -- using seq -- more natural. (A pun for the year's end.)

## one of these?...

Are you looking for one of these?

plot(x-floor(x/3)*3, x=-5..5);

plot(fmod(x,3), x=-5..5);

(Note that they are not the same.)

That Example unfortunately shows only how to have text use the current Style that is set for Hyperlinks, rather than an actual hyperlink.

There is a Hyperlink constructor exported from DocumentTools:-Layout, but it is not documented. It's also not a package export, so its name is not rebound by with. But it can still be called by its full name.

```with(DocumentTools):
with(DocumentTools:-Layout):
InsertContent(Worksheet(Group(Input(Textfield("Track Santa at the ",H))))):
```

## unapply...

It is not a bug. But it is a commonly asked question.

for i from 1 to n do a[i] := unapply( b[i](u), u); od;

I consider it safe to assume that you've given us a toy example merely for the purpose of illustration, and that your actual examples are more involved. Otherwise you could assign more directly from b to a, or b[i] to a[i]. I assume that you are not working with this trivial task.

If you have a more involved example for which the above approach does not work as you want then show us the full example. There are too many variants to guess thoroughly.

Eg, you might want the i in  b[i] to be resolved in the body of the new operator/procedure -- while neither b[i] nor the call b[i](u) are yet resolved explicitly or executed. That could be done as follows, which also handles even more complicated cases,

for i from 1 to 2 do
a[i] := subs(__dummy=b[i],(u->__dummy(u)));
end do;

Such subtleties might not matter to your workflow. It could conveniently allow you to change any or all of the definitions of the b[i] without having to reassign the a[i]. That might well not matter to you.

## substitution...

Substitute for 1-gamma first, using e_nsp2. Then you can substitute for gamma using e_nsp1 (without interfering with the original 1-gamma terms).

(You could also separately freeze the relevant terms 1-gamma and gamma, and then do the substitutions together. But your example seems unambiguous and so this may not be necessary here.)

 > e_nsp1 := nsp_1 = gamma*L/(sigma*alpha);

 > e_nsp2 := nsp_2 = (1 - gamma)*L/(sigma*alpha);

 > set_3 := {sigma*alpha = tau*w^(sigma - 1)*mu_11*w*gamma*L                         + w^(sigma - 1)*mu_12*s*(1 - gamma)*L/tau,           sigma*w*alpha = mu_11*w*gamma*L + mu_12*s*(1 - gamma)*L};

 > subs([1-isolate(e_nsp2,gamma)], set_3);

 > subs(isolate(e_nsp1,gamma), %);

 >

## missing comma...

You are missing a comma between the 3rd and 4th equation in the definition of Inter.

Also, did you realize that Inter contains lambda[1], etc, while the eqs and Sol contain lambda__1, etc? I'm not sure which you want, but I've changed them to match, here. tes_ac.mw

## multiple roots...

I suspect that the real lesson to learn here is: Do not evalf non-constant expressions before it is necesary! Doing so can easily result in loss of accuracy when doing subsequent numeric computations, due to roundoff error in the approximated coefficients.

Leave coefficients as exact values as late as you can. It may prevent roundoff error from hiding roots, or finding true extrema, and it might even allow useful symbolic simplification.

In this example it looks as if the supplied expression contains a mix of exact names (ie, x) and floating-point coefficients. It seems possible that some (earlier) representation or characterization might be possible in which a wealth of multiple roots could be ascertained.

Below I use Maple 2019.1.

 >
 >
 >

 >

 >

 >

Calling fsolve with a maxsols option (alas, undocumented) is just a hook to NextZero. It's an alternative to Student:-Calculus1:-Roots(...,numeric) which calls fsolve recursively.

Also, we can note that a 10-digits approximation to an actual root can possibly produce a large residual (forward error). That can happen simply due to the fact that the root (or the coefficients) have been already rounded.

## Maple 2015...

In Maple 2015 you'll need to account for the special-evaluation rules which Explore has on its first procedural parameter (ugh).

Here is one way that seems to handle your posted example, in a procedure. I used Maple 2015.2. Here I deliberately stuck to your original approach.
Explore_Procedure_ac1.mw

ps. I mean no offence, but I have reservations about this whole approach, including picking apart RVs. (I don't understand what great convenience that brings over passing around a distribution name and parameter names, at the risk of complicated and IMO hazy mechanisms.) And to go to such efforts, while global :-x must still be unassigned, etc, seems awkward to me. Perhaps I don't properly understand how this OBSERVE procedure is intended for use.

## with, uses...

The command with is not intended to work inside a procedure body. It's Help pages documents that clearly, with examples. That is the primary cause of the error.

I have changed your definition of PR to utilizes the uses syntax instead.

does_not_evaluate_ac.mw

Since you're using Maple 2019 you might find its new Calendar package easier for those computations (eg. date differences).

## HTML caption...

It is undocumented and not widely known that the caption string of a Button Component can be set using a reasonably convenient subset of HTML.

This attachment shows font size control in two such ways. I used Maple 2019.1.

 > restart;
 > with(DocumentTools):
 >

First, let's use the size attribute of the HTML font tag.

 > mk:=proc(s::string, fs::posint)   sprintf("%s",           fs,s); end proc:
 >
 > for i from 1 to 6 do   Threads:-Sleep(0.5);   SetProperty("Button0", ':-caption',               mk("foo",i), ':-refresh'); end do:

Or we could use an Internal CSS and the font-size property.

 > mkcss:=proc(s::string, fs::posint)   sprintf("

%s

",           fs,s); end proc:
 >
 > for i from 8 to 20 by 2 do   Threads:-Sleep(0.5);   SetProperty("Button0", ':-caption',               mkcss("foo",i), ':-refresh'); end do:
 >

You can use similar techniques to control qualities such as text color, bold and italic, etc.

I am not sure what is the extent of this functionality.

## And...

If you pass the inequalities to solve in an And call (as opposed to the more usual set)  then the result will be a RealRange which pretty-prints in a traditional manner with brackets.

Here's your example, as well as some conversions back and forth.

 > restart;
 > a1 := solve( And(-1 < x, 0 < 2*x/(x^2 - 1), x < 1), x );

 > lprint(a1);

RealRange(Open(-1),Open(0))

 > op(map(op,a1));

You may also find these conversions useful.

 > convert(x::a1, relation);

 > a2 := solve({-1 < x, 0 < 2*x/(x^2 - 1), x < 1}, {x});

 > b2 := And(op(a2));

 > convert(b2,RealRange);

 > lprint(%);

x::RealRange(Open(-1),Open(0))

 >

## axis bars, or tickmarks?...

Are you asking for axis labels and axis bars but with no axis tickmarks?

Or are you asking for axis labels with neither axis tickmarks nor axis bars? That is not possible in the strict sense, since the labels are part of the axes (as a whole, to the GUI renderer) and there is no syntax for omitting only the axis bars.

While you may not be able to get rid of the axis bars themselves while retaining axis labels, but you can make the axis bars thin and white and less apparent under no light model.

Personally, I don't see much point to having axis labels without any axis bars since in that situation it is visually unclear as to where the labels lie spatially, upon rotation. Without the axis bars there's little visual cue (apart from what the surface might convey...)

 > restart;
 > plot3d(sin(x)*y, x = -2*Pi .. 2*Pi, y = -2*Pi .. 2*Pi,        axis=[tickmarks=[],location=low],        axes=normal, lightmodel=none,        labels=[X,Y,Z]);

 > plot3d(sin(x)*y, x = -2*Pi .. 2*Pi, y = -2*Pi .. 2*Pi,        axis=[color=white, thickness=0.001, tickmarks=[],location=low],        axes=normal, lightmodel=none,        labels=[`#mi("X",mathcolor="black")`,                `#mi("Y",mathcolor="black")`,                `#mi("Z",mathcolor="black")`]);

 >