You can extract operands in a few ways. One way is to use op (again, or repreatedly). Another way is to index into a partial result by postpending with [] or [1] where legitimate. Or you can mix your approaches, if a structure is more deeply nested.

 PiecewiseTools:-ToList is an undocumented routine, which would probably help you only as much as op and others.

@epostma You mentioned that, "The defaults for start and end of a range in indexing are always the minimum and maximum valid values." But it's not always true that we can use `..` instead of `1..-1` if it's not true in Maple 11, is it?

@epostma You mentioned that, "The defaults for start and end of a range in indexing are always the minimum and maximum valid values." But it's not always true that we can use `..` instead of `1..-1` if it's not true in Maple 11, is it?

@epostma Thanks for the redundancy tip. I was probably thinking (incorrectly) about situations I'd see in the past in which it was desirable to override all of m, m^2, and m^2 to get (say) cm as a new default for use in all of length, area, and volume. But as you note, in this case the dimension is the same.

While we're discussing it, would it be possible to make this easier? Pretty much the only time I see use of AddSystem, GetSystem, and UseSystem is to override the base unit for output of a dimension. And that same question comes up sort of regularly. Couldn't there be an easier syntax for it, maybe just one single command that does all the tasks (quietly) of grabbing, altering, and installing the systems?

@epostma Thanks for the redundancy tip. I was probably thinking (incorrectly) about situations I'd see in the past in which it was desirable to override all of m, m^2, and m^2 to get (say) cm as a new default for use in all of length, area, and volume. But as you note, in this case the dimension is the same.

While we're discussing it, would it be possible to make this easier? Pretty much the only time I see use of AddSystem, GetSystem, and UseSystem is to override the base unit for output of a dimension. And that same question comes up sort of regularly. Couldn't there be an easier syntax for it, maybe just one single command that does all the tasks (quietly) of grabbing, altering, and installing the systems?

@JacquesC A 2DMath corollary might be: don't mix subscripted names and their non-subscripted base name in the same expression (since by default subscripted names are indexed names).

@JacquesC A 2DMath corollary might be: don't mix subscripted names and their non-subscripted base name in the same expression (since by default subscripted names are indexed names).

@otherworld314 Keep in mind that computing the pade approximation (or other numapprox'imations) can involve much more computation work than simply doing the numerical quadrature. For the most part, if numercial integration done just once within a given range is what you want then numapprox is the wrong tool.

@otherworld314 Keep in mind that computing the pade approximation (or other numapprox'imations) can involve much more computation work than simply doing the numerical quadrature. For the most part, if numercial integration done just once within a given range is what you want then numapprox is the wrong tool.

This seems to work (as does Alejandro's suggestion):

> `expand/.`:=proc() subs(`&*`=`.`,expand(`&*`(args))); end proc:

> PE := A.X+B.U+L.(Y-C.X-D.U);
            PE := (A . X) + (B . U) + (L . (Y - (C . X) - (D . U)))

> expand(PE);
          (A . X) + (B . U) + (L . Y) - (L . (C . X)) - (L . (D . U))
 
> lprint(%);
A.X+B.U+L.Y-(L.C.X)-(L.D.U)

> expr:=a.(b+c);
                              expr := a . (b + c)

> expand(expr);
                               (a . b) + (a . c)

I wonder if there might be something in Ore_algebra that could be turned to that right-collecting job.

This seems to work (as does Alejandro's suggestion):

> `expand/.`:=proc() subs(`&*`=`.`,expand(`&*`(args))); end proc:

> PE := A.X+B.U+L.(Y-C.X-D.U);
            PE := (A . X) + (B . U) + (L . (Y - (C . X) - (D . U)))

> expand(PE);
          (A . X) + (B . U) + (L . Y) - (L . (C . X)) - (L . (D . U))
 
> lprint(%);
A.X+B.U+L.Y-(L.C.X)-(L.D.U)

> expr:=a.(b+c);
                              expr := a . (b + c)

> expand(expr);
                               (a . b) + (a . c)

I wonder if there might be something in Ore_algebra that could be turned to that right-collecting job.

@Will By far the most tags have been set during the automatic import process, and the heuristic for it looks weak. So that Popular Tags list is not useful -- just a collection of pretty generic items. It doesn't reflect much of anything, except possibly that the automatic tagging was too general.

Who is going to want to pop a tag named "equations", or "list", or "input" when doing so matches so many posts quite indiscriminately? (38, 37, and 33 pages of results, respectively.) Compare with popping some of the tags recently deliberately used by members, by hand, such as "performance", or "optimization"?

If the list currently on the Popular Tags pane never much changes, because it is weighted by so much cruft, then it's not useful.

The top bar is now too crowded with items that just slice and dice views of all postings.

Now there are menu bar items "Questions", "Posts", and "Products" (not to mention "Unanswered" and "Recent", which really are conceptually in a same parent category: views of postings). It would be better if some parts of this view functionality were rolled together in the menu.

Now, the menu has become overcrowded and more confusing. The apparent/surface-class similarity of all those view choices makes it more work for someone to decide which is wanted. It's noisy.

And, more importantly, it's pushed the "Tags" item off the bar in the direct sense, by relegating it to the "More" drop-down. But "Tags" is much more of a distinct concept.

The menu bar should contain distinct functionality items. But instead the menu bar has become more cluttered with items too close in meaning/functionality, while truly independent functionlity has been pushed to the sideline. Five out of eight items on that menu bar are now for view slices, while useful items like Tags are buried. It's overkill.

@Christopher2222 There's now a voting mechanism for expressing your approval of the ideas in a post.

@jakubi I really enjoyed the prior blog entries made here. I'm referring here to the ones made by regular members, not the maplesoft blog items. They often led to interesting technical discussion or insight, or contained some refreshing views on Maple functionality. I'm thinking of blog entries made by Darin, Joe, Axel, Roman, and several others.

It's harder to find them now, or view them collectively as they are all mixed up with, or dominated by, more day-to-day Posts about mapleprimes, errors, etc, even within all-posts-by-a-member views.

If this site gets advanced Search facilities (boolean tag querying, or mixed tag+keyword searching) then it might become easy to create a custom search. (Could we be able to save it as a bookmark?)

Please let me reiterate that tags are much more useful for searching than keywords. A post could contain a sentence fragment like "this, of course, if the opposite of a numeric technique". And then a keyword search on "numeric" would unfortunately include that post in the flood of hits. But presumably it would not also have a "numeric" tag, so a tag-search on "numeric" would fortunately miss it. That's just a simple example.