I have fixed it.

I have fixed it.

If you had done solve({df=0},{x});, you would have gotten {x=tan(RootOf(2*_Z*tan(_Z) - 1, 0.6532711871))} as a result, which completely agrees with your result:

 tt := RootOf(2*_Z*tan(_Z) - 1, 0.6532711871): evalf(tan(tt));
                             0.7653789267

It took me a little while to figure this out too. But Maple is correct here (inasmuch as Student[Calculus1]:-CriticalPoints returning an empty result can be considered ``correct'').

Personally, I would call it a bug, but in Maple lingo, this is called a weakness. Basically, Maple has only one solve, which solves over the complex. It does not really have a solve which finds only solutions in a smaller domain, except for the integers. In other words, no 'solve' that is designed from the ground up to deal with the reals. Of course, this is not so simple: one can easily conjure up an equation where the solution is real, but intermediate values of the expression (but not the final values) are complex. In other words, the problem here is that discont() is asking solve() much too general a question, because it has no real way (pun intended) to ask a more meaningful question. The issue is really that the restriction that only solution with x in 1..10 interest you is not "used". Mathematically, this is a very hard problem. What is puzzling is how little this seems to matter; I mean, this kind of ``weakness'' is rarely encountered in practice. Either that or, when it is encountered, it is not reported and/or blamed on something else. Or maybe this really is rare. It would be interesting to know! If it is rare, then it is not worth expending a lot of effort on it. If it is merely under-reported, then maybe this requires real attention.

See some of the code below in this same post. The tricky part is with repeated eigenvalues, one needs to take care. Also, the resulting vectors are frequently normalized in some way, which is likely not they way they will come out of this straightforward a solving method.

See some of the code below in this same post. The tricky part is with repeated eigenvalues, one needs to take care. Also, the resulting vectors are frequently normalized in some way, which is likely not they way they will come out of this straightforward a solving method.

You know, that just might work! Maplesoft derives too much "competitive" advantage [see their marketing] from Standard to easily allow the outside world to look at that. It also derives some competitive advantage from parts of the kernel and library. But there is no competitive advantage to be gained from Classic! That is one component which could be open-sourced without doing harm to the business side [if someone can argue that it would do harm to the business side to open source it, then that same argument should mean that Classic should be improved, which it isn't; that status quo is already 'doing harm' to Classic]. Be warned though: there is a reason maintenance of Classic was abandoned...

Classic GUI is completely frozen - only Standard gets active development. And Standard M11 starts faster than previous versions... but it's still too slow for my taste. Personally, I installed Eclipse (a development environment), started it, waited for way too long, so I shut it down and uninstalled it. Same with Sun's IDE. The only reason I did not do the same with VisualStudio was that I needed it to compile a project for my course (although for VS, if I got a slightly faster computer, that would not be a problem, while it would not have solved Eclipse's problem).

If you are on Windows or Linux, have you considered using Classic instead of Standard? That is what many of the old-timers on mapleprimes use for their daily work, many for reasons similar to yours: Classic does not 'get in the way' of doing work with the underlying Maple, while Standard still has glitches (even in worksheet mode) that can make it bothersome to use for someone who is not a beginner.

h(2) will evaluate a function at a point. If you want to evaluate an expression at a point, use eval(g,x=2). diff will differentiate an expression, so diff(g,x) works; to differentiate a function, do D(h) instead.

h(2) will evaluate a function at a point. If you want to evaluate an expression at a point, use eval(g,x=2). diff will differentiate an expression, so diff(g,x) works; to differentiate a function, do D(h) instead.

It is a rampant disease in IT, and some connected fields - if it's not new, it can't be good. mint is very very old. Maple sits in a weird niche, because while it straddles IT and math - and mathematicians know that old theorems are just as good as new ones. Perhaps we should find a way to reprint the user manual for Maple 3.3 [I have a copy!]. It documents lots of techniques that seem to have all but disappeared from the (offline) documentation of pointy-clicky Maple. The only mention of 'mint' is on p.330 of the Programming Guide, as a footnote to the [horribly slow and even less up-to-date] maplemint.

> Si(0);

                                  0

and also

> FunctionAdvisor("special_values", Si);
                              Pi                      Pi
  [Si(0) = 0, Si(infinity) = ----, Si(-infinity) = - ----,
                              2                       2

        Si(infinity I) = infinity I, Si(-infinity I) = -infinity I]

and yet

> solve(Si(x)=0,x);

                            RootOf(Si(_Z))

so that solve knows less about Si than either Si itself or Maple's FunctionAdvisor. In other words, the knowledge that Si(0)=0 is 'spread out' in Maple, and routines that should have that knowledge do not 'query' the right databases for that knowledge.

> Si(0);

                                  0

and also

> FunctionAdvisor("special_values", Si);
                              Pi                      Pi
  [Si(0) = 0, Si(infinity) = ----, Si(-infinity) = - ----,
                              2                       2

        Si(infinity I) = infinity I, Si(-infinity I) = -infinity I]

and yet

> solve(Si(x)=0,x);

                            RootOf(Si(_Z))

so that solve knows less about Si than either Si itself or Maple's FunctionAdvisor. In other words, the knowledge that Si(0)=0 is 'spread out' in Maple, and routines that should have that knowledge do not 'query' the right databases for that knowledge.