If the hardware float version fails what is done is most other top-level routines is that the software version is automatically called.  So what you outline here [sorry, I missed that detail from your previous post] is that this isn't done.  That's a bug.

The 7 Digits part also seems like an independent bug.  Very strange.

A quick investigation leads to define_external("STATS_MaplePoissonRandomSample_HW",MAPLE,LIB = "statshw.dll"); as being the culprit [after an astonishing amount of preprocessing].  In other words, that is the routine which is called to do the job, and is also the one which throws that error.

It seems that there is no software-float backup to this particular (??) Statistics routine.

A quick investigation leads to define_external("STATS_MaplePoissonRandomSample_HW",MAPLE,LIB = "statshw.dll"); as being the culprit [after an astonishing amount of preprocessing].  In other words, that is the routine which is called to do the job, and is also the one which throws that error.

It seems that there is no software-float backup to this particular (??) Statistics routine.

Now that you mention it, the use of alias has all but disappeared from a lot of the documentation (ie recent stuff).  I wonder why?  It nicely does solve a real problem (as shown here), that more people ought to know about!

Joe, you might consider doing a Book page for that, in the hopes of reviving alias.

Now that you mention it, the use of alias has all but disappeared from a lot of the documentation (ie recent stuff).  I wonder why?  It nicely does solve a real problem (as shown here), that more people ought to know about!

Joe, you might consider doing a Book page for that, in the hopes of reviving alias.

Internally, it first returns Gamma(0,z), which some other routines then ``simplify'' to Gamma(z).  Perhaps that is the actual bug?

I totally agree that full-routine, and preferably in source form, is preferable.  I am just saying that when it is not, patches are still possible.  In other words, there are no technical reasons why we couldn't put together a set of patches, some of which would be nice, some which would be obscure. 

In the particular case of the 4997 Digits problem, that one can be done in source form!  I just had too much fun showing the other method...

I believe that it would be better organized as a sourceforge project, with a mapleprimes blog page to indicate progress/updates, with links to full html pages for the details.

It is much simpler for Maplesoft to deal with duplicate reports than to expect them to fix bugs that have never been reported!  File away.  If a bug gets reported many many times, then that means that a lot of people have encountered it, so it is even more important that it get fixed.  [# of times reported used to be tracked in the database, although I am not sure if it is anymore]

It is much simpler for Maplesoft to deal with duplicate reports than to expect them to fix bugs that have never been reported!  File away.  If a bug gets reported many many times, then that means that a lot of people have encountered it, so it is even more important that it get fixed.  [# of times reported used to be tracked in the database, although I am not sure if it is anymore]

Designing benchmarks like this is quite a lot of work.

Sure is!  But worthwhile.

However, I disagree with your statement about Maple's performance being fairly unaffected by a lot of things.  In theory, that's true.  In practice, it's not.  You can measure a huge difference (in some cases) on the same hardware but running different OS (because memory-intensive Maple computations are very sensitive to the underlying OS's memory management routines).  Maple can also be very sensitive to hardware configurations [like cache size for numerics intensive computations].  And it can vary on whether you are running the computation using TTY, Classic or Standard [why that is so mystifies me, but I have definitely measured such an effect].

A massive but very thorough timing suite would be very useful.  We could measure both progress and regressions that way too.

The core routine that does this transformation is

> showstat(`convert/GAMMA/IC/from`[Ei]);

`convert/GAMMA/IC/from`[Ei] := proc(f)
local a, z, G;
   1   if nargs = 0 then
   2     return 1, (a, z) -> if nargs = 2 then [[z <> 0]] end if
       end if;
   3   if nops(f) = 2 then
   4     a, z := op(f);
   5     if `tools/type`(z <> 0) then
   6       if `tools/type`(a,'integer') then
   7         G := ('GAMMA')(1-a,z)
           else
   8         G := GAMMA(1-a,z)
           end if;
   9       return z^(a-1)*G
         end if
       end if;
  10   f
end proc

which gives GAMMA(0,z) when given Ei(1,z) as input.  What should it be instead?

Note that it is possible to 'patch' anything you want using the method I called live surgery previously can be used to patch anything at all.  This requires that patching be done in an init file instead of via a patch library though.

The Maple library only changes once a year (for those who continually upgrade), and for a lot of users, less often than that.  But more to the point, certain bugs don't seem to get fixed in a 'timely' manner.  If those same bugs can get fixed by the community, why not?  It is often easy to fix a clear bug in a sub-sub-routine of simplify or of fsolve, but quite unrealistic to write a whole new simplify or fsolve.

It is true that patches can introduce unexpected behaviour.  But what is a user to do?  Wait 7 years for Maplesoft to get around to fixing the bug, or go with a patch that is available now that seems to work for the case at hand?

I am not sure if the Maplesoft developers really know how much the Standard prettyprinter is a very serious regression from Classic.  This is but one example.  There are all sorts of issues with baselines that are too high or too low, exponents that are too high, too low, too far left or right [same with subscripts], weird placement of minus signs, extra parenthesis when they are not needed, missing parentheses when they are, etc.  Also the fonts they use are fuzzier - I don't know where that comes from.  I know this was an issue with WebEQ as well; that turned out to be because for some (stupid!) reason a weird (and completely unecessary) scaling factor was applied to all glyphs, thus making them fuzzy.  If the fonts are used 'scaled' instead of at their natural sizes, that might be the cause.  But the worst is probably the line-breaking.  VERY often I have seen a break in an expression that looks like expr^(1/3) + expr2^(1/3) where the break is to put just the ^(1/3) [typeset as a superscript] on its own on the next line!  Sometimes, I have even see weird things like just an open ( on one line at the end, and the rest of the expression on the next.  Just incredible stuff.

But as I use Classic in part because I can't stand how awful the math now looks, and in part because I mostly use Maple to get some work done and Classic allows me to do that much more efficiently.  Standard, even in 1D worksheet mode, is not nearly as responsive as Classic.  Plus Standard has  lost the % labelling on large expressions.

I am not sure if the Maplesoft developers really know how much the Standard prettyprinter is a very serious regression from Classic.  This is but one example.  There are all sorts of issues with baselines that are too high or too low, exponents that are too high, too low, too far left or right [same with subscripts], weird placement of minus signs, extra parenthesis when they are not needed, missing parentheses when they are, etc.  Also the fonts they use are fuzzier - I don't know where that comes from.  I know this was an issue with WebEQ as well; that turned out to be because for some (stupid!) reason a weird (and completely unecessary) scaling factor was applied to all glyphs, thus making them fuzzy.  If the fonts are used 'scaled' instead of at their natural sizes, that might be the cause.  But the worst is probably the line-breaking.  VERY often I have seen a break in an expression that looks like expr^(1/3) + expr2^(1/3) where the break is to put just the ^(1/3) [typeset as a superscript] on its own on the next line!  Sometimes, I have even see weird things like just an open ( on one line at the end, and the rest of the expression on the next.  Just incredible stuff.

But as I use Classic in part because I can't stand how awful the math now looks, and in part because I mostly use Maple to get some work done and Classic allows me to do that much more efficiently.  Standard, even in 1D worksheet mode, is not nearly as responsive as Classic.  Plus Standard has  lost the % labelling on large expressions.