@Alejandro Jakubi That may work for this example. But it also might be entirely beside the point. (Ok, so we don't know for sure what the OP's actual criteria are. But we may guess intelligently. I suggested that it was for u,v,w to appear less often in the result. Nobody's suggested otherwise, or another guess. Who knows, maybe the only criterion is expression length or lack of RootOfs. I was discussing the situation under my own guess.)

Your picking V to exclude, merely happens to produce some result in which u,v,w appear less often as a particularity of the example. But that's just a particular of the example. I see no method at all in your selecting V for exclusion from the trig terms as a `solve` variable aside from visual inspection or noticing the nature of eqn2, etc.

So your suggestion is much like my own first `solve` suggestion above, rather than what I was attempting with `G`.

Of course, I expect that you, Alejandro, are quite aware of these distinctions. So I'm commenting more for the benefit of the OP.

One could also simply invoke `isolate` on eqn2, in order to get the supposedly "better" formula for sin(b). That's even easier. But I didn't suggest it because it shares the aspect of arbitrariness.

As mentioned, we don't know what the OP really wants. Consider the sin(a) solution from A.J.'s `solve` call. Is it more, less, or equally desirable as this below?

> solve({eqn1, eqn2, eqn3}, {sin(a),cos(a),sin(b)});


       /            u                  w               v\ 
      { cos(a) = --------, sin(a) = --------, sin(b) = - }
       \         V cos(b)           V cos(b)           V/ 

For some other, different example, including V rather than excluding it might be key. It's problem specific. By trying a Groebner basis methodology for handling it as a polynomial system, I was trying to enforce priority amongst the variables (where I made a supposition that u,v,w were undesirable). Maybe it could be done better. Or maybe the OP just wants short solutions. Or the desire might be as simple as just wanting any solutions without RootOfs.

@Alejandro Jakubi That may work for this example. But it also might be entirely beside the point. (Ok, so we don't know for sure what the OP's actual criteria are. But we may guess intelligently. I suggested that it was for u,v,w to appear less often in the result. Nobody's suggested otherwise, or another guess. Who knows, maybe the only criterion is expression length or lack of RootOfs. I was discussing the situation under my own guess.)

Your picking V to exclude, merely happens to produce some result in which u,v,w appear less often as a particularity of the example. But that's just a particular of the example. I see no method at all in your selecting V for exclusion from the trig terms as a `solve` variable aside from visual inspection or noticing the nature of eqn2, etc.

So your suggestion is much like my own first `solve` suggestion above, rather than what I was attempting with `G`.

Of course, I expect that you, Alejandro, are quite aware of these distinctions. So I'm commenting more for the benefit of the OP.

One could also simply invoke `isolate` on eqn2, in order to get the supposedly "better" formula for sin(b). That's even easier. But I didn't suggest it because it shares the aspect of arbitrariness.

As mentioned, we don't know what the OP really wants. Consider the sin(a) solution from A.J.'s `solve` call. Is it more, less, or equally desirable as this below?

> solve({eqn1, eqn2, eqn3}, {sin(a),cos(a),sin(b)});


       /            u                  w               v\ 
      { cos(a) = --------, sin(a) = --------, sin(b) = - }
       \         V cos(b)           V cos(b)           V/ 

For some other, different example, including V rather than excluding it might be key. It's problem specific. By trying a Groebner basis methodology for handling it as a polynomial system, I was trying to enforce priority amongst the variables (where I made a supposition that u,v,w were undesirable). Maybe it could be done better. Or maybe the OP just wants short solutions. Or the desire might be as simple as just wanting any solutions without RootOfs.

The parsing of the infix &+- operator is also different. It seems like a difference in precedence.

In 1D Maple notation and without brackets to delimit the 1/2 the input

x &+- 1/2;

produces the output object `&+-`(x,1)/2 while in 2D Math mode it produces the output object `&+-`(x,1/2);

acer

I further cut down the objective function's individual execution time by around another factor of 2, by having the worksheet create lambda, X, NX, beta, g, etc, explictly as float[8] Vectors instead of implicitly as Maple tables.

I've also run it as an optimization problem, using each of the Optimization, GlobalOptimization, and DirectSearch (ver.2) packages. I used simple bounds (ranges) on all 5 variables. I pretty much had them each rely on default options, and I didn't try to tweak any of the solvers for speed by adjusting options.

F2proc_newer_stil.mw

I supplied an 'objectivegradient' procedure for Optimization:-NLPSolve to use. (That could be made even simpler, by having loop and seq over the fdiff calls in that procedure, instead of having all 5 lines be explicit.)

I inserted a few lines into the objective, to allow reporting when a better objective value was found. Mostly for fun, but also partly because I wanted to see its progress rate since speed performance was a prior issue.

acer

I further cut down the objective function's individual execution time by around another factor of 2, by having the worksheet create lambda, X, NX, beta, g, etc, explictly as float[8] Vectors instead of implicitly as Maple tables.

I've also run it as an optimization problem, using each of the Optimization, GlobalOptimization, and DirectSearch (ver.2) packages. I used simple bounds (ranges) on all 5 variables. I pretty much had them each rely on default options, and I didn't try to tweak any of the solvers for speed by adjusting options.

F2proc_newer_stil.mw

I supplied an 'objectivegradient' procedure for Optimization:-NLPSolve to use. (That could be made even simpler, by having loop and seq over the fdiff calls in that procedure, instead of having all 5 lines be explicit.)

I inserted a few lines into the objective, to allow reporting when a better objective value was found. Mostly for fun, but also partly because I wanted to see its progress rate since speed performance was a prior issue.

acer

The improvements in version 2 are quite apparent. I've really only just begun trying to go a little deeper in investigating using this package. The help pages in version 2 are a big improvement. There's obviously a large amount of development and authoring effort that lies behind this package. Great work.

I have one minor issue, and one (in my opinion) more serious one to report.

When supplying simple bounds as constraints, but without supplying an initial point, the `Search` routine seems to generate it own initial point. But it can sometimes select a point which violates those constraints. Yes, it does emit a Warning for this, but couldn't the routine automatically generate an initial point that satisfies all simple bound constrains (eg. [x>=-1, x<1, etc])? This may be minor.

A more serious objection is that the names used in (in)equality constraints, as expressions, are described as having to match the names of the formal parameters in the case that the objective is a procedure.

acer

I run the 32bit version of Maple, including Classic, on a 64bit Windows 7 Pro machine and have not seen any problems specific to that configuration.

Where did you get this idea, that 64bit Windows will not run 32bit Maple (including Classic)? I don't know that it is true in any significant way. (Certainly the Maplesoft M14 system requirements webpage states this info wrongly. Better to see Microsoft's own FAQ on this topic, which suggests that success is the norm in this regard.)

I will try the poster's code, in both Windows 7 Pro 64bit as well as in Windows XP64, using 32bit Maple for both, and report.

Ok, one to report: On Windows XP64 (a 64bit Windows platoform) the code and plot worked fine for N=400 or N=2000 in both the Classic and Standard GUIs of 32bit Maple 14.

nb. I'm just addressing Patrick's remarks about 32/64bit in this comment (which I believe to be mistaken) and not the OP's issues on Vista.

acer

I run the 32bit version of Maple, including Classic, on a 64bit Windows 7 Pro machine and have not seen any problems specific to that configuration.

Where did you get this idea, that 64bit Windows will not run 32bit Maple (including Classic)? I don't know that it is true in any significant way. (Certainly the Maplesoft M14 system requirements webpage states this info wrongly. Better to see Microsoft's own FAQ on this topic, which suggests that success is the norm in this regard.)

I will try the poster's code, in both Windows 7 Pro 64bit as well as in Windows XP64, using 32bit Maple for both, and report.

Ok, one to report: On Windows XP64 (a 64bit Windows platoform) the code and plot worked fine for N=400 or N=2000 in both the Classic and Standard GUIs of 32bit Maple 14.

nb. I'm just addressing Patrick's remarks about 32/64bit in this comment (which I believe to be mistaken) and not the OP's issues on Vista.

acer

@petrivka Ok, it looks like a lot of what goes on inside the objective procedure EIGEXP may be unnecessarily duplicated with each call. I'll give it a whirl...

@petrivka Ok, it looks like a lot of what goes on inside the objective procedure EIGEXP may be unnecessarily duplicated with each call. I'll give it a whirl...

This new MATLAB Answers site (about 3 weeks old, but also see here) has similarities to Mapleprimes and stackoverflow.

It is accessible off of their broader site, MatlabCentral, although I don't quite understand the difference between their FileExchange and their LinkExchange sites. I find their Contest site interesting.

Hopefully Mapleprimes can get enough ongoing development to compare well.

One of Mapleprimes' strengths is the ability to inline uploaded worksheets as content in a post. I've been seeing problems using that lately (insertion failures), and hopefully it will become more stable and powerful.

acer

@hirnyk I already mentioned how the results are different in Maple 13.02 and Maple 14.01.

@hirnyk I already mentioned how the results are different in Maple 13.02 and Maple 14.01.

Did anyone else catch episode 412 of The Big Bang Theory, titled "The Bus Pants Utilization"?

Sheldon and friends cook up an idea for a smartphone app: it would take a picture of a DE, do handwriting recognition, and then identify/solve it using some "symbolic evaluation engine".

(It may still be watchable online, here.)

acer

@hirnyk You got an error message because you omitted the {a,b,c,d}, even though you provided the avoid option. It looks like fsolve had a issue with that.

If you also supply {a,b,c,d}, and a (new) range, then it gets a differing pair of solutions with Maple 14 (and also a differing pair when using Maple 13.02).

It looks like fsolve's ability to find a differing solution depends on its initial value. (It seems reasonable, that fsolve would choose a different initial point when a range is supplied and when one is not. But a more general way to force differing initial points is, well, to supply them explicitly.)

I ran it like this, in M14, and got two different solutions.

restart:

x := 2*(-sin(2*a)+sin(2*(a+b))+2*cos(2*a+2*b+2*c+d)*sin(d));
y := -2+4*cos(2*a)-4*cos(2*(a+b))+4*cos(2*(a+b+c))-4*cos(2*(a+b+c+d));
z := 2*(sin(a)-sin(a+b)+sin(a+b+c)-sin(a+b+c+d));
w := -1+2*cos(a)-2*cos(a+b)+2*cos(a+b+c)-2*cos(a+b+c+d);

S1 := fsolve({w = 0, x = 0, y = 0, z = 0});

fsolve({w = 0, x = 0, y = 0, z = 0}, {a, b, c, d},
       {a = 0 .. 7, b = 0 .. 7, c = 0 .. 7, d = 0 .. 7}, avoid = S1)