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)

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