Re: Bug with Hypergeometric2F1?
- To: mathgroup at smc.vnet.net
- Subject: [mg99616] Re: Bug with Hypergeometric2F1?
- From: Bill Rowe <readnews at sbcglobal.net>
- Date: Sat, 9 May 2009 03:22:03 -0400 (EDT)
On 5/8/09 at 12:14 AM, akoz at mimuw.edu.pl (Andrzej Kozlowski) wrote:
>On 7 May 2009, at 19:38, Bill Rowe wrote:
>>I don't believe your interpretation of what occurs is correct. I am
>>reasonably certain when you use Sum with machine precision numbers
>>a numerical estimate is made using the same code used by NSum. That
>>is, I believe the effect of using machine precision numbers is to
>>call NSum.
>>I used SetDelayed since Set cannot be used with NSum in this
>>example. With Set, Mathematica tries to evaluate the right hand
>>side which cannot be done since n and k are not defined at this
>>point.
>Sorry, but I think it is you who is confused. The point is this:
>when you evaluate Sum[Binomial[100., i], {i, 0, 1.}], which is what
>you are doing when you use SetDelayed, Mathematica automatically
>replaces approximate numbers by exact ones when evaluating the sum,
>so it gets the right answer anyway. The original problem had nothing
>to do with Sum or NSum at all, that's what I meant by "illusion". It
>was all concenred with evaluating the formula:
>2^n - Binomial[n, k + 1]*Hypergeometric2F1[1, k - n + 1, k + 2, -1]
>with n and k approximate numbers. It is this formula and not Sum
>that is the cause of the problem. The problem would still be present
>if f was defined simply as
>f[n_,k_]=2^n - Binomial[n, k + 1]*Hypergeometric2F1[1, k - n + 1, k
>+ 2, -1]
>If you use SetDelayed in the original definition of f, the above
>formula is never used so the issue does not arise. NSum was
>completely irrelevant to this problem.
While I understand your argument and point, I remain unconvinced
this is the true underlying explanation. The difference between
my hypothesis of what occurs and your explanation lies in the
precise details of how Sum and NSum work. And without access to
the source code, there is no way to determine which explanation
is a better match to the source code.
Additionally, there is no effective way to do a test in
Mathematica that I can see. NSum cannot be used with Set when
undefined symbols are involved. And when Set is used with Sum, a
symbolic result is obtained (which is the source of the problem)
and the underlying code for Sum is not used when numerical
values are later given to those variables. In short, I see no
way to separate the effects of Set and SetDelayed from possible
differences between Sum and NSum.
My reason for believing Sum calls the same code as NSum when
given machine precision numbers is based on a memory of
something I had read. However, I've been unable to find
something in the current documentation that confirms my belief.
In any case, I think there is a clear principle present in
Mathematica that when numeric values are wanted with machine
precision input, functions that begin with N should be used in
preference to their counterparts that do not begin in N. And I
think it is clear that doing applying the function N to a result
obtained using a function designed to return symbolic or exact
results is generally not the same as using the set of functions
that begin with N. That is I believe Wolfram writes code that
addresses numerical issues in functions that start with N that
is generally not called in the counterpart functions that do not
begin with N. Or said differently, I think those functions that
begin with N were put in Mathematica for good reasons and should
be used when numerical results are wanted.