There are effective differences between these,

flat := a->`if`(type(a,list), op(map(procname,a)), a):

flat2 := x -> [subsindets(x,list,t->op(t))]:

In cases of extreme nesting there could be tie-in with stacklimit, for the recursive call. And indeed the recursive method fails after hitting the recursion limit. For very deep nesting the subsindets may succeed, but only so slowly as to be useless.

> Z:=(`[]`@@17229)(7,8):

> st:=time(): ans1:=[flat(Z)]: time()-st; # very fast
                                    0.219

> Z:=(`[]`@@17230)(7,8):

> st:=time(): ans1:=[flat(Z)]: time()-st;
Error, (in flat) too many levels of recursion
                                    0.172

In case you are wondering about ListTools:-Flatten and deeply nested lists,

> st:=time(): ans1:=ListTools:-Flatten((`[]`@@59059)(7)): time()-st;
                                    1.904

> st:=time(): ans1:=ListTools:-Flatten((`[]`@@59060)(7)): time()-st;
Error, (in ListTools:-Flatten) too many levels of recursion
                                    1.528

I'm leaving out half the story, throughout, which is memory allocation increases by different methods.

For a simple list of many lists of lists (ie. shallow nesting with many children, and IMO likely the more common case), the comparative performance situation can look quite different

> Z:=[seq([[7,8]],i=1..100000)]:

> st:=time(): ans1:=[flat(Z)]: time()-st;
                                    2.527

> st:=time(): ans2:=flat2(Z): time()-st;
                                    0.187

> st:=time(): ans3:=ListTools:-Flatten(Z): time()-st;
                                    2.293

This was all in Maple 13.01 on Windows XP.

acer

By coincidence, now that the Mapleprimes Search facility has improved, I was thinking about sieving this site and collating all the requests for abstract linear algebra. Maybe that would help in the decision making.

The question comes up (with slightly differing functionality aspects, naturally) pretty regularly.

I have made some very modest efforts into this area. But they are very rough (in a backlog of unfinished prototype side-projects). So I doubt they would be of use to anyone, as is.

Part of the problem is knowing where to start. Collating the particular functionality requests seems like one reasonable place to begin. It's tempting to ask, "Ok, how do I lay down a comprehensive set of requirements, up front?" But if the horizon is too vast, that can be an impediment to making any headway. I asked a colleague, expert in programming, what one can do in extreme situations. The answer was that one way is to collect a smaller, manageable set of individual tasks, and see what would be required to solve them individually.

The technical question, of how to represent an abstract Matrix, is interesting. In the past, I've briefly looked at attributes on names, `is` and assumptions, and even modules or records. It's quicker to get going simply with attributes on names, but these days I'm leaning more toward modules or similar (despite their rather heavy nature).

On a forwards thinking note, I saw this the other day. Wouldn't it be nice to be able to do the same in Maple. (This looks like an impressive use of it.)

acer

If you expect to use a `simple' piece of code many times, inside some other procedures, then you might not want to take the performance hit of extra function calls just to get that simple code to run inside some parent procedure.

Maple function calls can be (relatively) expensive, so wrapping just a tiny code fragment inside a proc can have a measurable cost. For such reasons, the `option inline` exists for procedures. Compare the body of computational routine `f` below, when `Centroid` does or does not have option inline.

The idea is that `f` might do a long computation which calls `Centroid`many times. You can ignore the T stuff, and focus on the last part of the body of `f`, where the centroid computation takes place.

Notice in the printed 2D output below how the body of the second version of `f` has the centroid code inlined into it, avoiding the overhead cost of the function call to `Centroid`.

> Centroid:=proc(L) `+`(op(L))/nops(L) end proc:

> f:=proc()
  local T;
  T := [[1,2,3],[4,5,6],[8,9,10]];
  Centroid(T);
end proc;

   f := proc () local T; T := [[1, 2, 3], [4, 5, 6], [8, 9, 10]]; Centroid(T) end proc

> f(); # it works
                          [13  16  19]
                          [--, --, --]
                          [3   3   3 ]

> Centroid:=proc(L) option inline; `+`(op(L))/nops(L) end proc:

> f:=proc()
  local T;
  T := [[1,2,3],[4,5,6],[8,9,10]];
  Centroid(T);
end proc;

   f := proc() local T; T := [[1, 2, 3], [4, 5, 6], [8, 9, 10]]; (`+`(op(T)))/nops(T) end proc

> f(); # it still works
                          [13  16  19]
                          [--, --, --]
                          [3   3   3 ]

BTW, you seem to be suggesting that Maple should have a routine to compute centroids of lists. That notion has, built right into it, the idea that a list represents a point in space. That may be convenient sometimes, but a Vector (usual, or VectorCalculus) might be more useful. I'd agree that the `geometry` package's objects are too unwieldy.

The original versions posted here simply print the result, and return NULL. If that's really what one wants, inside some larger working procedure say, then why not use userinfo?

While I was composing the minor variant, using `+` and `op`, Joe posted the same.

note to admin: I realize now that I should have made this a branch post. Can that be done, after the fact? Thnx.

acer

I buy into the notion that Thread:-Add and friends should be drop-in replacements for their global counterparts, as much as is reasonably possible. As Darin has pointed out, some languages provide the automatic handling of locals that allows examples such as this to work automatically. Why isn't it reasonable to expect that Maple can too?

I'd say that Thread:-Add and friends haven't attained much more than surface usefulness if they are this problematic.

Hence, I call the given example a bug in Threads itself.

acer

@Robert Israel Hi Robert, some time back Doug Meade wanted to be able to distribute a Maplet bundled with image files. He posted about his solution here.

While I'm looking at this thread again, while updating tags on old posts,

1:iolib(34);

acer

@Will On behalf of many of us, Will, let me just say Thanks!

@jakubi Alejandro, thanks for looking. I wonder if yours is the only mapleprimes backup.

Would you be able to say how many responses this thread had, in total, in V.1? In V.2, it currently lists as 13+1 where yours is the 1. (And it'll likely be 13+2 when I submit this.)

Would you be able to show a block quote of a paragraph or a significant, uniquely identifying portion of one of the missing responses?

Thanks,
acer

@Joe Riel Joe, did you mean to format that comment like this?

In html input mode, use &lt; and &gt; to input < and >, respectively. For an ampersand, use &amp;

@Joe Riel Joe, did you mean to format that comment like this?

In html input mode, use &lt; and &gt; to input < and >, respectively. For an ampersand, use &amp;

The Online Help has somehow messed up that example, Alejandro! It's the very last example on ?assuming,details.

In the Online Help page, the result of using assuming is (incorrectly) the same as the result from using assume. They both show as the result a+1.

But the assuming result should be this, instead,

> f := proc(x) sqrt(a^2)+x end proc;
                      f := proc(x) sqrt(a^2) + x end proc
 
> f(1) assuming a>0;
                                    2 1/2
                                  (a )    + 1

I wonder how it goes wrong. (eg. Examples run out-of-order, or a 2DMath effect, or...) I didn't check in the Standard GUI itself.

Your example with attributes is also interesting; that too should be documented as another exception.

acer

Yes, LinearAlgebra:-LeastSquares ought use the thin SVD automatically. It deserves an SCR.

While on these topics, there are also other smaller SVDs possible, with other suitable uses. See here on wikipedia, where they get called "thin", "compact", and "truncated".

In image decomposition such as John has described, one might use a "truncated" scheme where just a (possibly very small) number of singular values and corresponding singular vectors are computed. I believe that this can be done using the NAG routines that are demonstrably present in Maple.

> restart:

> infolevel[LinearAlgebra]:=1:

> LinearAlgebra:-SingularValues(<<4.>>,output=U):
SingularValues:   "calling external function"
SingularValues:   "NAG"   hw_f08kef
SingularValues:   "NAG"   hw_f08kff
SingularValues:   "NAG"   hw_f08mef

One thing puzzles me, though. When the f08kff documentation talks about the leading n columns of Q, in section 3.2, ought that to be rows of Q instead? (Am I missing something?)

I wouldn't altogether brush off using the normal equations, and it's useful that Alec mentioned it. Maybe LeastSquares could offer three schemes -- normal, QR, and thin SVD -- and clearly document their differences.

acer

@Will That is bad news, to read, "We have plans for adding a way for Moderators to curate the best content on the site, it would be more formal than simply adding a tag. "

Moderation, by a select few hand-picked by Maplesoft, is an innappropriate way in which to curate the best content. There are lots of places in which this is described as a community driven site, and where the rating/ranking schemes are described as community driven. But curation of best content by a select Moderation group goes hard against that, and is antithetical to those stated community-driven goals.

Moderation is fine for controlling spam, removing duplicate posts, adjusting wrongly slotted items, keeping the interpersonal tone polite, etc. But it goes against the widely stated site-vision that the best will bubble to the top.

If you really want to foster an arena of free and community-driven contribution then you have to be very careful about controlling it. Keep in mind that the recent mapleprimes redesign of this site has, in effect, brought about a considerable moderating effect by the site adminitration. (Ie, control over how posts are viewed, followed, ranked, and labelled have all been forcibly changed.)

Curation powers based upon reputation may not be perfect, but at least one can trace it back to the community in some way -- because the community assigns the reputation.

Could an admin please convert this Post to a Question, so that we can up-vote djc's answer (which, btw, is of his usual high quality).

Thanks for the explanation, Will. That's pretty much how I myself had understood it as working.

But for me, I often really do want the "all" view, as I find that I keep going back to threads even when they haven't changed. For example, I'll read some posts and questions during the day, perhaps, and want to respond in the evening or the next day. I think that I do that much more often than I respond immediately upon reading. But by then the posts might have scrolled off of the "Active Conversations" view from the main page (and that link is broken, so I can see farther than what's show on the front page). And I want the posts and questions merged together, etc.

The "unread" view is a neat mechanism, and works as I'd guessed. But I find that I regularly want to look at the complete history of the past day or so, regardless of (and unfiltered by) whether I've already viewed some items.

I appreciate all the effort you've put into this site. Thanks for those other fixes and updates and comments you made earlier today, by the way.

acer