Home › Blogs › William Fish's blog

4997 Digits

William Fish's picture
Posted on 2008-03-26 07:59 By William Fish (Maple Rating 2 161)
Categories:

In the following worksheet, evalf[4997](... does what I expected and evalf[4998](... does not.

View 4937_Page147.mw on MapleNet or Download 4937_Page147.mw
View file details

See (3) and (10) in the worksheet.

Can anybody help me understand what is happening inside the CAS?  I know that 4998 is an obscene number of digits but on my Wintel machine:

> kernelopts(maxdigits);

returns 268,435,448

Comments

JacquesC's picture

Stupid hard-coded limitation in fsolve

Comment on 2008-03-26 10:16 from JacquesC (Maple Rating 4 1648)

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].

noted

Comment on 2008-03-26 10:30 from Dave L (Maple Rating 2 121)

Duly noted, thanks.

Dave Linder
Mathematical Software, Maplesoft

Any Solutions?

Comment on 2008-03-26 15:51 from dcasimir (Maple Rating 3 283)

I may have missed it in your post, but are there any ways a user can work around this ?

 

v/r,

 

Axel Vogt's picture

in this case it has an exact solution

Comment on 2008-03-26 16:01 from Axel Vogt (Maple Rating 4 885)

in this case it has an exact solution, so it is clear

JacquesC's picture

Curing Maple's bug

Comment on 2008-03-26 16:12 from JacquesC (Maple Rating 4 1648)

[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.

hmm

Comment on 2008-03-26 16:56 from Dave L (Maple Rating 2 121)

During the development cycle of Maple 9.5 (Jan, 2004) I removed these lines from the very top of `fsolve/EvalAtx` (which dates back to 1996),

   1   if 10000 < max(op(map(abs,map2(op,2,indets([v, f],float))))) then
   2     return exponent_overflow
       end if;

The start of my comment in the source revision begins, "Removal of a highly dubious mechanism for guessing whether the expression will under/overflow." and goes on with a bit of a rant about it. I can hardly imagine why I didn't notice the similar lines at the end of that short routine. I think that I was really focused on this next example, which did not work in Maple 9 and earlier.

fsolve((10.51627310^n-1/2*22.09916394^n-1/2*0.^n)/(1/2*17.95621497^n+1/2*7.261843774^n-10.51627310^n)-1, n=0.5..2);

Jacques, I know that you will be aware of it but others might not realize that from-the-hip editing of Library routines can be a risky thing. That can be so even when one has strong grounds to deem a fix as "good". Maple's so complicated that any adjustment really needs a full test run to ensure that no regressions are caused. I'd be remiss if I didn't mention that, given your code surgery example.

Dave Linder
Mathematical Software, Maplesoft

JacquesC's picture

Live surgery

Comment on 2008-03-26 17:10 from JacquesC (Maple Rating 4 1648)

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.

Axel Vogt's picture

permanent or for temporary?

Comment on 2008-03-26 17:52 from Axel Vogt (Maple Rating 4 885)

I always ask me: would such a 'hotfix' be permanent or needed for each restart?

acer's picture

not permanent, as it is

Comment on 2008-03-26 17:58 from acer (Maple Rating 4 1106)

As it was presented, it is not permanent and would vanish upon restart. To become permanent it would need either to be savelib'd to a .mla archive that would subsequently appear in libname in new sessions or to go in an initialization file.

By a strange coincidence, I've been trying to hammer out a decent blog item which relates to patching the Library. (Actually, I've learned that issues come in clumps and clusters, so coincidences suprise me less and less.) Maybe this will motivate me to post.

acer

JacquesC's picture

Temporary

Comment on 2008-03-26 18:04 from JacquesC (Maple Rating 4 1648)

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.

William Fish's picture

WOW

Comment on 2008-03-27 13:12 from William Fish (Maple Rating 2 161)

It works!  My worksheet works!  I am astonished [filled with sudden wonder or amazement].  I hope that's OK.

I continue to be amazed at what happens when I ask stupid questions here.  It is completely beyond my ability to predict.

Thank you all.

Here is my worksheet:

View 4937_Page147million.mw on MapleNet or Download 4937_Page147million.mw
View file details

WARNING: I went nuts and computed a million digits so it runs for 48 minutes on my humble machine.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
}