13196 Reputation

29 Badges

11 years, 233 days

On google groups. (comp.soft-sys.math.maple and sci.math.symbolic)

On stackoverflow.


MaplePrimes Activity

These are replies submitted by acer

@tomleslie Those values may be a minimum, but it shows them as not being a solution.

It is a serious shortcoming of DirectSearch:-SolveEquations, that it leaves it up to the user to programmatically notice/test whether the returned values do in fact solve the equations, or (more critically) are close to an actual solution. For people who just want a small/smallest residual it's fine. But for people who need to know whether an actual solution exists the behavior is extremely poor.

@Carl Love The _S000002 is a temporary name that (I believe) solve or SolveTools creates, as a way of encapsulating properties (or assumptions) on names or subexpressions.

I now see that the problem is not because of how solve (or machinery underneath it) works, but how arccos works.

In my previous Comment's result from solve, the problematic arccos calls were not automically resolving until I used forget. That's still unfortunate. But I suspect that the following cause (of that issue) has broader implications.



        Maple 2016.2, X86 64 LINUX, Jan 13 2017, Build ID 1194701

arccos(1/4*5^(1/2)-1/4); # good

                          2 Pi

prob := arccos(1/4-1/4*5^(1/2)); # hmm

            prob := Pi - arccos(---- - 1/4)

arccos(1/4*5^(1/2)-1/4); # hmm

                         arccos(---- - 1/4)



                                3 Pi


                                 2 Pi

I can understand that Maple might prefer to pull out a negative sign from arccos(1/4-1/4*5^(1/2)) (and shift the result accordingly). But oughtn't it to be checking whether the new, resulting call like arccos(1/4*5^(1/2)-1/4) can produce a result before putting it, unevaluated, into the temporary Cache?

After calling forget(arccos), if I once again call arccos(1/4-1/4*5^(1/2)) then once again the unevaluated call arccos(1/4*5^(1/2)-1/4) will be put back into the temporary Cache of arccos. Unfortunate.

This kind of behaviour by arccos seems to go back to at least Maple 9. Parts of Maple prefer cos. Another effect, using Maple 2016.2,




           Pi - arccos(---- - 1/4)



                       3 Pi

The relevant code seems to be the else clause of `arccos/normal`. It might be that uneval quotes prevent some infinite recursion, but I don't really see why it's needed for that subcase. If the sign is 0 then ok, and if the sign is -1 then calling actively on -x should recurse to the first clause (which is protected by uneval). Maybe I'm missing something. It is Friday, after all.


`arccos/normal` := proc(x)
   1   if `tools/sign`(x) = 1 then
   2     arccos(-x) := Pi-('arccos')(x);
   3     arccos(x) := ('arccos')(x)
   4     arccos(-x) := ('arccos')(-x);
   5     arccos(x) := Pi-('arccos')(-x)
       end if
end proc

Regarding a comment in my previous example: the following call to solve (or something underneath that) is not cleaning up some assignments into the temporary Cache of the arccos procedure. I think that it ought to do such clean-up, without any sort of extra burdern on the user to do something like call forget.

This changed between Maple 12.02 and 13.00, I believe. SCR submitted.


arccos(1/4*5^(1/2)-1/4); # Now computes and returns 2*Pi/5


s:=[solve(1/256+(1/128)*cos(8*x)-(1/128)*cos(4*x), allsolutions)]:



[arccos(_S000002)], [Pi-arccos(_S000002)], [arccos((1/4)*5^(1/2)-1/4)], [Pi-arccos((1/4)*5^(1/2)-1/4)]

arccos(1/4*5^(1/2)-1/4); # Now does not return 2*Pi/5



Cache:-TemporaryEntries(arccos); # NULL, after `forget`





@John Fredsted I would imagine that most people here know the values of cos at the multiples of Pi/4, but thanks for following up. And again thanks sincerely for your Answer.

Carl has now shown a systematic method for that "first step". I'm now trying to figure out why Maple resolves some similar examples...but not some/most.


# Why does it forget this is 2*Pi/5 later on!? Option cache?



p:= evala(Norm(z-convert(op(x1), RootOf))):
d:= degree(p):
p2:= combine(eval(p, z= invfunc[op(0,x1)](x))):
s:= subs(id,[solve(p2, allsolutions)]);

      s := [-3/10 _B1~ Pi + 1/2 Pi _Z1~ + 3/20 Pi,
            -1/10 _B1~ Pi + 1/20 Pi + 1/2 Pi _Z1~]

S1:= [seq(seq(eval(s[1], [_B1=kk,_Z1= k]), k= 0..d-1),kk=[0,1])]:
S2:= [seq(seq(eval(s[2], [_B1=kk,_Z1= k]), k= 0..d-1),kk=[0,1])]:
S:= [S1[],S2[]]:

S[min[index](abs~(x1 -~ S))];

                             7 Pi

BTW, vv's arctan example above also worked for me, after preliminary conversion to arcsin.

@Carl Love Thanks, Carl. Those initial lines of your code, to compute p2, are impressive.

@John Fredsted No worries. My version involved convert(cos(16*x1),expln) and I ought to have noticed that is exactly 0. It would be more apparent if I'd just done expand(cos(16*x1)) instead. Then it would be even more like member vv's expand(cos(16*x1)) which also produces 0 immediately. (I had to edit my previous comment too, to apologized for the close but unintentional duplication of approach.)

And your first observation can be had directly, as expand(cos(8*x1)) which returns sqrt(2)/2. So that too is in the same camp: noticing that cos(N*x1) equals something with known useful properties (for the trig inversion).

To me these "fortuitous" first steps are even more ad hoc as finding the values of the introduced parameter in the latter step.

@Markiyan Hirnyk Thank you, that sets the bar higher.

@John Fredsted That's an interesting idea, although there is still the matter of determining the values of the introduced parameter (for you n=2 and -1 for the boolean, and for me below _Z1=7). And the choice of application by `cos`, and the choice of the scalar multiple, is also to be considered. But thanks for the idea. Here's another way to utilize it.

[edited] After I did the following implementation I reread the whole thread and realized that the code below is the essentially the same kind of approach as member vv's Answer. That duplication was completely unintentional, and my apologies to vv!


x1 := arcsin(1/2*(2+(2+(2+2^(1/2))^(1/2))^(1/2))^(1/2)):


                  K := 1/32 Pi + 1/16 Pi _Z1~

v:=indets(K,name) minus {constants};

                         v := {_Z1~}


                            15 Pi

@vv That's the kind of thing I've been wondering. It would be sad if one had to resort to ever more nestings like `expand(combine(...))`.

On the one hand it seems Maple has difficulty simplifying mixed functional domains (e.g. arctrig and complex radicals). 

It may be that part of the difficulty is that `expand` and friends are hitting everything. Perhaps they could be used more selectively (e.g. frontend'ed).

I've see `solve` spit out arctan of complex radicals, quite often when given trig equations that I believe could be better handled by more examination of the periods of the individual trig calls contained.


@tomleslie Thanks, though I was trying to avoid `identify`, with the wording, "exact, symbolic steps".

@vv Thanks for looking, but as you've likely surmised I'm really after some kind of systematic approach where the target is as yet unknown.

@erik10 I am quite in agreement with you: there's quite a bit of improvement needed for the GUI, in terms not just of rescaling for high-res displays but also for consistent rescaling of embedded components and their associated text.

I'm not trying to suggest that things already work fine. I'm just trying to point out a few things that might possibly help you mitigate the difficulties now.

By the way, there have been quite a few reports by Danish users (mostly students) on this site, over the years, about corrupted worksheets. One aspect that recurs may be the presence of special text characters (eg. Danish), possibly linked to errant escape-characters. But I've been wondering whether the common presence of (not small, always) inserted images in the documents might not also be part of the problem. It would be a good thing to see such problems resolved.


Explicitly supplying some other value for the size option should already override whatever has been set using plots:-setoptions. That's a nice thing about plots:-setoptions, it allows you to set preferences, which can then be easily overridden at any time, with the usual command calls.

Also, the size=list option can be utilized on a call-by-call basis, with different values (as the first float in the list, designating the proportion) as desired.

When you write of "images" I'm not sure whether you mean images as backgrounds to plots, or inserted from the main menubar, or embedded using ImageTools:-Embed, or as a Drawing (canvas).

For images used as the background for 2-D plots, those don't respect plots:-setoptions with the size option, which I think is a good thing. But an explicit use of the size option in a plot command can still override the original dimensions of the image. Eg, using Maple 2016.2, with each of these lines in its own execution group, say,


img := cat(kernelopts('datadir'),"/undercarriage.jpg"):

# Good. Image file is 600x400.
# Should not adhere to setoptions preference of 300x300.

# Good. Respects the specified size.

# Good. Picks up setoptions preference of 300x300.

For images inserted using the main menubar's Insert->Image action, you could insert them into a single-row, single-column GUI Table, without exterior borders. By right-clicking on that Table you can set its properties. That includes setting it to be a fixed properotion of the GUI window's width (default is 100%). You can also center that borderless Table. As long as the original image width is greater than that proportion of the window width then the image will be zoomed to that dimension. So just make sure that the image is a wide as the maximally needed case.

For an image embedded with the ImageTools:-Embed command you can also right-click and change the Table's properties to a specific fixed proportion of the window width. You can also center it, eg, using the main menubar's Table->Alignment->Table->Center . (It would be nice if that command got the nicer options to do all that programatically like DocumentTools:-Tabulate can, or alternatively if DocumentTools:-Tabulate got the functionality to handle Array-based "images".)

Unfortunately the Drawing canvas does not seem to rescale automatically when placed within a GUI Table whose width property is set to a fixed proportion of the GUI window's width. Ie, objects drawn don't rescale when the GUI window is resized or maximized. That's a pity.

1 2 3 4 5 6 7 Last Page 1 of 309