@GuruYerram Please see Carl's good answer below. Lists are not true mutable data structures in Maple. In consquence Maple needs store in memory only one instance of any particular list. So you can just test whether your two candidate lists are the identically same stored structure, either checking directly under evalb or within a conditional check.

As for why your code did not work, note the the seq call in the assignment to list2 does not alter the value of n at the higher scope. So n-1 is not a numeric value such as 20-1 say, after that assignment to list2. It's still just n-1 in terms of unassigned symbolic n. When you try and set up that for-loop with index j then Maple complains that the final value n-1 is not numeric.

If you had used a for-loop with index name n, to create a table or Vector/Array, then that index name would be assigned after the loop was finished. But, in contrast, the index name in a seq call is local to that call.

"What I am doing wrong?"

You are not showing us the code which you used.

acer

Download squareblack.mw

Be sure to notice that phaseportrait is a command in the DEtools package. So it must be either called as DEtools[phaseportrait] or be called after loading the package using the command with(DEtools).

If you try and use it straight, in neither of those ways, then maple will just return your command call.

acer

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