I think that probably would result in some mess:

Simplifying gives a denumerator of degree 407. The discriminant is not zero, so - if I remember correctly - all zeros are different. Using Cauchy's bound and plotting (log) indicates there is a real zero at -1 and using Sturm chains shows there is only 1 real root.

I think that probably would result in some mess:

Simplifying gives a denumerator of degree 407. The discriminant is not zero, so - if I remember correctly - all zeros are different. Using Cauchy's bound and plotting (log) indicates there is a real zero at -1 and using Sturm chains shows there is only 1 real root.

The online help (for evalf) says:

Numeric Precision
You can control the precision of all numeric computations using the environment variable Digits. By default, Digits is assigned the value 10, so the evalf command uses 10-digit floating-point arithmetic.
You can assign any positive integer that does not exceed the kernelopts(maxdigits) value to Digits. For more information, see kernelopts.
To specify the numeric precision for an evalf computation without changing the value of Digits, use the optional index in the calling sequence, that is, evalf[n](expression).

What you may have in mind is: correct to n digits and correctly rounded (in which way ever prefered)

May be the handbook even tells more (I have not looked it up)

The R fromm above is

R := 1/2*9^(-p)/GAMMA(1/2+p)*6^(1/2)*hypergeom([p+1/4, -1/4+p],[1/2+p],5/9)*
     sin(Pi*p)*GAMMA(-p+1) * GAMMA(-1/2+2*p);

Now I think that Maple evaluates sin(Pi*p)*GAMMA(-p+1) as 0 in integers because
of the sinus - and ignoring the pole of GAMMA (a kind of l'Hospital situation).

However it could know it better

  GAMMA(-z) = -Pi*csc(Pi*z)/GAMMA(z+1); # reflection formula, FunctionAdvisor 
  convert(%, sin);
  -sin(Pi*z)*%*z;
  combine(%);
  eq:=subs(z=p, %);

                                                  Pi
               eq := sin(Pi p) GAMMA(-p + 1) = --------
                                               GAMMA(p)

Then the following behaves correct

  algsubs(eq, R); combine(%) assuming p::posint;

    1/4*2^(1/2)*(4*p-3)*3^(1/2-2*p)*
    hypergeom([-1/4+p, p+1/4],[p+1/2],5/9)*GAMMA(2*p-3/2)*Pi /GAMMA(p+1/2)/GAMMA(p)

However I can not get the desired simple result (which is not only by the missing
simplification for denominator, but more for the hypergeometric expression). 


PS: I like Robert's cute way ...

The R fromm above is

R := 1/2*9^(-p)/GAMMA(1/2+p)*6^(1/2)*hypergeom([p+1/4, -1/4+p],[1/2+p],5/9)*
     sin(Pi*p)*GAMMA(-p+1) * GAMMA(-1/2+2*p);

Now I think that Maple evaluates sin(Pi*p)*GAMMA(-p+1) as 0 in integers because
of the sinus - and ignoring the pole of GAMMA (a kind of l'Hospital situation).

However it could know it better

  GAMMA(-z) = -Pi*csc(Pi*z)/GAMMA(z+1); # reflection formula, FunctionAdvisor 
  convert(%, sin);
  -sin(Pi*z)*%*z;
  combine(%);
  eq:=subs(z=p, %);

                                                  Pi
               eq := sin(Pi p) GAMMA(-p + 1) = --------
                                               GAMMA(p)

Then the following behaves correct

  algsubs(eq, R); combine(%) assuming p::posint;

    1/4*2^(1/2)*(4*p-3)*3^(1/2-2*p)*
    hypergeom([-1/4+p, p+1/4],[p+1/2],5/9)*GAMMA(2*p-3/2)*Pi /GAMMA(p+1/2)/GAMMA(p)

However I can not get the desired simple result (which is not only by the missing
simplification for denominator, but more for the hypergeometric expression). 


PS: I like Robert's cute way ...

Living in Germany I am not much used to Yahoo as data source, but if you have to retrieve page by page it always will slow. I think there are cheap data provider: this has the advantage, that you do not need to re-write programs (and they may care for splittings or such stuff). On a private base I only used either Eurex (what a shit, every year something changed) or simply had some depot at an online bank (same trouble + password trouble) and all that through Excel (very comfortable). In those cases where commercial quality was the very thing then it always was within a 'guaranteed' infrastructure and provided data have been from Bloomberg or Reuters at realtime. But for private use and 'end of day / settlement' there may be even free sources beyond that, may be you find some at www.wilmott.com/messageview.cfm

Living in Germany I am not much used to Yahoo as data source, but if you have to retrieve page by page it always will slow. I think there are cheap data provider: this has the advantage, that you do not need to re-write programs (and they may care for splittings or such stuff). On a private base I only used either Eurex (what a shit, every year something changed) or simply had some depot at an online bank (same trouble + password trouble) and all that through Excel (very comfortable). In those cases where commercial quality was the very thing then it always was within a 'guaranteed' infrastructure and provided data have been from Bloomberg or Reuters at realtime. But for private use and 'end of day / settlement' there may be even free sources beyond that, may be you find some at www.wilmott.com/messageview.cfm

I do not work with that package. But is seems 'obvious' for me, that it is
using a compiled version of algorithms (I see no need to use much symbolics,
that would slow down a *lot*).

So the first what I would do is to set Digits:=14 (or better evalhf(Digits)).

  img[2,2];
                         0.979999999999999982

Which is 2206763817411543/2251799813685248*pow(2,0) and I would expect

  evalhf(4.0*0.98);
                         3.91999999999999993

However I get (avoiding to mix datatypes integer and float (which is not
actually posible in pure Maple, I think)

  img[2,2]*4.0 = .98 * 4.0;

                       3.9200000000000 = 3.920

How is that? Well, it is quite fine: Both give the *same* number in IEEE
float, 2206763817411543/2251799813685248*pow(2,2). And you can not trust
anything beyond that (the rest is converting from IEEE to decimals and
some resentation voodoo beyond IEEE 53 bit).

You can check that using the function 'nearest' I posted some days ago
for testing compiled results against exact solutions.

For the implicite, 2nd part of your problem - 0.97 and 0.98 become the
same: you use different inputs for 'img'. It is likely that this is due
to the algo beyond, and in IEEE they identify. Guess you have to live
with it (except M allows symbolic exactness here).

In any case: you should set the correct Digits first.

Side remark: Since Maple already uses GMP for large integers I always was wandering, while it does not access to MPFR (or complex variants) in the same spirit. I would be interested to hear a comment from a Maple guy on that ...

www.mpfr.org/

I think that is the hardware float number for 0.97

I did those downloading once using Excel and do not think a DLL is needed. For superfast I would go for wetget or such stuff (actually I am a very bad coder).

I did those downloading once using Excel and do not think a DLL is needed. For superfast I would go for wetget or such stuff (actually I am a very bad coder).

Formally nothing is a bug, if a docu tells it.

But who ever seriously thinks that for users switching from one to the other it is bearable to check each input characterwise?

I will never understand that attitude (sorry, please do not take it personally)

At least you may say what is the origin of that task and for what you want to use it.

And what are typical constellations of your parameters.

Edited (while waiting for your answer):

Using the transformed problem I would check at the boundaries first.

x ~ 0 using a series in x=0 the 'polynomial' part of the Laurent series
numerical dies quickly and it should be possible to state a lower bound
where some 0 < x could ever exist there or find a lower bound as 1e-10
or such.

x ~ infinity is ugly and a lame way is to replace erc, erfc by their
asymptotics (or use inverse Mills ratio as coded function) and write
1='b/2*D(erf)(u)/erfc(u)/u + a/2*D(erf)(v)/erfc(v)/v # positive 
   - a/2*D(erf)(v)/erfc(v)/v/erf(v)';                # dito

Now one should have a range where to search. If fsolve does not answer
(*and only then*) one could first shrink the range by bisection for log(x)
and then by switching to the binary representation (or the usual bisection)
or re-try fsolve for that.

Whether that makes sense depends on answers you have not given: is it
known to be monotous or to have extrema or ...

It depends a bit on your constellation of parameters and if you have it
in a very flat part it may become hairy (needing higher precision and
care for cancellation of leading digits or accepting results with not
so good accuracy).

But I do not want to do it for you :-)

At least you may say what is the origin of that task and for what you want to use it.

And what are typical constellations of your parameters.

Edited (while waiting for your answer):

Using the transformed problem I would check at the boundaries first.

x ~ 0 using a series in x=0 the 'polynomial' part of the Laurent series
numerical dies quickly and it should be possible to state a lower bound
where some 0 < x could ever exist there or find a lower bound as 1e-10
or such.

x ~ infinity is ugly and a lame way is to replace erc, erfc by their
asymptotics (or use inverse Mills ratio as coded function) and write
1='b/2*D(erf)(u)/erfc(u)/u + a/2*D(erf)(v)/erfc(v)/v # positive 
   - a/2*D(erf)(v)/erfc(v)/v/erf(v)';                # dito

Now one should have a range where to search. If fsolve does not answer
(*and only then*) one could first shrink the range by bisection for log(x)
and then by switching to the binary representation (or the usual bisection)
or re-try fsolve for that.

Whether that makes sense depends on answers you have not given: is it
known to be monotous or to have extrema or ...

It depends a bit on your constellation of parameters and if you have it
in a very flat part it may become hairy (needing higher precision and
care for cancellation of leading digits or accepting results with not
so good accuracy).

But I do not want to do it for you :-)