@Carl Love It works for me in Maple 17.01 and 18.01.

For Maple 16.02 it works for me if I get rid of the mcomplete in the Typesetting construction.

As a minor change, instead of fiddling around with the signum of the integer part the procedure %mixed(x) could instead simply detect the case of a negative single-argument input x and then call -%mixed(-x). In other words, pull the negative sign to outside the function call. That might make some examples of subtraction look prettier. However, as mentioned before a neater way to get fancy would be with objects.

@Kitonum I've made a correction below, so that the `value` of a negative example computes properly. (I wasn't able to replace the attachement of the actual Answer, sorry.)

Download mixedrational2.mw

The second, more complicated example succeeds when "applying derivative-divides". 

Bugs reported.

restart:

int( -csc(x)^2/cot(x)^(2/3), x );        

                                /          2
                               |     csc(x)
                               |  - --------- dx
                               |          2/3
                              /     cot(x)

int( -a/3*csc(a*x)^2/cot(a*x)^(2/3), x );

                                /cos(a x)\(1/3)
                                |--------|
                                \sin(a x)/

@Axel Vogt Thanks. I forgot about your earlier answer to do the inner integral symbolically. I was trying to ensure that the inner result was accurate enough to allow the outer integral's (error-estimation) accuracy to be met for the wider range of the parameters.

Setting Digits:=6 was the primary problem, I believe. evalf/Int provides decent features for control of accuracy tolerance and working precision, and the key is to use them appropriately. A low Digits setting applied to the whole sheet is not a good idea -- better to raise it higher where needed (auxint) I believe.

Certainly it does not follow that Digits should be set low merely on account of low precision in the provided numeric data. The working precision (Digits) may well still need to be high enough to provide accurate results from (auxint, compound expressions, special functions, etc) intermediary results.

With it now much faster the plot ranges can be practically extended and their granularity improved.

CoCu18minimal_modif2.mw

Of course, with the accuracy targets of the outer integrals set coarser (1e-5 say) then any rootfinding results are only that accurate at best.

@KReuther Perhaps this will help, or give you some more ideas.

CoCu18minimal_modif.mw

Why is the output in your screenshot example left-justified? Is it 2D Output?

acer

@Alejandro Jakubi It would need some care. The act of simplfy(fdz,trig) might also unfortunately convert the tan(_X) to sin(_X)/cos(_X), in which case the subsequent evaluation at z (which is tan(_X)) = _Y would miss.

It's possible that an evaluation such as, say,

   temp := simplify(fdz, 'trig');
   t := eval(temp, [z = _Y, convert(z,sincos) = _Y]);

(followed by the same kinds of test for remaining instances of _X) might cover this situation. Might be "ok". Maybe.

@Alejandro Jakubi 

A1:=[tan(_X),
     tan(_X)^(n-2)*sec(_X)^2,
    _X]:

A2:=[sin(_X)/cos(_X),
     (sin(_X)/cos(_X))^(n-2)/cos(_X)^2,
     _X]:

tr:=proc(z, f, _X) local dz, fdz, t;
  if f::('specfunc(int)') or assigned(_Y)
    or has(f,_Y) then return NULL end if;
  try dz := diff(z,_X);
  if has(normal(dz),_X) and testeq(dz = 0) <> true then
    fdz := convert(f/dz,'diff');
    t := eval(fdz,z = _Y);
    if eval(t,_Y = z) <> fdz then return NULL end if;
    if has(op('t'),_X) or has(op('t'),'diff') then
      t := simplify(t,'trig') end if;
    if not (has(op('t'),_X) or has(op('t'),'diff')) then
      return [t, z] end if;
  end if;
  catch:
    NULL;
  end try;
  return NULL;
end proc:

tr(op(A2));
                                (n - 2)  sin(_X)
                             [_Y       , -------]
                                         cos(_X)


tr(op(A1)); # returns NULL, derivative-divides unrecognized

convert(A1,sincos) - A2;
                                   [0, 0, 0]

tr(op(convert(A1,sincos)));
                                (n - 2)  sin(_X)
                             [_Y       , -------]
                                         cos(_X)

Why doesn't `tr` also (as well, as an additional test, ie. not always)  try trig simplification before evaluating fdz at z=_Y?

@Carl Love I suspect that worksheet Tables may need selecting before Ctrl-Del will work, though selection of a (inner, nested) Table may also be done with keyboard shortcuts Alt-a, s, t (Windows).

But, sure, it often seems to suffice for sections, execution groups input or output, single lines of text in a paragraph, etc.

@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.