I tried Mathematica 6.0 on
HypergeometricPFQ[{112, 51/10}, {-9/10}, -99999/100000]
and got the (presumably exact ??) result
-183933169187931829794351104521526197029774379000000000000000000000000\
0000000000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000000000000000000000000000000000000000000000000000\
0000000000000000000000000000000000000000000000/
11324984934739307220163426028747102350310899924999124109622447068264\
2089509049347831693103349943262869210969949172830357221037131460936617\
2457317140303388728526568056839394088427274999192970896030049564669168\
5199955047630663915447045353398112210710118309005643847603222953120252\
7472676579674432971253271831088126529101868279771770153695910346445313\
9991441759761159325993368148026744708619920408656674968525340473179327\
4543394221143555750764130509074977665133986904900063950461891643545329\
6240971237497707332066495140483266031003755059081400674335749107079469\
7608945169169804679596517702998625671016983228364785324615691195240034\
1
which evaluates to the Mathematica result via N[%,100].
In the documentation for HypergeometricPFQ there are illustrations where
the
internal $MaxExtraPrecision is insufficient to obtain the requested
precision for this function,
so apparently Mathematica fails to do adequate numerical evaluation
using N[] without resetting some global system parameter.
I don't know how to run your code or mpmath on exact inputs.
I have, in the past, used python-wrapped code from Allegro CL with
almost no effort.
This was for GMP.
I found, however, that the python wrappers were too unsophisticated for
me, and
implemented only the "Functional" style in GMP. That is, A:=A*B+C
could not
access the combined multiply-add-replace capability. I don't know if
that is still the case.
Barton Willis wrote:
> For Maxima 5.19, I contributed code for numerical and symbolic
> evaluation of the hypergeometric functions. The other day, I started
> looking into how Sage evaluates these functions (but I haven't tried to
> install Sage). One way seems to be mpmath
> (http://code.google.com/p/mpmath/).
> The NSF supported the development of mpmath:
>
> http://groups.google.com/group/mpmath/browse_thread/thread/960b02f0a2ed5dfa
>
>
> Let's try mpmath on a hypergeometric function; first let's try 50 digits
> and
> second 100 digits. The signs of the two values aren't the same:
>
>
>>>> mp.dps = 50
>>>> hyper(['112.0', '5.1'],['-0.9'],'-0.99999')
>>>>
> mpf('0.00000000000073150973254264463451967741826767251189694769140430165')
>
>
>>>> mp.dps = 100
>>>> hyper(['112.0', '5.1'],['-0.9'],'-0.99999')
>>>>
> mpf('-0.00000000000000000000000162413610479<junk>')
>
> Wolfram Alpha (input: hypergeometricPQ[{112,5.1}, {-0.9}, -0.99999]) gives
>
> -1.62413610479708629611767409391575176600337612526370... x 10^-24
>
> And my (non-NSF) code gives
>
> (%i4) hypergeometric([112.0b0, 5.1b0],[-0.9b0],-0.99999b0);
> (%o4) - 1.6331655633849675761598634419620944688583571143885b-24
>
> I'm not sure why my value differs from mma by about 9.0e-27, but
> likely it is due to differences in the precisions of the inputs. At
> least my code gets the sign correct. Grump^infinity.
>
> Barton
>
>
>