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.

**Re: Re: New Wolfram Tutorial Collection documentation is ready**

**Re: Clickable options**

**Re: Re: Bug with Hypergeometric2F1?**

**Re: Bug with Hypergeometric2F1?**