@Alger Please explain in more detail what you mean.

@Alger I don't see why what I gave does not do what you've asked.

Here below the colors red and blue are switched, as you have them.

You write cos(theta) but perhaps you intend cos(freq*theta), for some freq. You write you want the axis to be at radius R, but your image shows a curve entirely within the circle. That's obtained by just adjusting my code by 1, in the axial direction.

Please explain more, if it wasn't actually what you wanted.

Download algerplot.mw

@Christopher2222 Yes, that was the first of the three plots I showed by example.

@Kitonum I could be misunderstanding of course, but where the OP wrote ".mw" I interpreted it as meaning a query about behaviour in the Standard GUI (as opposed to .mws which I might interpret as a query about behaviour in the Classic GUI, or both).

Which style: detached, grouped, or stacked?

acer

@mapleatha it worked fine for me, using the Java GUI of Maple 13. Why don't you describe exactly what you're doing, and in which interface and input and output mode, instead of just wasting time?

Here's a screenshot of it working for me in 64bit Maple 13.02 on Windows 7. Earlier in the day it worked for me using 64bit Maple 13.01 for Linux.

@nm Using a DOS window under Windows 7: (This is one long command, of course. I split it across two lines of text here just so that it displays nicely in this post.)

c:\TEMP>"C:\Program Files\Maple 18\bin.X86_64_WINDOWS/cmaple.exe"
         -q -c "print(int(sin(x),x));" -c "quit"

                                    -cos(x)
c:\TEMP>

Using cygwin (and this one also worked using /cygdrive/c/ instead of c: in the fully qualified location of cmaple.exe): (Again, this is just a one-line command.)

$ "c:\Program Files\Maple 18\bin.X86_64_WINDOWS/cmaple.exe"
  -b "c:/Program Files/Maple 18/lib/" -q -c "print(int(sin(x),x));" -c "quit"

                                    -cos(x)

Those worked for me with Maple 2015 as well.

@mapleatha Why are you not updating to the 13.02 point-release?

There is an item "Startup Code" in the "Edit" dropmenu off the main menubar of my 64bit Maple 13.02 running on Windows 7.

What operating system and particular point-release Maple version are you using?

acer

@jockoflocko Ok. So did you configure Maple to find the vcvars64.bat file from the MSVC++ compiler when you installed Maple 17. Or did you instead configure it afterwards, by running the Compiler:-Setup command? Which MSVC++ version did you install, and which Visual Studio version?

It may not be related to your problem, but are you still running Maple 17.00? And if so then have you considered getting the 17.02 update?

By the way in Maple 18 and 2015 the LLVM C compiler comes bundled with the 64bit Maple product itself, on each of the MS-Windows, Linux, and OS X platforms. Hence Compiler:-Compile is ready to go, with no downloads or configuration necessary.

What version are you using? Is it Maple 17?

What operating system? MS-Windows or Linux or OS X? And 32bit or 64bit Maple?

acer

@Carl Love Some years ago I wrapped up something very similar into a procedure which I called findroots. I mention it because, for a requested range a..b, it invoked NextZero with an option like maxdistance=b-start rather than just maxdistance=b say.

It looks to me as if your code is intended to restrict further searching if any root is found above bound 10000, because of the while condition on the loop. It doesn't make a huge difference for this example, but it might be that there is some benefit (speed or robustness) by using an option maxdistance= 10000 - R[k-1] rather than maxdistance= 10000 in the NextZero call. The endpoint 10000.0 might need it's own examination, but that's relatively very cheap.

Just an idea.

I think that NextZero has improved over the years. I don't see why fsolve couldn't be amended to call it as a method, possibly while offering the maxsols option for input other than just univariate polynomials. The whole business of repeatedly calling fsolve & its avoid option, as used by Student:-Calculus1:-Roots, is a bit sad.

@Alejandro Jakubi Of course customization is possible, but in my experience there are very many users who want and expect their own favored functionality model to be the default.

When I wrote "thorny dichotomy" I was thinking of the problem that users can and often do want greatly differing and opposing defaults from each other.

@Carl Love I'll note a few things too:

- andmap expects true or false, and will throw an error if the testing procedure such as is returns FAIL before andmap returns. So either a less beautiful test such as t->is(t)=true, or a nested loop, or similar, should be used instead of a raw is call.

- Examples can be found -- including in old posts on this site -- of mixed or unmixed trig, expln, radical, or RootOf expressions whose difference can be reduced to zero using a combination of custom simplification steps, but for which is does not succeed in showing equivalence.

Hence I prefer something more customizable, such as the Normalizer/Testzero method. This can also be set to use `is` of course. It might also be used in general concordance with the pivot checkers, division steps, and row reduction steps done by LUDecomposition for LU and Cholesky methods (because they use it too). I'd favor having the customizability mechanism not be the act of writing new extensions `IsMatrixShape/...`.

I also don't value so much authoring a custom extension to IsMatrixShape, if using it as such an extension requires even more typing. Intead of authoring one's own `IsMatrixShape/IsSymmetric` procedure and having to invoke it by all the keystrokes of IsMatrixShape(A,IsSymmetric) one could more easily author the same procedure and call it IsSymmetric and call it like IsSymmetric(A). I don't see why a sensible and consistent naming convention can't be as useful handling the global namespace as using very long names.

And what does the current implementation of `IsMatrixShape`(M,symmetric) offer that type 'Matrix(symmetric)' does not? If nothing of significance then the former could be sensibly changed to be smarter. I don't see much problem with having it be replaced with something as usefully powerful as a test by normal, which is what Normalizer defaults to. That mentioned typecheck could be used on Matrix A beforehand just as easily as could that call to IsMatrixShape. It's a few keystrokes less to use, since symmetric is not a protected name and hence should be quoted for general safeness.

type(A,'Matrix(symmetric)');
IsMatrixShape(A,'symmetric');

I don't really understand why IsMatrixShape even exists, if its stock methods are not going to be smarter than a corresponding typecheck.

@tomleslie A plain if..then conditional uses evalb as the boolean evaluator. And the help page for evalb documents somewhat well what it means for evalb(A=B) to return true. In the case of general nonnumeric expressions that won't return true unless A and B evaluate to the very same uniquified object in memory. It should therefore not be a surprise that evalb( x*(x-1) = x^2-x ) returns false since those are stored internally by Maple as two distinct symbolic expressions.

On the other hand you have brought up valid concerns. As Carl pointed out, normal may not invoke expand. But it should be recognized that while equivalence testing is a cousin of zero recognition but is not the very same thing. Maple's normal can produce the result that is identically 0 when passed the difference of two mathematically equivalent rational polynomials which might not individually be returned as the very same form by normal. For example,

expr1 := x*(x-1):
expr2 := x^2-x:

normal( expr1 );
                                  x (x - 1)

normal( expr2 );
                                    2    
                                   x  - x

normal( expr2 - expr1 );
                                      0

So throughout your quiz2, say, you'd be on firmer ground by considering expr1-expr2=0 rather than expr1=expr2.

It's also worth considering that people have come down this road many times before. There are several mechanisms for such testing. None is perfect -- not so much because "zero testing is theoretically undecidable", but more practically because the balance between ease-of-us/flexibility and power will never be perfect for all different kinds of Maple user. The following is just an illustration of alternate approaches.

print( eval(Testzero) );
 proc(O) evalb(Normalizer(O) = 0) end proc;

print( eval(Normalizer) );
 proc() option builtin = normal, remember, system;  end proc;

Testzero( expr2 - expr1 );
                                    true

So a potential alternative might be something more configurable. Eg,

restart:

unprotect(`IsMatrixShape/symmetric`);
`IsMatrixShape/symmetric` := proc(M)
   if op([1, 1],M) <> op([1, 2],M) then
       false;
   else;
       andmap(Testzero, M - M^%T );
   end if;
end proc:
protect(`IsMatrixShape/symmetric`);

M1:= Matrix([[0, x*(1+x)],[0, 0]]):
M2:= Matrix([[0, 0],[x+x**2, 0]]):

IsMatrixShape(M1+M2,symmetric);
                              true

Normalizer := t -> simplify(t, trig):

IsMatrixShape(Matrix([[0, sin(x)^2+cos(x)^2],[1, 0]]),symmetric);
                              true

Let's also notice that Maple has a working type-check for symmetric Matrices. So there's not much point in also having a command to do only the same thing, especially if it involves more typing to use. Since the command's name is prefixed by "Is" then why not give it the benefits of the is/assume/assuming mechanism?

# I actually much prefer to have just Testzero be used. I dislike this version
# that I give below because the potentially expensive `is` call cannot be turned off.
# I don't know how to resolve the thorny dichotomy: some users expects correct results
# as often as they can get them, with no surprises. But other others expect a fast and
# efficienct system which can be configured to not waste resources.
restart:

unprotect(`IsMatrixShape/symmetric`);
`IsMatrixShape/symmetric` := proc(M)
   if op([1, 1],M) <> op([1, 2],M) then
       false;
   else;
       andmap(t -> is(Normalizer(t) = 0), M - M^%T );
   end if;
end proc:
protect(`IsMatrixShape/symmetric`);

M1:= Matrix([[0, x*(1+x)],[0, 0]]):
M2:= Matrix([[0, 0],[x+x**2, 0]]):

IsMatrixShape(M1+M2,symmetric);
                              true

IsMatrixShape(Matrix([[0,a],[b,0]]),symmetric) assuming a=b;
                              true

IsMatrixShape(Matrix([[0, sin(x)^2+cos(x)^2],[1, 0]]),symmetric);
                              true

I do believe that merely using EqualEntries is a poor approach, which is what IsMatrixShape(..., symmetric) is doing in Maple 18. It's no better than the simple type-check syntax, I'd say.

restart:
showstat(`IsMatrixShape/symmetric`);

`IsMatrixShape/symmetric` := proc(M)
local S;
   1   if op([1, 1],M) <> op([1, 2],M) then
   2     return false
       end if;
   3   S := Matrix(M,scan = triangular[upper],shape = symmetric);
   4   return EqualEntries(S,M)
end proc

I think it's quite natural to expect at least the following of a symmetric Matrix check:

• Entrywise comparison as strong as normal by default, and tests the difference against zero, rather than just equality between entries.
• Configurable, documentable, and consistent with some other parts of Maple.
• Supports assumptions.

Sure, a new tolerance option for float comparison could also be added to the command. But a configurable mechanism such as provided by Testzero and Normalizer allow that too. They also allow for use of verify,float as well as for more general used of verify for the entrywise scalar comparisons.

Someone might point out that only the upper or lower triangle might need walking, when applying such tests. In the case of using andmap I wonder whether such could be accomplished by that kernel builtin itself.