@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)

@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)

@hirnyk Here's a worksheet, run in Maple 14.01 under 32bit Windows XP. (48 solutions from sol[2], of which only 8 are correct.)

trigsolsexampleM140.mw

However, if I run this in Maple 13.02 then only eight solutions are computed by this worksheet, and they are all correct.

@hirnyk Here's a worksheet, run in Maple 14.01 under 32bit Windows XP. (48 solutions from sol[2], of which only 8 are correct.)

trigsolsexampleM140.mw

However, if I run this in Maple 13.02 then only eight solutions are computed by this worksheet, and they are all correct.

@hirnyk I believe that you are mistaken, if you think that contradicts my point. What I pointed out was that there are some incorrect solutions to {x,y,z,w} in the result of allvalues(sol[2]). It does not contradict this to show that there are also some correct solutions in it, which is all that you have done (as far as I can see).

The code I gave, in both earlier messages, demonstrates the incorrect solutions explicitly (by forward substitution into the original equations). Eight of the 48 solutions in evalf(allvalues(sol[2])) appear correct, and forty appear to be incorrect.

I used Maple 14.01 on 32-bit Windows.

@hirnyk I believe that you are mistaken, if you think that contradicts my point. What I pointed out was that there are some incorrect solutions to {x,y,z,w} in the result of allvalues(sol[2]). It does not contradict this to show that there are also some correct solutions in it, which is all that you have done (as far as I can see).

The code I gave, in both earlier messages, demonstrates the incorrect solutions explicitly (by forward substitution into the original equations). Eight of the 48 solutions in evalf(allvalues(sol[2])) appear correct, and forty appear to be incorrect.

I used Maple 14.01 on 32-bit Windows.

@hirnyk I don't think so. (Digits defaults to 10, so it isn't special to "raise" it to 10.) In your worksheet, you didn't evaluate {x=0,y=0,z=0,w=0} at R. You used some other point.

If I append these into your worksheet, the invalid results are shown all the same.

eval({w = 0, x = 0, y = 0, z = 0}, R)

seq(eval([x, y, z, w], eval(Q[n], [_Z2 = 0, _Z4 = 0, _Z6 = 0, _Z8 = 0])), n = 1 .. nops([Q]));

seq(eval([x, y, z, w], eval(qq, [_Z2 = 0, _Z4 = 0, _Z6 = 0, _Z8 = 0])), qq in Q);

@hirnyk I don't think so. (Digits defaults to 10, so it isn't special to "raise" it to 10.) In your worksheet, you didn't evaluate {x=0,y=0,z=0,w=0} at R. You used some other point.

If I append these into your worksheet, the invalid results are shown all the same.

eval({w = 0, x = 0, y = 0, z = 0}, R)

seq(eval([x, y, z, w], eval(Q[n], [_Z2 = 0, _Z4 = 0, _Z6 = 0, _Z8 = 0])), n = 1 .. nops([Q]));

seq(eval([x, y, z, w], eval(qq, [_Z2 = 0, _Z4 = 0, _Z6 = 0, _Z8 = 0])), qq in Q);

I guess that's incentive to upgrade versions.

Oh, hang on...

> 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):

> sol := solve({w = 0, x = 0, y = 0, z = 0}, AllSolutions = true):# a long output

> Q:=evalf(allvalues(sol[2])):

> Q[5];

             {a = 0.3419031877 + 6.283185308 _Z2, 

               b = 0.6383343061 + 6.283185308 _Z4, 

               c = 0.7556269538 + 6.283185308 _Z6, 

               d = 0.4422007045 + 6.283185308 _Z8}

> map(about,indets(Q[5],name) minus {a,b,c,d});

Originally _Z2, renamed _Z2~:
  is assumed to be: integer

Originally _Z4, renamed _Z4~:
  is assumed to be: integer

Originally _Z6, renamed _Z6~:
  is assumed to be: integer

Originally _Z8, renamed _Z8~:
  is assumed to be: integer

> # OK, so those _Z? parameters have to be integer valued.
> # So let's try the value 0 for them all.

> eval(Q[5],map(`=`,indets(Q[5],name) minus {a,b,c,d},0));

    {a = 0.3419031877, b = 0.6383343061, c = 0.7556269538, 

      d = 0.4422007045}

> # Now, evaluating the original equations at this point
> # should produce small values. (...but it doesn't, and
> # one can show that it's not just a roundoff issue.)

> eval([x,y,z,w],%);

    [-0.639506680, 0.231347804, -0.6603026126, 0.5832003498]

This is not a new issue, for solve with its AllSolutions option returns too many results (some invalid) for trig examples. It looks like a tough subject.

One has to check, which results are valid. The following should produce results with small magnitude. But only 8 of 48 do. It looks like incorrect results in allvalues(sol[2]), ie, more than just a roundoff/precision issue. It looks like sol[2] needs additional qualification.

Digits:=500:
for X in evalf(allvalues(sol[2])) do
   eval([x,y,z,w],eval(X,map(`=`,indets(X,name) minus {a,b,c,d},0)));
   print(evalf[5](%));
end do:

acer