The way I coded it, it would be temporary.  But if you want, you could easily enough create a new library archive with patches in it.  If you put that library in the right place and with the right name, then it will act as a 'patch' to the main library, and thus will be "permanent" without being irreversible.  Basically you put the archive in the same directory as maple.lib, and give that new archive a higher priority (ie > 1000000 ) than maple.lib.  Then it will act as a 'patch' library.

The main danger there is if Maplesoft issues its own patch library, yours may be searched either before or after the 'patch', and this can create undesirable side-effects.  So that would definitely be a user-beware action to take.

Executing LibraryTools[Priority](libname); (assuming libname is just a string) is most instructive.

It was implicit in my use of the terms "live surgery" that what I did was most dangerous indeed [but still most fun!].  Neverthless  it is indeed worthwhile being explicit about this - Maple's code base is very complicated, and seemingly obvious ``fixes'' can have disastrous side-effects.  Live surgery is not for the faint of heart. 

I still have memories of trying to fix one particular problem, only to discover the infamous 4-wrongs-make-a-right test in the test suite [ie a test where Maple got the right answer, but that was due to 4 different bugs expertly conspiring to do this; fixing any of the 4 bugs on their own caused other failures in other places because the 'improvement' caused a cascade of other failures!].

This fragility, unfortunately, is not really a positive characteristic; Software Engineering 101 says that that should not be the case in a well-designed modular system.  At least I can take some comfort in thinking that recent additions to Maple seem much more modular than some of the older code.  It is unfortunate that the core features of Maple heavily rely on older code - but that is to be expected in any system.

[I think by 'solution' the question asks for a work-around].  And indeed there is a way to do this.  Live surgery of Maple code is one of the things I really enjoy doing!  In this case, this simple one-liner will cure fsolve's ills:

`fsolve/EvalAtx` := FromInert(subsop([5,-2]=NULL, ToInert(eval(`fsolve/EvalAtx`))));

What does this do you might ask? Pretty simple, actually: it simply removes the if statement altogether from the offending routine (it is the second-last statement in that proc [thus the -2], and the statements of a proc at in the 5th position of an inert form), and voila!, bug fixed. And now things work like a charm:

> p := x^(1/x):pp := diff(p,x):
> evalf[5000](RootOf(pp,x,2..4)-exp(1));

                                  0.

Thank you Robert, I really liked that.  That is definitely the 'post of the day' for me.

We are really far behind a proper mathematical explanation of such phenomena.  Current technology is still trying to figure out how to deal with approximate factorization of polynomials, so what you show above is many orders of magnitude farther away from a satisfactory explanation!

To me, such an explanation will definitely have to involve Kolmogorov Complexity as one ingredient.

This eventually calls fsolve, and if you trace that, it seems that a lot of the cases return an "exponent_overflow" error.  This in turn is caused by the following line in `fsolve/EvalAtx`:

if 10000 < max(op(map(abs,map2(op,2,indets(r,float))))) then  return exponent_overflow end if;

Now, this weird line pulls off the exponent of a large (or tiny) float, which is (weirdly!) the actual exponent minus 10,000 [must have something to do with GMP?] and makes sure that it is not larger than 10000 in absolute value.  Well, at 4997 Digits (and more), some intermediate result you get is indeed that small.

This is one of the bizarrest hard-coded limitations I have seen in Maple.  [Most of the other similar bizarre ones are also in fsolve, BTW].

I have a refinement on what I think might be going on here.  It is possible that what is wrong is not `is/RealRange` itself but rather how it is being called.  When tracing things, what was passed to this routine and how it was processed looked a tad odd.  Maybe in some case it is being called with one convention, while in another it is using an opposite convention?

I have not looked at this in detail, this is just a guess.  It would take me a couple of hours to look at that carefully, a couple of hours I should really spend doing something else... [even though tracing this bug might just be more fun],

I have a refinement on what I think might be going on here.  It is possible that what is wrong is not `is/RealRange` itself but rather how it is being called.  When tracing things, what was passed to this routine and how it was processed looked a tad odd.  Maybe in some case it is being called with one convention, while in another it is using an opposite convention?

I have not looked at this in detail, this is just a guess.  It would take me a couple of hours to look at that carefully, a couple of hours I should really spend doing something else... [even though tracing this bug might just be more fun],

The origin of this question is much, much simpler!  Right now I am teaching a first-year discrete mathematics for computer science course (I use Rosen's wonderful textbook for this task).

At most universities nowadays there is a non-trivial issue with academic dishonesty (ie cheating, but the administrators like to come up with new words).  So I decided I would mitigate this problem by creating an assignment generator for this course.  Given a list of student IDs, the program generates 2 sets of html files, one containing randomized questions for each ID, and one containing the solution to that problem [so that the TAs can mark these assignments before they graduate!].  In Maple, this is really not very hard, especially if you think of generating the answer first, then generate a question that has that particular answer.  This makes the randomization much easier -- doing it the other way around, as my TA did on this one question, makes things a lot harder.

This particular question was inspired by question 20 on p. 354 of the 6th edition of Rosen's textbook, which is really an exercise that goes along with Theorem 3 and Example 12 on pages 351-352.

Working on this assignment generator has been a lot of fun.  I am still tweaking it, because I am not happy with the architecture of the generator.  And some of the randomization is really poor too - but that's because some of the questions are just a simple random choice from a short list of variants (usually 3 or 4).  But it does achieve its aim of severely curtailing cheating.  In fact, instead of trying to cheat, those students who don't understand just don't bother handing anything in at all, which towards the end of the year is a real time-saver...

One of these days, I should write a blog entry describing various techniques.  But the main idea is as described above: don't randomize problems, randomize answers.  If you think of an example involving say factorization of univariate cubic polynomials over the integers, you should see right away why this would be much simpler!

The origin of this question is much, much simpler!  Right now I am teaching a first-year discrete mathematics for computer science course (I use Rosen's wonderful textbook for this task).

At most universities nowadays there is a non-trivial issue with academic dishonesty (ie cheating, but the administrators like to come up with new words).  So I decided I would mitigate this problem by creating an assignment generator for this course.  Given a list of student IDs, the program generates 2 sets of html files, one containing randomized questions for each ID, and one containing the solution to that problem [so that the TAs can mark these assignments before they graduate!].  In Maple, this is really not very hard, especially if you think of generating the answer first, then generate a question that has that particular answer.  This makes the randomization much easier -- doing it the other way around, as my TA did on this one question, makes things a lot harder.

This particular question was inspired by question 20 on p. 354 of the 6th edition of Rosen's textbook, which is really an exercise that goes along with Theorem 3 and Example 12 on pages 351-352.

Working on this assignment generator has been a lot of fun.  I am still tweaking it, because I am not happy with the architecture of the generator.  And some of the randomization is really poor too - but that's because some of the questions are just a simple random choice from a short list of variants (usually 3 or 4).  But it does achieve its aim of severely curtailing cheating.  In fact, instead of trying to cheat, those students who don't understand just don't bother handing anything in at all, which towards the end of the year is a real time-saver...

One of these days, I should write a blog entry describing various techniques.  But the main idea is as described above: don't randomize problems, randomize answers.  If you think of an example involving say factorization of univariate cubic polynomials over the integers, you should see right away why this would be much simpler!

That was definitely the ticket.  My gut feel was that there was a nice graph-theoretic way of looking at this, but I could never quite "get into" that area of discrete math/cs.  Thanks, that is a beautiful solution.

That was definitely the ticket.  My gut feel was that there was a nice graph-theoretic way of looking at this, but I could never quite "get into" that area of discrete math/cs.  Thanks, that is a beautiful solution.

And if I want the path, then I can keep a copy of all of the intermediate matrices and easily enough read the possible paths where the endpoints can be read from the m-1'st matrix.  I can then work my way (backwards or forwards) to find the whole path, if I so wish.  Very nice.

And if I want the path, then I can keep a copy of all of the intermediate matrices and easily enough read the possible paths where the endpoints can be read from the m-1'st matrix.  I can then work my way (backwards or forwards) to find the whole path, if I so wish.  Very nice.

The thing that really blows my mind is that this phenomenon, namely that for parabolic Julia sets, the escape rate in a neighbourhood of the landing point of a ray that goes to the Julia set at the (forward orbit of) the critical value shows up in my PhD thesis!  Basically, what I show there is that there is a relation between the speed of escape of such points (in this case, polynomial in the number of iterations) and the ``geometry'' of the Julia set (basically what kind of 'wedges' one can stick in along landing rays).  Linear wedges (in the natural coordinates) correspond to any case where there is a hyperbolic metric, corresponding to exponential escapes.  When one gets to polynomial escapes, the wedges are asymptotically narrower (think x^2 around 0), which is what one observes in the parabolic and (conjecturally) in some of the Siegel cases too [ie in the exterior of the Siegel domains, the interior parts in those cases are simple].  These Julia sets (conjecturally in my thesis, but I believe that has been proven since) correspond exactly to those where the exterior conformal map extends to a H"older continuous map on the circle.

Your code deals with the (much easier) problem of finding contiguous increasing sub-sequences.  I meant an arbitrary sub-sequence.