@sand15 

In general one could collect both the time() and the time[real]() data, ie the "cpu time" and the "real time" respectively.

The "cpu time" as reported by Usage is an accumulation from all kernel threads that might be used during your calculation. But if there is successful parallelism then that "cpu time" can include a sum of timings of subcalculuations that may have overlapped temporally. So under successful kernel-level parallelism "cpu time" can be significantly and deceptively larger than the wall-clock duration of the computation. (By "wall-clock" I mean the time as measured by your kitchen clock or wristwatch.)  Your manual measurements obtained as the difference of time() calls is this cpu time.

The "real time" as reported by Usage is the wall-clock timing. It can be larger than the "cpu time" if your machine is loaded by other running programs or services.  On an otherwise unloaded machine the "real time" is usually the one that matters. Manual measurements of the difference of time[real]() calls can mirror this real time.

@anton_dys 

You could try out this attachment.

oldPBmenu.mw

@nm My previous comment also contained a second attachment, with another way, using just indets and no subs. 

Your task starts off with the requirement that y is the dependent variable and x is the independent variable. But dsolve will approach it from another way -- examining all the derivatives and the function calls within them, so as to infer the class of the problem and sort out the dependencies. I think it's highly likely that it uses indets for a significant part of that (or some utility procedures which in turn use indets). But its validation will differ from yours,  because the requirements do.

@nm Does this do what you want?

Download indets_subs.mw

Or you might try either F or G here.

indets_subs2.mw

@Fabio92 This approach only works if both worksheets are opened and executed.

That means that -- every time he wants to work in any worksheet that doesn't define/construct the modules and procedures -- he first has also to open the defining worksheet and execute that in the parallel.

That's quite a lot of ongoing effort.

@nm I didn't see before that the plain `y` was unwanted, as my eye saw a call y() in one of you later examples. Adjusting the type used by indets can accommodate that easily. (I'm away from my computer but will add it later.)

Using `has` to attempt this kind of thing, is not The Way, IMO. The subsequent predicate used in remove/select ends up having to do the heavy lifting, and then either needs to utilize indets or be some complicated fragile mess that simulates indets .

@rahinui I'm glad if it helps.

The conditional stull with `tools/genglobal/name_counter` is just there so that the first substituiton is done with _F1 or "higher", rather than with _F or _F0. I just thought it looked more sensible that way.

The heavy lifting is done by `tools/genglobal`, which is quite commonly used in system Library commands' code for the purpose of creating new, unassigned global names based upon some given name-stem.

@Carl Love Yes, thanks, it's clear what you meant now.

@Kitonum 

restart;
Kx:=tau->(10+2*cos(5*tau)*cos(3*tau))*exp(-tau^2):

temp:=(D@@2)(r->-Kx(r));

                                                                       2
    temp := r -> -(-68 cos(5 r) cos(3 r) + 60 sin(5 r) sin(3 r)) exp(-r )

                                                                   2
         + 4 (-10 sin(5 r) cos(3 r) - 6 cos(5 r) sin(3 r)) r exp(-r )

                                              2                                  2       2
         + 2 (10 + 2 cos(5 r) cos(3 r)) exp(-r ) - 4 (10 + 2 cos(5 r) cos(3 r)) r  exp(-r )

temp(0);                                          
                                              92

@Carl Love Sorry, I don't understand what you're trying to to convey by that last sentence, "Since the display is not done by side effect, it can be blocked by error."

@Kitonum I don't see how that approach would be robust in cases where the terms in expr are a mix of valid and invalid calls to y.

For example, it looks like the call to y(z,x) here should be noticed as not OK.

expr := diff(y(x),x)*diff(y(z,x),x) + diff(y(x),x,x):

candidates:=convert(select(has,expr,y),list):

lprint(candidates);
[(diff(y(x), x))*(diff(y(z, x), x)), diff(diff(y(x), x), x)]

map(t->`if`(has(t,y(x)),"OK","not ok"), candidates);

                          ["OK", "OK"]

Have you tried it using the inert Int command instead of the lowercase active int command?

@mmcdara 

For your point 1), I suppose that the element-wise application of is boils down to this kind of thing, where it matters whether the system allows for the second argument as a property.

is(3.000000, 3);

              true

is(sin(x)^2+cos(x)^2, 1);

              true

is(1, sin(x)^2+cos(x)^2);

Error, (in property/ConvertProperty) sin(x)^2+cos(x)^2 is an invalid property

Regarding you followup point 3), the element-wise multiplication of Arrays with the `.` command has been there since Maple 6, if I'm not mistaken. I have no problem with that syntax, which was available long before the element-wise tilde became available. If anything I'd say that I'm not a huge fan of the coercion from Array to Matrix/Vector as now done by LinearAlgebra commands.

A long time ago (Maple 6 time frame, say) there was a strong distinction between a Matrix as a linear mapping from one vector space to another and an Array as a more general kind of 2-dimensional collection of data.  I wouldn't be surprised if the rationale to allow coercion by LinearAlgebra commands were in part motivated by the wish not to surprise users (eg. Matlab users) coming into Maple. The system seemed more logically consistent to me when it was stricter in this regard. A somewhat related issue occurs for the distinction between row and column Vectors.

As for overload, you can read about it in the Help system. It's only my opinion but... they seem very nice and handy, up to the point that one has to debug them.

@Carl Love The DifferentialGeometry package has commands which change the prompt (as a semaphore of context).

@nm 

I have long advocated that help pages should quote option names and option values as if protectively and robustly coding for the most problematic cases. That includes quoting the global name where it may be necessary, where the global name is referenced using colon-dash. Eg.  ':-foo' .

I have a feeling that it's not done like that in the documentation for fear that it would lead to user confusion. (ie. Maple! So many kinds of quotes!) I hold the opposing view -- that properly, consistently, and defensively coding for the corner cases would lead to better understanding or at least acceptance of the safest practice.

nb. The fact that mint and maplemint may not emit any messages for a particular example procedure does not mean that it will compute as desired, or without error. Being "mint-clean" does not necessarily imply correct or error-free computation.

On a somewhat related note, I also think that help pages should utilize the colon-dash syntax when doing full reference to module-based package members, instead of using indexing.  A help page should reference LinearAlgebra:-Norm instead of the indexed form LinearAlgebra[Norm] , including in its Title and Description, as well as in cross-references in any See Also section. The indexed form is inferior in my opinions because it may need to be referenced safely as LinearAlgebra[':-Norm'] in order to guard against collision with possible local name Norm as well as to guard against collision with name Norm possibly being assigned at the higher level. There is some explanation on the help page with topic colondash .