@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

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

This posted answer is not the only decent way to do it. Like many things in Maple, it's one of several viable alternative approaches.

The posted mechanism would process and assign to all the exports treated in like manner, and it would do them all on the very first reference to the package name in subsequent sessions. If one has a very large number of such exports, then the delay upon issuing with() might be undesirable. And indeed some alternative approaches could spread the cost, by separating the individual define_external calls. It could be done so that each define_external is done only when each export is referenced.

For example, one could code the module so that each export was defined as a procedure. Do away with the ModuleLoad entirely. Each export procedure could either make its own relevant define_external call each time it was invoked for a computation. Eg,

ASTEM97:=module()
option package;
export psat;
local dllloc;
   dllloc := "c:/Windows/system/astemdll.dll";
   psat := proc(x)
   local extern_fcn;
      extern_fcn := define_external('psat97mc', 'FORTRAN',
                           'arg1'::('float[8]'),
                           'RETURN'::('float[8]'),
                           'LIB' = dllloc);
      extern_fcn(x);
   end proc;
   # repeat for other exports   
end module:

with(ASTEM97);
                             [psat]

psat(4); # I have no such .dll
Error, (in psat) external linking: error loading external
library c:/Windows/system/astemdll.dll: The specified module could not be found.

The above approach works even without savelib and restart (but, naturally, one could still do that, for easy re-use in subsequent sessions!). One drawback to the above is that define_external is called each and every time the export psat is called. Improvements can be had here too, by using additional module locals to which to assign the define_external returned object (and checks whether each is assigned, each time invoked). Or the define_external calls can be replaced by a call to a proc (module local, say) which has `option remember`. There are lots of variations.

Or things could be even fancier, and each export could do the define_external *the first time* and then immediately redefine itself to the call_external (which is the proc that define_external actually returns). See here for a little on that technique.

acer

This posted answer is not the only decent way to do it. Like many things in Maple, it's one of several viable alternative approaches.

The posted mechanism would process and assign to all the exports treated in like manner, and it would do them all on the very first reference to the package name in subsequent sessions. If one has a very large number of such exports, then the delay upon issuing with() might be undesirable. And indeed some alternative approaches could spread the cost, by separating the individual define_external calls. It could be done so that each define_external is done only when each export is referenced.

For example, one could code the module so that each export was defined as a procedure. Do away with the ModuleLoad entirely. Each export procedure could either make its own relevant define_external call each time it was invoked for a computation. Eg,

ASTEM97:=module()
option package;
export psat;
local dllloc;
   dllloc := "c:/Windows/system/astemdll.dll";
   psat := proc(x)
   local extern_fcn;
      extern_fcn := define_external('psat97mc', 'FORTRAN',
                           'arg1'::('float[8]'),
                           'RETURN'::('float[8]'),
                           'LIB' = dllloc);
      extern_fcn(x);
   end proc;
   # repeat for other exports   
end module:

with(ASTEM97);
                             [psat]

psat(4); # I have no such .dll
Error, (in psat) external linking: error loading external
library c:/Windows/system/astemdll.dll: The specified module could not be found.

The above approach works even without savelib and restart (but, naturally, one could still do that, for easy re-use in subsequent sessions!). One drawback to the above is that define_external is called each and every time the export psat is called. Improvements can be had here too, by using additional module locals to which to assign the define_external returned object (and checks whether each is assigned, each time invoked). Or the define_external calls can be replaced by a call to a proc (module local, say) which has `option remember`. There are lots of variations.

Or things could be even fancier, and each export could do the define_external *the first time* and then immediately redefine itself to the call_external (which is the proc that define_external actually returns). See here for a little on that technique.

acer

Is improvement to the rendering (inlined into Mapleprimes posts, not in Maple itself) of typeset "2D" math a part of this plan?

If that is so then is it an item of higher, or lower, priority?

acer

See the help-page ?printlevel

acer