Not only is it shorter code than a call to SubVector, the square-bracket "rtable subindexing" is also the direct kernel access which bypasses slower Library code. SubVector just ends up making an rtable subindexing call itself.

Joe showed the same subsop approach earlier, more simply using rtable subindexing. He just left out the dynamic inference of the Vector's length (and might not have made it into an operator). For that, one might use op(1,V) rather than LinearAlgebra:-Dimension. That syntax is so widely used that I don't imagine it will change any time soon.

acer

There are two kinds of mutability to consider. Changing an element's value, and changing the size of the structure.

For changing the value of an element, a Vector is often preferred over a list because substituting values into a position of a list involves creation of a whole new list. It is an inefficient use of memory, producing garbage that must be collected. This gets worse as the structure gets large. (It doesn't matter whether one uses subsop, or assigns directly to a list of length <=100.)

For changing the size of the structure, as when entries are removed altogether, using a table can be preferable over using either a Vector or a list. In this case one can avoid the creation of  both new Vector and list final objects (and several intermediary objects, if not done carefully). Again, this can matter more if the size of the structure is very big and if the entries need to be removed one at a time.

> A := Vector[row]([2, 10, 5, 7]);
                              A := [2, 10, 5, 7]
 
> At:=convert(A,table);
                  At := table([1 = 2, 2 = 10, 3 = 5, 4 = 7])
 
> unassign('At[2]');
> eval(At);
                         table([1 = 2, 3 = 5, 4 = 7])

You may be able to remove entries from table At more efficiently (for a very large object).

There are a few ways to convert the final reduced table back to a Vector (perhaps depending on whether you keep track of how many entries are removed).

> Vector[row]([seq(At[op(i)],i in indices(At))]);
                                   [2, 5, 7]

acer

There are two kinds of mutability to consider. Changing an element's value, and changing the size of the structure.

For changing the value of an element, a Vector is often preferred over a list because substituting values into a position of a list involves creation of a whole new list. It is an inefficient use of memory, producing garbage that must be collected. This gets worse as the structure gets large. (It doesn't matter whether one uses subsop, or assigns directly to a list of length <=100.)

For changing the size of the structure, as when entries are removed altogether, using a table can be preferable over using either a Vector or a list. In this case one can avoid the creation of  both new Vector and list final objects (and several intermediary objects, if not done carefully). Again, this can matter more if the size of the structure is very big and if the entries need to be removed one at a time.

> A := Vector[row]([2, 10, 5, 7]);
                              A := [2, 10, 5, 7]
 
> At:=convert(A,table);
                  At := table([1 = 2, 2 = 10, 3 = 5, 4 = 7])
 
> unassign('At[2]');
> eval(At);
                         table([1 = 2, 3 = 5, 4 = 7])

You may be able to remove entries from table At more efficiently (for a very large object).

There are a few ways to convert the final reduced table back to a Vector (perhaps depending on whether you keep track of how many entries are removed).

> Vector[row]([seq(At[op(i)],i in indices(At))]);
                                   [2, 5, 7]

acer

I believe that it is a crossbreed. Some Mathematica code can be pretty much translated to Maple code which doesn't rely on the MmaTranslator to subsequently run. And some code cannot be fully treated that way. (And some code cannot be translated at all. But you seem prepared for some of that.)

I suspect that it depends on what sort of computations one is doing. I would guess that symbolic manipulation, special functions, ode solving, etc, get mostly translated, while i/o (like your Get example) might get "converted" instead.

Perhaps you might let us know, how you get on in practice.

acer

I believe that it is a crossbreed. Some Mathematica code can be pretty much translated to Maple code which doesn't rely on the MmaTranslator to subsequently run. And some code cannot be fully treated that way. (And some code cannot be translated at all. But you seem prepared for some of that.)

I suspect that it depends on what sort of computations one is doing. I would guess that symbolic manipulation, special functions, ode solving, etc, get mostly translated, while i/o (like your Get example) might get "converted" instead.

Perhaps you might let us know, how you get on in practice.

acer

This change to the hover-over (tooltip, bubble-help) for the subliteral entry on the Layout palette is a behaviour regression bug (mistake) that should be reverted.

acer

This change to the hover-over (tooltip, bubble-help) for the subliteral entry on the Layout palette is a behaviour regression bug (mistake) that should be reverted.

acer

Ah, yes, I see that I was not paying enough attention to the actual problem specifics. Thanks.

acer

Ah, yes, I see that I was not paying enough attention to the actual problem specifics. Thanks.

acer

Raising Digits may affect which local max NLPSolve attains for the bivariate problem, but if that then gets the global max (in a range) it is likely "by luck". It's still using a solver which only promises a local max.

Alec's demonstration of using the symbolic `maximize` rather that the numeric `NLPSolve` is nice here.

Of course, quite often a multivariate expression will not be a product of univariate expressions, nor will the symbolic `maximize` always be able to find an explicit solution. In general, finding a numeric global max of a multivariate expression is not so easy (especially without the GlobalOptimization add-on, which itself can require fiddling with options).

acer

Raising Digits may affect which local max NLPSolve attains for the bivariate problem, but if that then gets the global max (in a range) it is likely "by luck". It's still using a solver which only promises a local max.

Alec's demonstration of using the symbolic `maximize` rather that the numeric `NLPSolve` is nice here.

Of course, quite often a multivariate expression will not be a product of univariate expressions, nor will the symbolic `maximize` always be able to find an explicit solution. In general, finding a numeric global max of a multivariate expression is not so easy (especially without the GlobalOptimization add-on, which itself can require fiddling with options).

acer

You haven't added any more detail of what you expect to be done for the lengthier expressions.

By "characterize" I meant something like giving an explicit description. I don't see a pattern in your lengthy expression (involving kc,dn, etc) that matches the much shorter examples involving x1,x2,x,y,etc. In particular, you may wish to clarify what you mean by terms being relevent (or not) to the factorization. (You may find that hard and it might even be that recourse to a stated goal of simplification to an end-pattern, or simplification by length, is easier. If so, then the pattern might be spelled out by you much more clearly.) But maybe I am just being slow.

acer

You haven't added any more detail of what you expect to be done for the lengthier expressions.

By "characterize" I meant something like giving an explicit description. I don't see a pattern in your lengthy expression (involving kc,dn, etc) that matches the much shorter examples involving x1,x2,x,y,etc. In particular, you may wish to clarify what you mean by terms being relevent (or not) to the factorization. (You may find that hard and it might even be that recourse to a stated goal of simplification to an end-pattern, or simplification by length, is easier. If so, then the pattern might be spelled out by you much more clearly.) But maybe I am just being slow.

acer

The first step is easy enough to accomplish. I hadn't bothered to post it because, easy as it is, I don't see how it assists in the final goal.

> map(normal,collect((x^2+2*x+1+y)/(x+1)^2,y));
                                    y
                                 -------- + 1
                                        2
                                 (x + 1)

The final goal doesn't seem to be clearly characterized (to me, at least).

acer

The first step is easy enough to accomplish. I hadn't bothered to post it because, easy as it is, I don't see how it assists in the final goal.

> map(normal,collect((x^2+2*x+1+y)/(x+1)^2,y));
                                    y
                                 -------- + 1
                                        2
                                 (x + 1)

The final goal doesn't seem to be clearly characterized (to me, at least).

acer