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

Supply the simple bounds on variables like so (when using "expression form"),

GlobalSolve(..., Kguess[1]=3..17, Kguess[2]=19...27 );

The [bl,bu] option is related to the "operator form" (which you're no longer using). Replace those numbers such as 3,17,etc with your known bounds.

With such positive bounds supplied, the assume=nonnegative option should not be necessary.

acer

Supply the simple bounds on variables like so (when using "expression form"),

GlobalSolve(..., Kguess[1]=3..17, Kguess[2]=19...27 );

The [bl,bu] option is related to the "operator form" (which you're no longer using). Replace those numbers such as 3,17,etc with your known bounds.

With such positive bounds supplied, the assume=nonnegative option should not be necessary.

acer

I believe that {..} curly braces are required around the constaints, so that they get passed as a set (even when there is just a single constraint).

acer