It's great that you had fun programming it.

I hope it's ok to comment. Instead of loading the packages outside of the procedure body using `with`, it would be better form to utilize the `use` or `uses` functionality inside the procedure body.

acer

It's great that you had fun programming it.

I hope it's ok to comment. Instead of loading the packages outside of the procedure body using `with`, it would be better form to utilize the `use` or `uses` functionality inside the procedure body.

acer

See here for a note on this.

acer

See here for a note on this.

acer

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

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