@Joe Riel Hi Joe, might your response about saving a compiled procedure be a good candidate for Branch to New Post?

@Joe Riel Hi Joe, might your response about saving a compiled procedure be a good candidate for Branch to New Post?

@Joe Riel Joe, I'd label applying the subsindets version onto such examples as user error, not a code bug. It's just obviously the wrong tool for the job, isn't it?

I'd accept the idea, that the discussion heretofore was about examples where the intended deepest entries were numeric, say. I think that it's reasonable to suppose that this is about code for some known situation, if not that particular one.

Look at the first suggestion, map(op,L). That was clearly only intended for the known case that L was a list (or maybe a set), as it doesn't do much good when applied to all kinds of piecewise or other structure instead.

And isn't that what happens so often in practice? One writes code in which a given, inner situation is known. There's no need to take the performance hit to check the deep typing of list L. But for L of a given type (which one's own known code might well have produced its very self) some faster method may apply.

Isn't coding like that one possible ideal, in the absence of an optimizing symbolic compiler?

That's why I think that the subsindets version is notable. For a known and commonly occuring class, it is quite a bit faster.

acer

@Joe Riel Joe, I'd label applying the subsindets version onto such examples as user error, not a code bug. It's just obviously the wrong tool for the job, isn't it?

I'd accept the idea, that the discussion heretofore was about examples where the intended deepest entries were numeric, say. I think that it's reasonable to suppose that this is about code for some known situation, if not that particular one.

Look at the first suggestion, map(op,L). That was clearly only intended for the known case that L was a list (or maybe a set), as it doesn't do much good when applied to all kinds of piecewise or other structure instead.

And isn't that what happens so often in practice? One writes code in which a given, inner situation is known. There's no need to take the performance hit to check the deep typing of list L. But for L of a given type (which one's own known code might well have produced its very self) some faster method may apply.

Isn't coding like that one possible ideal, in the absence of an optimizing symbolic compiler?

That's why I think that the subsindets version is notable. For a known and commonly occuring class, it is quite a bit faster.

acer

What exactly is meant, when you write that you cannot simplify the piecewise under assumptions, "...because that value of q[S] is still dependent of another variable"? Why can't that other variable be included in the assumption(s), and the assumption(s) be whatever is need to trigger a given conditional (but no conditional earlier in the piecewise)?

acer

What exactly is meant, when you write that you cannot simplify the piecewise under assumptions, "...because that value of q[S] is still dependent of another variable"? Why can't that other variable be included in the assumption(s), and the assumption(s) be whatever is need to trigger a given conditional (but no conditional earlier in the piecewise)?

acer

@Alejandro Jakubi That's really helpful, Alejandro. Thanks.

@jakubi 

Without preserved nesting and order of all the comments to a post, a lot or real value is lost.

I'd like to hear that it's going to be corrected, as an automatic sweep throught the new site. It's even more important than the related issue of whether the formatting of earlier posts will be fixed (all crammed into one run-on paragraph).

And the same is true for Questions: Just because more highly up-voted Answers rise to the top should (ideally) not mean that the comments nested underneath them get their order and placement mangled.

Which reminds me: the mechanism for submitting nested comments is erratic. I always click the link for a previous comment or Answer on which I want to reply further. And the system certainly knows something of what I want, because it inserts a @name for the author to which I'm responding further. But only sometimes does my comment get nested (indented, or whatever you want to call it). It's frustrating, and I believe that I'm being careful enough to be attempting it properly. (Also, for comments on Posts -- not Questions or Answers -- why doesn't the "Parent" drop-down choice appear?)

acer

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

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