@sazroberson There are no subtle extra evaluations going on in this example.

Your code to map `rhs` is not correct. Apart from a missing bracket, the arguments to `rhs` will be wrong. When the variables passed to `solve` are in a list then the result is a list of such (list form) solutions.

You instead could do it as,

((rhs~)~)(solve({x+y=1,x+2*y=4},[x,y]))[];

                            [-2, 3]

((rhs~)~)(solve({x^2+y=1,x-y=5},[x,y],explicit))[];

                        [-3, -8], [2, -3]

But I still prefer to use the so-called 2-argument `eval` approach over approaches using `rhs` or `op`, as I feel it is more understandable and can (sometimes) place less burden on the coder to be aware of the variable positions in the `solve` call. Each to his own, naturally.

And, of course, the 2-argument `eval` approach can also be used with the list of lists format (but with one less mapping call),

map2(eval,[x,y],solve({x+y=1,x+2*y=4},[x,y],explicit))[];

                            [-2, 3]

map2(eval,[x,y],solve({x^2+y=1,x-y=5},[x,y],explicit))[];

                       [-3, -8], [2, -3]

@Carl Love The change is within the kernel builtin assigned command.

In Maple 18.01 all three queries within f below compute without error. In Maple 17.02 the third query, assigned(rt[foo]), does more levels of evaluation of rt[foo].

This below is run in Maple 17.02. The problematic third query seem to break 1-level evaluation rules for LOCALs. In Maple 18.01 the third query behave like the first, (giving value true rather than raising an error).

restart:

f:=proc() local rt,foo;
  rt:=table([foo='Vector'(posint)]);
  assigned(eval(rt[foo],1));
  type(rt[foo],name);
  assigned(rt[foo]);
  NULL;
end proc:

trace(f):

f();
{--> enter f, args = 
                      rt := table([foo = Vector(posint)])

                                     true

                                     false

<-- ERROR in f (now at top level) = 
"dimension parameter is required for this form of initializer"}
Error, (in Vector) dimension parameter is required for this form of initializer

The problematic behaviour seems specific to "local" table references. (I mean, the name `rt` to which the table is assigned is local. The table may scope from anywhere.) The following is also run in Maple 17.02,

restart:

f:=proc() local rt,foo,z;
  rt:=table([foo='Vector'(posint)]);
  z:=rt[foo];
  assigned(z);
end proc:

f();
                                     true

@Carl Love In 17.02 the call to Exists produced an error with one pair and returned true with two pairs. In18.01 both cases returned true.

@Mac Dude The need for two pairs of uneval (single-left) quotes around the type in the AddType call, so that Exists would work, seems unnecessary in Maple 18.02.

I didn't try it within ModuleLoad of a saved/loaded package.

I edited the main Question, to reflect product Maple 17.

I set the 'Product" on this Question to Maple 17, since the Asker mentioned that in a followup Comment.

acer

@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