I believe that Preben's response is on the right track.

I'm not sure whether the solve help-pages make it clear enough (for systems of multivariate equations) just what is the definition of a solution according to the various possible calling sequences.

I suspect that a working definition of a "solution" to a call like,

    solve( eqs, vars );

is that evaluation at the returned result will satisfy all the equations. (It doesn't matter whether `eqs` are equations, or expressions which are taken to imply equations.)

Now, it may happen that there are other variables present in `eqs` which are not included in `vars`. The given calling sequence of the `solve` command appears to mean that any "solution" will only contain equations whose left hand sides are in `vars`. I didn't find this aspect described in any `solve` help-page, but then also I didn't find anything else like a tight set of definitions of a "solution" to a system of equations according to the various calling sequence possibilities. I will presume that this is an interpretation that agrees with `solve`'s design and behaviour for the remainder of this Comment.

So `solve({eq1,eq2},{d})` would return solutions containing only equations with `d` on the left hand side.

For the given example no single equation of the form `d=expr` can (by itself alone) satisfy both `eq1` and `eq2`. Or, more generally, it may be that no set consisting only of equations like var[i]=expr[i] for var[i] in `vars` would satisfy all equations in `eqs`.

In that case `solve` would return NULL, as no equation d=expr alone can satisfy both equations.

Consider the output from,

restart;

eq1:=s=a+b+c+d:
eq2:=s=2*(a+b)*(a+c)*(b+c):

eliminate({eq1,eq2},d);

      [                      /        2        2                    2
      [{d = s - a - b - c}, { -s + 2 a  b + 2 a  c + 4 a c b + 2 a c 
      [                      \                                       

                2        2          2\ ]
           + 2 b  a + 2 b  c + 2 b c  }]
                                     / ]

The first element of that output is of the form `d=expr`. Notice that `s` is not free in the (only) expression (implying an equation set to zero) in the set as the second entry of that output. This means that `solve({eq1,eq2},{d,s})` is a quite different request than is `solve({eq1,eq2},{d})`. Having the expression (in the set appearing as the second entry) in the above result from `eliminate` equal zero implies that `s=function_of_abc`. I see the second entry in the above result from `eliminate` as another way of encapsulating the notion that no single equation `d=expr` can alone satisfy both `eq1` and `eq2`, as there is a algebraic relationship amongst a,b,c, and s which does not involve d.

But if all this is correct interpretation then there is a useful bit of functionality missing from the `solve` command. It is the ability to force a non-trivial RHS in the equation `d=expr` in a result from calling `solve`. Let's suppose that you wish to avoid solutions containing `d=d`, if possible. If you simply invoke `solve(eqs)` and leave out the `vars` then there may be some choice of which variables appear in the solution trivially like `var[i]=var[i]` (as if they were parameters, say). One might want to specificy in a call to the `solve` command that `d=expr` appears with `expr` not identical to symbol `d`, and that any other variables could be inserted into the "solution" that would allow all original equations in `eqs` to be satisfied. If there were a choice as to what else to eliminate then `solve` might programmed choose. Eg. `s` might be chosen in the given example because doing so provides a simple explicit solution.

Why do I feel like this has been discussed before?

acer

@Carl Love You extracted arguments to the calls to sqrt, which you assigned to s1, s2, and s3, without using Maple. It was not a solution done entirely in Maple. You could have automated that step of extraction of `sqrt` arguments, but still it would rely on your mathematical knowledge of what makes the objective nonreal -- ie. what makes its imaginary part nonzero. Your mathematical knowledge and use of the domain of `sqrt` was indeed applied on top of what Maple did. It was mental consideration of what made Im(objective)=0 true.

I don't have any issue with that. And in the context of Patrick's consideration of a typical "student" it should certainly not be considered as arcane knowledge. But an additional mathemtaical process it was, indeed.  That bears on the general applicability of your methodology to other examples, possibility not involving sqrt but with the same kinds of difficulties.

@Carl Love You extracted arguments to the calls to sqrt, which you assigned to s1, s2, and s3, without using Maple. It was not a solution done entirely in Maple. You could have automated that step of extraction of `sqrt` arguments, but still it would rely on your mathematical knowledge of what makes the objective nonreal -- ie. what makes its imaginary part nonzero. Your mathematical knowledge and use of the domain of `sqrt` was indeed applied on top of what Maple did. It was mental consideration of what made Im(objective)=0 true.

I don't have any issue with that. And in the context of Patrick's consideration of a typical "student" it should certainly not be considered as arcane knowledge. But an additional mathemtaical process it was, indeed.  That bears on the general applicability of your methodology to other examples, possibility not involving sqrt but with the same kinds of difficulties.

Can one unprotect `series`, assign it to MultiSeries:-series, and then call `residue`?

acer

Can one unprotect `series`, assign it to MultiSeries:-series, and then call `residue`?

acer

I did not really need to use plots, in my approach using Optimization:-Maximize. If you read Carl's, Markiyan's, and my answers you can see similarities in the approaches. I'f I'm not mistaken, we all relied on using Im(objective)=0 as extra known information (eg. as constraint, or constraints plural). Carl used exact `maximize`, Markiyan used the add-on DirectSearch package, and I used the Optimization package.

The feasible set ends up being (the union of) three disjoint line segments, and the answer is the largest of the maximum for each. Not all the approaches listed had to examine those separately, or even explicitly.

Feasible sets which have measure zero (in the domain to be searched) can be hard for optimizers.

Carl got nice exact results. It might seem that his code relies of inspection of the objective, and manual extraction of the three extra conditions. But it should be simple to automate that, so I do not consider it a flaw. Note the helper proc that he wrote, though. Markiyan's answer (improving on what he might have reported as tried in his original Question) is very simple and straightforward. My approach worked harder and was most complicated, generating a set of "simple" extra constraints so as to get multiple calls to local `Maximize` over the finite collection of candidate regions. (There is obviously stuff for Optimization to learn from DirectSearch's way of handling such domains, and I accomodated an inequality->range conversion to get coverage of all the feasible domain.)

acer

I did not really need to use plots, in my approach using Optimization:-Maximize. If you read Carl's, Markiyan's, and my answers you can see similarities in the approaches. I'f I'm not mistaken, we all relied on using Im(objective)=0 as extra known information (eg. as constraint, or constraints plural). Carl used exact `maximize`, Markiyan used the add-on DirectSearch package, and I used the Optimization package.

The feasible set ends up being (the union of) three disjoint line segments, and the answer is the largest of the maximum for each. Not all the approaches listed had to examine those separately, or even explicitly.

Feasible sets which have measure zero (in the domain to be searched) can be hard for optimizers.

Carl got nice exact results. It might seem that his code relies of inspection of the objective, and manual extraction of the three extra conditions. But it should be simple to automate that, so I do not consider it a flaw. Note the helper proc that he wrote, though. Markiyan's answer (improving on what he might have reported as tried in his original Question) is very simple and straightforward. My approach worked harder and was most complicated, generating a set of "simple" extra constraints so as to get multiple calls to local `Maximize` over the finite collection of candidate regions. (There is obviously stuff for Optimization to learn from DirectSearch's way of handling such domains, and I accomodated an inequality->range conversion to get coverage of all the feasible domain.)

acer

@PatrickT 

Is this of any help?

> restart:

> eq := x = 11/500+6*u*(1/25)-u^2
>           +(-174200000000*x^5+13045131*E^4*u^4)^(3/5)/(65225655*E^4*u^4): 

> subsindets(eq,`^`,convert,surd):

> lprint(%);

x = 11/500+(6/25)*u-u^2+(1/65225655)*surd(-174200000000*x^5+13045131*E^4*u^4, 5)^3/(E^4*u^4)

@PatrickT 

Is this of any help?

> restart:

> eq := x = 11/500+6*u*(1/25)-u^2
>           +(-174200000000*x^5+13045131*E^4*u^4)^(3/5)/(65225655*E^4*u^4): 

> subsindets(eq,`^`,convert,surd):

> lprint(%);

x = 11/500+(6/25)*u-u^2+(1/65225655)*surd(-174200000000*x^5+13045131*E^4*u^4, 5)^3/(E^4*u^4)

One could address the question, "For which naturals is the number of divisors odd?"

A divisor is always matched by a corresponding quotient, and those are equal for the case of the square root of a perfect square. So there is only ever an "odd man out" for a perfect square.

If I understood the posed question, then the ith coin is flipped at the jth iteration, where j is any divisor of i (except 1, as you started by skipping 2). So you need to find out whether the number of divisors of i is odd or even, in order to figure out whether it stays as H or becomes a T.

acer

One could address the question, "For which naturals is the number of divisors odd?"

A divisor is always matched by a corresponding quotient, and those are equal for the case of the square root of a perfect square. So there is only ever an "odd man out" for a perfect square.

If I understood the posed question, then the ith coin is flipped at the jth iteration, where j is any divisor of i (except 1, as you started by skipping 2). So you need to find out whether the number of divisors of i is odd or even, in order to figure out whether it stays as H or becomes a T.

acer

@Christopher2222 I see, you were considering the plotting of structures emited as the result of calls to the `smartplot3d` command. You seem to be asking for live regeneration of the 3D plot, when that is panned. Thanks for explaining.

My point 3 was to do with the PlotComponent (embedded component) and the menubar's orientation toggles. In particular, it is already possible to programatically specify orientation when calling 3D plotting commands. It's also already possible to alter a PLOT3D data structure with a different ORIENTATION() call within it (by using `subs`, which creates a new structure). The new structure has to be passed from kernel to GUI as data. I want to be able to sidestep all that overhead, and to programatically control the GUI's own controls which manage the rotational view of the whole plot image. I want to be able to access those rotation controls of the GUI, without generating and passing new plot datastructures. And having such programatic control by means of properties of a containing PlotComponent seems like a natural way to do it. Something similar to all the PlotComponent properties for controlling an animation.

Here's where functionality related to point 3 (if not 3 itself) gets tricky: some people have suggested (here on Mapleprimes, I think..., but perhaps elsewhere) that adjusting (via right-click menus) a plot as stored in the GUI should be followed by a means to access the an equivalent modified plot data structure. Eg. first change the line or surface style, etc, and then somehow have the GUI pass back a modifed plot data structure (possibly only accessible as some potentially new property of a containing PlotComponent) to the kernel and thence to the user. I hope that it never gets implemented only like that. I would rather hope for an entirely new kind of data structrure for plots (ie. a Record, or object?) which is properly mutable, as a replacement to the current function-call structure. That's a huge task. I'm hoping for smaller, more realistic improvements.

@Christopher2222 Could you please explain how your idea of "Live 3d plot panning" differs from using "pan" as the mouse-cursor manipulator of a 3D plot?

Could you also please explain in detail what you meant by more "user programmable properties"? Is this "Live" panning one of those programmable things? If not, then what did you have in mind?

I apologize if I did not spell it out before, when I posted this: could you please refrain from general discussion on "wish lists" in the comments to this post?

If you would like to add concrete and particular detailed suggestions then please do so. But please put general comments in some other thread. It's very much not what I was hoping for here (even as a mixture, alongside particular concrete suggestions).

Thank you for your consideration,

acer

restart:
f:=-8.7754e-19*(1/(3590-t)^(1/4)):
plot([f,-f],t=2600..3600,filled=true,color=red,view=-6e-19..6e-19);

acer