@vv 

Oops ... I forgot that LeastSquares doesn't make assignments to the coefficients (which would implicitly create a table). So you are right; this example is no good.

@Markiyan Hirnyk 

I have never used AudioTools! After I wrote my previous post, I remembered that one might want to do something like

CurveFitting[ LeastSquares ]( x_vals , y_vals , x , curve = add( c[j] * x^j , j = 0 .. 10 ) ) ;

which implicitly uses a table. So I should have written that the book doesn't contain any applications of arrays or tables that don't involve programming, and whilst such applications do exist, I still prefer to defer the material to the section on programming.

@Markiyan Hirnyk 

I agree that it makes sense to consider all the main container structures together in a comprehensive reference manual such as the Programming Guide.  However, I take a different view for Understanding Maple.  Users need to know about lists and sets to do all kinds of things, so these must be considered in chapter 2.  On the other hand, I can't think of any applications for arrays or tables that don't involve programming. Were I to discuss arrays and tables in chapter 2, readers (who may be quite inexperienced at this point) would have to plough through some rather tricky material, only to find that none of it is used until much later in the book. This would be off-putting in my opinion.

@Scot Gould 

I did consider including a 'traditional' index, but I came to the conclusion that it wouldn't add much that isn't provided by the index of Maple Notation and the Table of Contents. Please let me know if your students report difficulties finding information in the book.  If the lack of a traditional index causes a widespread problem I will produce one and make it available for download (and add it to any future editions).

Should there be a chapter on statistics? I tried to limit the book to material that is central to understanding Maple, and material that a large majority of users are likely to need. I don't think statistics would fall into the first category, but one could argue that a large majority of users will need it, especially since many science undergraduates take one or more statistics courses in their first year. On the other hand, I don't know how widely Maple is used for statistics. There wouldn't be much point adding a chapter on this if statisticians all prefer R or minitab.

Finally, I think single ditto operators are relatively harmless in simple situations. Also, in my experience, Maple users tend to use shortcuts such as this even if they are advised not to, especially if they can't see an immediate problem with what they are doing. If I took a 'hard line' approach, and suggested that ditto operators should be avoided, then I'm afraid my advice might be ignored. Instead I decided to use ditto operators in some of the shorter examples, but to steer clear of them in more complex situations (e.g. I don't think I ever used one inside a procedure), in the hope that readers might see that it's in their best interests to do the same.

P.S. Limits show up in applied mathematics all the time!

@taro 

Could you elaborate on your comment about the book being difficult to read in places? Which sections are you referring to? How do think they could be improved?

@Markiyan Hirnyk 

I'd like to think that Understanding Maple is a bit more than 'one more introduction'. It's difficult to give a list of the material it contains that introductory guides tend not to cover, but one way to test this is to think of some things you (or your students) found confusing when first learning Maple, and ask whether Understanding Maple (or another book) resolves them. I could probably list a hundred issues that used to drive me crazy. Here are a few:

• Why can't I use the result of a previous calculation to define a functional operator as follows?

  int( 1 / ( 1 + x^2 ) , x ) ;
f := x -> % ;

• Why doesn't the following statement produce a numerical approximation?
  
  int( evalf( exp( x ) ) , x = 0 .. 1 ) ;


• Why does evalb return false in the following?

  A := Matrix( 2 ) ;
B := Matrix( 2 ) ;
evalb( A = B ) ;

• What are the circumstances under which parameter values can/cannot be changed from within a procedure?

Finally, could you elaborate on the comment 'The sections "Arrays" and "Tables" in "Programming" chapter look strange.' I will compile a list of suggestions for improvements that can be made in future editions, but I'm not sure what you mean by this.