@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

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

Changing the printlevel like that is overkill, when instead one could terminate the `end do` with a full colon.

acer

Changing the printlevel like that is overkill, when instead one could terminate the `end do` with a full colon.

acer

Using fnormal is not a trap, if one is trying to eliminate spurious nonreal artefacts (which is the case here) and if one uses it properly. But one does have to realize that it respects Digits (by default, unless overridden).

And that makes sense, since a small value of 10^(-13) may be considered an "artefact" at 10 digits of working precision but not at 15 digits of working precision. Or, a small value like 10^(-13) may be considered an artefact when compared to 10^(-12) but not when compared to 10^(-13). And there can be interplay between the effect of those two conditions: working precison and comparative size. And that is just what the extra 'digits' and 'epsilon' options of the fnormal command are there for.

The fine controls are there so that one can discriminate between what is to be taken as insignificant and what is not, since of course the status with which to consider some same magnitude will depend on the situation.

> q:=1e-13:

> fnormal(q,Digits,1e-12);
                               0.

> fnormal(q,Digits,1e-13);
                                -13
                            1 10   

The default behaviour won't suit everybody, and that too is to be expected. Everything which should have an option is like that.

acer