Do you have a valid Maple license?

Stop posting duplicates of this question.

If you have additional details, add yhe here as a Reply/Comment on the original Question.

@adel-00 Sorry, I will be travelling for 3 weeks and have no Maple access.

Perhaps next time you could provide the correct expressions up front.

@mmcdara It's great that you found it, Statistics:-Specialize.

You last comment also has a struck-out fragment containing (mu, sigma) -> RandomVariable(Normal(mu, sigma)) . Please note that that is a procedure which generates new RVs from scratch, and not a tool for specializing/instantiating a given, extant RV (which was actually your Question). It might accomplish your goal, but it doesn't do precisely what you asked.

Please add your followup queries on this here, instead of as separate Questions.

@denitsastaicova Now you've changed your request. At first you asked how to use your given z1 to shade via colorscheme with zgradient. And now it seems as if you'd prefer a slightly different scaling and transition for the gradient of values than are in the z1 which you originally supplied.

You've subsequently added the information that what you really want is a way to visually discern the highest z1 values easily. Well, your problem there is in your choice of a zgradient from Black to RoyalBlue. But I didn't suggest that scheme... you did!

But there is another approach which can use any computed z1 in its own "zgradient" colorscheme to generate coloring data. That coloring data can then be extracted and re-used as a coloring replacement in a x1,y1 point-plot. See below for an example.

You can also adjust the scaling in the z1 to get a different pace of color gradient. (I've provided an additional example below.)

Or you can choose different colors for the gradient. Or you can use 1-~z1 to reverse your original color gradient. It's up to you which color gradient pleases you most. What I'm showing is that, yes, a 3rd list like z1 can indeed be used to denote the colorscheme zgradient in a point plot of x1 vs y1. I leave it to you to devise which z1 values and which colors for the gradient you want.

Download color_pointplot2.mw

@Kitonum On the line that assigns to single try using the prefix form for the call to &not, as a function call using brackets.

Error_ac.mw

It works in Maple 2018.2 using

  &not( ... )

and, fwiw,

  NULL &not ...

@mmcdara Unfortunately the approach you've given does not do as well in later versions. You used Maple 2015, it seems.

But with two little tweaks it can still serve. (See my Answer as to why, if you'd like.)

Download int_mmcd_ac.mw

@Carl Love The crash is due to the evalf of these Int instances at higher precision (see my Answer, eg, at Digits=25 or so).

Yes, it's true that it would be better if fsolve didn't try and demand that kind of precision increase. But the bug is in evalf(Int(...)) .

@pauldaas 

It's too bad that you've ignored all my previous suggestions. Your code still uses deprecated linalg and matrix, unnecessary stacking to iteratively build the Matrices, unnecessary globals, and substitution done via unnecessary assignment to the list of key names.

This code is severely flawed. It is unnecessarily fragile and will likely cause future grief.

It's also too bad that you could not properly explain the purpose of the code. Comments about load forces on a beam are irrelevant. What would be useful would be information about why you need to build R row by row, whether you really need C at the end (or just R), whether you know the number of rows in final R, etc.

I would not be surprised if a robust and sensible version of code to accomplish your true goals could be only a few lines long.

It's too bad that you ignored all my suggestions in a previous thread. Your code still uses deprecated linalg and matrix, unnecessary stacking to iteratively build the Matrices, unnecessary globals, and substitution done via unnecessary assignment to the list of key names.

This code is severely flawed. It is unnecessarily fragile and will likely cause future grief.

@dharr Yes, it looks like it may just be reformulated as,

   K1*Int(cos(theta),theta=0..2*Pi) + K2*Int(sin(theta),theta=0..2*Pi)

where K1 and K2 do not depend on theta.

070919_ThetaIntegral_ac.mw

@9009134

For example,

int3_ac.mw

@adel-00 Is this what you are trying to accomplish?

Apart from other problems including misuse of assumed names, your sprintf calls tried to use Lambda as if its value were a float, but it is unassigned.

Download adel00.mw

@Rouben Rostamian  The OP gave a target rhs in which most of the original (diff-unrelated) terms were not expanded. Kitonum called collect (wrt R1) to undo that effect, but that is a slightly ad hoc or manual intervention.

I surmised that the OP wanted the remaining rhs terms left mostly as is, perhaps even more so than in the supplied target.

By using either collect or expand the diff terms can be initially separated. But by using collect for the initial separation of the derivatives there is less expansion to undo, for this example.

And if the leading sign is not crucial then my answer is shorter still.

There are other kinds of example where the effects of expand can be troublesome to undo. Sure an expanded call like sin(a+b) can be undone using combine. But there may be other trig products in the original which one doesn't want combined into a sum of trig calls on sums. Sometimes a frontend'ed call to expand can serve, but that's more effort to invoke.

And there are other related examples -- originally only partly expanded. Calling expand may expand too much, so that recovery of the very same extent of expansion is hard or practically impossible.

So it's my preference to not call expand, generally, if something else serves reasonably.

More specifically for this particular example: the OP wrote that he wanted the derivative terms to be collected, and he even provided a target that illustrated that. Now, the following accomplishes that but seems inferior because,
1) it calls both expand and collect, yet as I showed only collect is needed, and,
2) it expands all the remaining rhs terms, which would requires a rather ad hoc call to undo.

((L,R)->collect(L,diff)=-R)(selectremove(has,expand((rhs-lhs)(eqn)),diff));