1. You can display the examples in a help page using either 1-D math or 2-D math by checking/unchecking the entry View->Display Examples with 2D Math or clicking the right-hand icon in the toolbar on the help page.
2. If the examples in the help page are displaying in 1-D math, then when you click the "Open the Current Page Page in a Worksheet, then the examples ought to remain in 1-D math

If your function F is not F(x(u), y(u)), but is the more general F(x(u), y(u), u) then you may need

diff(F(x(u), y(u), u), u);

and once again you are going to have to explain very clearly and carefully exactly why this does not provide the answer you want.

You are going to have to explain very clearly and carefully exactly why

diff(F(x(u),y(u)), u);

does not provide the answer you want.

Now how could I have missed that??

thx

When I first had a look at this problem, I came up with a "solution" which was (sort of) the "inverse" of acer's, namely

nel:=x->`if`(type(x, name), 0, numelems(x));

which seemed to do the required thing for the following cases

nel([1,2,3]);
nel(a);
nel(3);
nel(a+b);

I don't now remember why - but I wasn't happy, so I didn't post it and went to bed.

It was only when I saw Carl's solution that I decided to revisit, and translating my original code to an overload procedure gave me

restart;
unprotect(numelems);
numelems:= overload
                   ( [  proc(x::name) option overload;
                        0
                        end proc,
                        numelems
                   ] ):

This *appears* to give the 'correct' answer for

numelems([1,2,3]);
numelems(a);
numelems(3);
numelems(a+b);

This gave me a problem with Carl's code, in that I really didn't undrstand  the

&under (C-> eval(C))

part, and if/why it is necessary. The C->eval(C) is simple to understand, but I really don't get the &under part at all. Maybe if someone could tell me for which type of argument my simple-minded overload gives a different answer from Carl's, I'd understand why this extra piece of code was desirable (or even necessary)

Try

s:=t->5*sqrt(t);   # define function s(t)
solve( s(t)=2, t);  # find t-value for which s(t)=2

But two entries for your list (based on my own machine)

• Works
• Windows 7 home 64 bit
• Maple 18.02
• Java Version 8 Update 60 (build 1.8.0_60-b27)
• Works
  • Windows 7 home 64 bit
  • Maple 2015.1
  • Java Version 8 Update 60 (build 1.8.0_60-b27)

I've tried looking for common factors in your list (together with my own machine behaviour), and can't see anything obvious which might cause your original problem :-(

The "explanation" I gave above is complete rubbish, which you can verify by trying

`if`(2<Pi, 0, 1);

Unambiguous, but still does not return the "expected" answer. The real explanation would seem to be (from the evalb() help page), that

An evalb call using <, <=, >, or >= returns evaluated only with arguments of type extended_numeric or complex.

Neither Pi, nor sqrt(5) are of the required type.

I assume that the same restriction applies to the Boolean relation which is the conditional expression of an 'if' construct. Thus the conditional expressions 2<Pi, 2<sqrt(5) in the if-statement will not be evaluated

The solution would seem to be to perform some operation on the conditional expression which "forces" the type conversion - so

`if`(2<evalf(Pi), 0, 1);

would work. So also does

`if`(is(2<Pi), 0, 1);

You have two machines

1. both running 64-bit win7
2. both running Maple 18.02
3. both running Java Version 8 Update 60 (build 1.8.0.60-b27)
4. and the requisite files to be converted exist in the same place which is the default directory for both of the Maple installations
5. and you get different answers???!!!

Actually there are three machines in this problem - mine and two of yours.

Mine and one of yours produce the require solution correclty

One of yours barfs: from this I can only draw two conclusions

1. the two machines which you think are identical - are not: however much you want to believe they are identical, they can't be
2. not sure I can help much, cos like I said before everything on my machine just works seamlessly, which means I can't replicate the problem and so my debug capability is almost non-existent

If you do manage to figure out the problem - post it here cos I'd like to know!

@Damon 

Replace the final statement

Eq4 := sum(sum(delta[i] . delta[j], j = 1 .. 3), i = 1 .. 3);

with

Eq4 := add(add(delta[i] . delta[j], j = 1 .. 3), i = 1 .. 3);

and everything should work as you expect (although in this instance I'm not quite sure why the sum formulation didn't work). Probably because it tried to produce a closed-form solution for the double sum, before evaluating the individual terms in the double-sum. Generally, when the individual terms in the sum can be calculated and there is a numerically-known number of terms, it is safer to use add() rather than sum()

@Damon 

In general sum() will attempt to compute a "closed-form" solution for a given problem, so for example, sum(j, j=1..n) will compute n*(n+1)/2 and if a numeric value for n is given, it will evaluate the result - so sum(j, j=1..10) will compute 10*(10+1)/2 and then evaluate this to 55.

add() just 'adds' so add(j, j=1..10) is equivalent to 1+2+3+4+5+6+7+8+9+10, which will evaluate to 55

There are situations which either can be used - and some situations where you have to pick the "right" one

BTW - can't see any attachment

I'm planning on updating to win10 in the near future -so I'd be interested in hearing about any Maple-related issues.

Good Luck

Question. What is the exact difference between sort and collect. why do they work differently.

There is no simple. meaningful answer to this question.

Rather obviously sort() will 'sort' things (such as list of numeric values, strings etc) which simply have no meaning as arguments to 'collect'.  So the range of applicability of sort() is much wider than collect(). However, in general, both will do *something* when given a general polynomial as an argument, so the following is restricted to this case.
Even for polynomials you should always bear in mind that Maple stores these essentially in the order that the terms are created - you should never assume that they are either "sorted" or "collected". The basic behaviour on a (possibly multivariate, assumed uncollected, assumed unsorted) polynomial is that sort() will 'sort' without collecting, and collect() will 'collect' without sorting - so it is quite common to use sort( collect(f, x) ) to 'collect' first and then 'sort'
Another significant difference is that collect() will first of all 'expand' its argument into a sum-of-powers, and then gather coefficients of like powers: sort() will only 'sort' the given expression without doing (even obvious!) manipulations

For example, if you define g:=(x+2)^2+(x+1)^3; then try sort(g, x), the 'sort' will do essentially nothing, since (as far as sort() is concerned) g contains no terms in x on which to 'sort', whereas collect(g, x) will first expand the expression in to a sum-of-powers, and collect appropriately

When you create the function

subs(n=i,ODE)*subs(n=j,W)

it has  some serious discontinuities (even for i=1, j=1) which you can verify by adding

fn:=subs(n=1,ODE)*subs(n=1,W):
plot( fn, r=k*a..a);

to your code: this just demonstrates that the integrand is "ugly" and Maple in fact refuses to integrate it. Before I look at "clever" methods which might (or might not)  be successful in performing the integration, I'd like to confirm that you expect to be integrating a function with such serious discontinuities

I have just double checked this in Maple 2015.1 and Maple 18.02. In both versions the command sequence

with(eBookTools);
book := NewBook("eBookSample", "eBook Sample Book", "Maplesoft, a division of Waterloo Maple Inc.", "2012");
AddChapter(book, "legal", cat(kernelopts('datadir'), "/eBookTools/Legal.mw"));
AddChapter(book, "preface", cat(kernelopts('datadir'), "/eBookTools/Preface.mw"));
AddChapter(book, 1, cat(kernelopts('datadir'), "/eBookTools/GettingStartedWithMaple.mw"));
CreatePDF(book);

produces the output

eBookSample.pdf

in my default directory, ie  C:\Users\TomLeslie\My Documents\eBookToolsOutput, with errors or warning messages of any kind. This file is reasonably complicated, but (as far as I can tell) correctly formatted.

Therefore first question - what Maple version are you running?? (Anything other than 18.02 or 2015.1 and I probably can't help much)

However if you are running either of these versions, and you still have problems - then there is obviously something different in out basic installation: so my installation details ( are you different, if so where ?)

1. I am running windows7 64-bit - I install all important updates
2. the above code uses the files "Legal.mw", "Preface.mw", and "GettingStartedWithMaple.mw". I have double-checked and these  files all exist in the directories C:\Program Files\Maple 2015\data\eBookTools and C:\Program Files\Maple 18\data\eBookTools.  Do you have the same files in the same directories?
3. Which java version are you running? I am using Version 8 Update 60 (build 1.8.0_60-b27)