@Carl Love I suppose that for a bvp there is a need to solve, at some juncture, sure. (Sorry if I made it sound like there'd be no solving step altogether.)

@Carl Love In the case that D doesn't/cannot successfully delve into the process (ie. returns unevaluated) then subsequent instantiations at a point, wrapped inside evalf, will invoke fdiff and thus attempt numerical differentiation. I agree, this is the least attractive way, as on general it'd be numerically least robust.

Another method, not yet mentioned in this thread I think, is to first augment the ode system before calling dsolve. An additional equation like say diff(y(x),x,x)=w(x) allows w(x) to be part of the generated solution. I believe this is easier to do than "solving for" the term. I also suspect that dsolve/numeric internal engine is generally in the best position to do the numeric computation (it already provides an integrated precision & abs/rel tolerance scheme, might even be better for dealing with round-off errir in some "solved" formula/scheme, etc). This approach is part of the initial call to dsolve, and not something done after the call, of course. I generally prefer it.

This subject has come up before on this site, quite a few times.

@nm I did not write that the negation of op(0,eval(g,1)) = int is unqualified "success". I wrote that it was a check for whether the return is an unevaluated int call.

How you choose to characterize "success" is something we can only guess at, in advance of your telling us.

BTW, Maple allows for some adventurous use of names vs symbols. Would you say that the following (deliberately exotic) example succeeds?

restart:

alias(y=x[int(f(x),x)]);
                                      y

g := int( y^2, y );

                                       1  3
                                  g := - y 
                                       3   

hastype(eval(g,1), specfunc(anything,int));

                                    true

If you would say that example succeeds then perhaps you also have certain as yet unstated qualifications on the class of examples to be tested.

@Bendesarts This now appears to be a C programming question, which might even be sensibly posed in a programming forum unrelated to Maple. It seems to me that Maple is just the tool used to create the standalone C source, but is otherwise not necessary for a solution.

But a version of the Watcom C compiler is bundled with the 32bit Maple 18 on Windows, and this might be used to create your DLL. I believe that you should strive for a DLL that does not rely on the Maple runtime, in this case, and so I would suggest that the Maple command `Compile` not be used directly. (You don't want something linked to Maple's libmrt, or which might only run alongside a licences Maple installation.) What is needed, then is the particular (shell) calling sequence of the WATCOM executables. I would have to dig, to find that out once again. I seem to recall that either I or Axel or someone else posted such a thing many years ago in this forum.

OK, so it seems that you have used Maple to emit C source (which is stand alone, ie. doesn't depend on any Maple runtime).

And now you want to create a shared object (dynamic library), so that other executables other than Maple can access its functions. That task doesn't really have anything to do with Maple, though its possible that you might be able to use whichever external C compiler is also used by Maple's Compiler command.

What version of Windows? Is your target a 32 or 64bit application? Which version(s) of Maple do you have, and for which did its Compiler command function properly? Do you have any other 3rd party C compiler installed?

acer

@Carl Love Thanks.

I could also add that checking for type specfunc is also possible. The key thing is to not cause a whole retry of the failing computation.

Which version of Maple?

Do you mean for float double precision? If so, the real or complex case?

For the nonsymmetric or the symmetric definite case?

acer

I forgot to mention that in the very last example the outer integrand is put into operator form by a call to `unapply`. That wasn't necessary when using method=_d01ajc, as per Axel's described approach. But this can be key when not specifying the method, since otherwise the internal machinery can try to expand the integrand expression (as part of discontinuity checks? It's unclear). Using operator form forcibly prevents such poking around, which can either cause a big slowdown or even a full stall and massive memory allocation even if at the top level Digits is (in this case) first brought back down to something more reasonable such as 25 say. The need for this trick crops up quite often, and I would like to see a more readily understandable, additional option to control this behaviour, instead of the obscure technique of switching to operator form.

@jonlg Yes, and indeed that's exactly what I suggested. It didn't seem like messing with the individual `tickmarks` or `xtickmarks` option should have been necessary to attain your goal.

@Rouben Rostamian  Manually changing the rotation of a 3D plot using the menubar (or rotating with the mouse cursor) does not change the PLOT3D structure, even if it already had an ORIENTATION substructure when first placed into a PlotComponent.

It would probably be better if that continues to not happen (or, at least not upon every rotation's rendering update) because it would be a very bad inefficiency if the GUI had to repeatedly send an updated PLOT3D structure back to the kernel. So, manual rotation is quite different from just changing linestyle or lighting, etc, because it is something for which an "update" can happen very often as one manually rotates.)

So instead I have been asking for those qualities (and the projection factor) to be properties of a PlotComponent, that could be queried and set using the DocumentTools:-GetProperty and DocumentTools:-SetProperty commands. As properties of the PlotComponent they could be picked off programatically and efficiently, with no need for a mass of data to flow back to the kernel engine from the GUI or even for any large plot structure to be updated/regenerated. I've been asking for some time now.

(Another way to improve such things would be to get a whole new plot data strucure, that was efficiently mutable, such that ORIENTATION could be updated without having to form a copy of the whole PLOT3D structure to be sent back over the socket. But I don't expect that to happen any time soon...)

@beidouxing Your use of {} and [] is invalid. Ie. You really don't have the mathematical expressions that you think you do.

After replacing with (), and digging around, it seemed to me that both c[1] and c[2] are unbounded above when w is replaced in some way (that I believe is equivalent) as you laid out, over x,y,z >0.

@Markiyan Hirnyk This seems to be one of those weird cases where an initial call to `solve` seems to churn, yet interrupting it and trying again succeeds.

For both the direct attempt using {eq1,eq2} as well as Carl's method with elimination of y I am seeing `solve` churn. But then if I interrupt and retry, then after a few tries it works.

restart:
eq1:=((x-1)^2+(y-5)^2)^(1/2)+1/2*abs(x+y) = 3*2^(1/2):
eq2:=abs(x+2)^(1/2) = 2-y:
G:=proc(i) solve( {eq1,eq2}, [x,y] ); end proc:
for i from 1 to 10 do
  traperror(timelimit(2,assign('res',G(i))));
  if res<>'res' and res<>NULL then printf("attempt %a",i); i:=10; end if;
end do:
res;

attempt 5
                              [[x = -2, y = 2]]

I see a similar effect when trying Carl's manual elimination of y. The first time I try it goes one and on. And similarly if I try solve( eliminate( {eq1,eq2}, y )[2] ).

Curiously, by trying to eliminate x rather than y I get a piecewise expression from which the single solution can be picked off immediately (though it's awkward to split the y cases programmatically, and I did only manually).

restart:
eq1:=((x-1)^2+(y-5)^2)^(1/2)+1/2*abs(x+y) = 3*2^(1/2):
eq2:=abs(x+2)^(1/2) = 2-y:
sol:=eliminate( {eq1,eq2}, x ):
op~(sol[1]) assuming y<>2:
solve(%, allsolutions);
                               {x = -2, y = 2}

{y=2} union op~(sol[1]) assuming y=2;
                               {x = -2, y = 2}

Will the first step consist of replacing the squiggly and square brackets with round brackets? In Maple {} is for sets and [] is for lists, but perhaps you just intended to use () which is for delimiting subexpressions.

Also (and I could be wrong) but what happens when x and y become arbitrarily small and positive while z becomes arbitrarily large and positive? Could it be that c[1] and c[2] tend to infinity in such case (under the condition that t[1]-isolated-for-w equals t[2]-isolated-for-w, and either is used for substitution of w in c[1] and c[2])? Perhaps consider the special case that x=y. Do you have some other bounds on x,y,z apart from their being either all positive or all negative?

acer

I agree, it is very nice. It might be even more impressive if the extraction of a valid IC for u(0)=D(h)(0) were done programmatically. Even if it might not always suceed. Perhaps just a call to fsolve, utilizing the intended parameter values, perhaps supplying a target range (for fsolve).

hmm. this is beginning to sound familiar. I suspect that this site has seen this kind of thing before.

It work for me, with these three lines all in the same Execution Group.

printf("Enter the number of players:\n");
numplayers:=readline(terminal):
printf("Number of players is %s\n",numplayers);

Are you using Execution Groups or Document Blocks? Which version of Maple, can I ask?

acer