@Scot Gould GAMMA is not what helps here. It's happenstance. Any other `convert` call that happens to accept a float argument would also succeed in exactly the same way.

The fact that GAMMA also relates (otherwise) to factorial would make it unnecessarily misleading to recommend it to your colleague for this situation. No actual conversion takes place here.

As for the "operator form" calling sequence, I too am a fan. It's often my first choice if I just need to avoid so-called "premature evaluation", when invoking with a function call.

@dharr The GAMMA conversion is a red herring here. In fact there's no factorial->GAMMA special-function call conversion actually going on here.

What is going on here is that (new behavior in Maple 2023!) the evalhf facility is escaping out to compute the (kernel builtin) convert call.

Some years ago evalhf was enhanced to allow it to escape out (of itself) for calls to eval. This was interestingly general, since one can put a variety of things in an eval call). But this escape for an convert call, that's new.

Note however that what the convert command actually receives in the example is just the software float 15.19780218. There nothing special about GAMMA going on. Other unrelated an noneffective conversions succeed for the very same reason as this does.

Yes, that's right. This approach is simply yet another evalhf avoidance-mechanism. (There are still others... but alas I don't have all night...)

Download Factorial_to_Gamma_failed_plot_ac.mw

That above was Maple 2023.0. The single call evalhf(F(5.1)) as well as plot(F, 0..20) are both succeeding because evalhf is calling-out-of-itself to perform the convert calls, and that receives as its argument a result computed (also in this escaped mode) using regular software floats.

Now, in Maple 2022.2 and earlier the same call to convert throws an error under evalhf. So the single call evalhf(F(5.1)) emits an error. The plot(F, 0..20) succeeds because the plotting mechanism catches errors in computing values at points under evalhf mode, and re-tries them in regular evalf mode.

Download failed_plot_dharr_ac.mw

Could you please upload and attach a Maple .mw worksheet that is self-contained enough to reproduce your problem (at least if run in the same version as your Maple 2019)?

Could you please check that the same example exists in the Programming Guide that is bundled in the Help system for your Maple 2019?

My Maple 2019 version of the Programming Guide has named sections and subsections, but no page numbers. But I'd like to not only know which example is problematic for you, but to see the worksheet in which it fails.

I'm supposing that you are using the last (freely upgraded) Maple 2019.2 point-release for that version.

Many calculations can be programmed in Maple in several different ways, some of which may be fast and efficient, and some of which may be slow and inefficient. In my experience it is common for the most important thing to be obtaining a fast and efficient scalar/nonparallelized implementation first and foremost, and then move on to parallelization only when that is very good. Often times the improvements possible for an inefficient scalar/nonparallelized implementation significantly outweigh the further benefits of parallelization. Hopefully you'll be able to share some of the crucial bits of your monte-carlo simulation code, if you suspect that might be optimized.

It's not clear to me that you read and digested the commentary in my answer.

Would you be prepared to accept a result closer to y=0? If so, how close?

Download badPDE_ac2.mw

@petit loup There is nothing abjectly wrong with your use of roll, assigned via RandomVariable.

You primary performance issue is mainly solved just by using the more appropriate syntax I gave, ie.   Sample(roll, [n,n]) .

On a related note, your work might require regenerating additional (possible large) samples from the same random variable. That can be done with a slight efficiency gain by reusing the Matrix container.  Eg,

   X := Sample(roll, [n,n]):

and then, later on, perhaps several times,

   Sample(roll, X):

That last call repopulates the existing Matrix X with a fresh collection of random values. If done many, many times the saved overhead of not having to construct/memory-manage the previous Matrix structures may be measurable.

@Muhammad Usman Your original image showed no labels or ticks or values on the axes, so I removed them. You can get them back by removing the relevant options, eg.

Download M2022_colorbar_fun2.mw

Other changes to the axes can be done by simply using the usual options in the usual ways.

ps. As for your sequence of space-curves, for which you obtained a surface using surfdata, have you considered creating a interpolating function F from sampling those space-curves? Such a function call F(x,t) could be used with plot3d, densityplot, etc, just like the example expression above. Or you might use some formula in x and t thst produced the sequence...

@Muhammad Usman What does that mean, the "contour plot of the sequence"?!

I'm giving up. You're only providing brief, inadequate (and, to me, meaningless) fragments. It's not a proper description.

@Muhammad Usman Why would you think that either of those would work in densityplot?!

You have not given a proper or adequate description of what you're actually trying to do.

@Muhammad Usman You assign to f the result from plots:-surfdata, and then pass that f as the first argument to plots:-densityplot.

What do you expect that to do?

You should describe what you're actually trying to do, in adequate detail. I can't help you, if you don't.

What version of Maple are you using? Is it still Maple 2015?

Please put close followup queries to this here, instead of spawning wholly separate new Question threads for such.

@C_R I started with the Help page ?dsolve,numeric,DAE because in your Question you showed that the call came from the example worksheet for ?examples,numeric_DAE.

ps. If I enter the following in the Google search bar of my Chromium web-browser then the first hit is to that ?dsolve,numeric,DAE Help page.
    maple help dsolve "differential option"

I'm merely reporting what worked for me. Searching is often tricky.

@Traruh Synred Your boostTo.mw attachment here was saved using Maple 2018.2 (released in the year 2018), and not Maple 18 (released in the year 2014).

The naming scheme was changed in 2015, to have the release number match the year.

@Traruh Synred Your dMemB1List and dMemB2List are rtables (eg. Arrays, or row Vectors), and not lists.

You could try and concatenate them with,

   <dMemB1List|dMemB2List>

Your worksheet is missing code that defines B_recursive.