NormalQuantily/StudentTQuantily values have wrong sign

Bugs in ND1 (report'em, get'em fixed)

NormalQuantily/StudentTQuantily values have wrong sign

Postby alm » Tue Apr 03, 2012 3:12 pm

Values from nQaunt and tQuant appear to have the wrong sign. NormalQuantile(0.975) returns approx. -2, yet 0 1 -2 nCDF returns 0.022. NormalQuantily(0.025) returns 2, which is also incorrect. The same applies to tQuant (similar results with df=100). This is with ND1 1.4.1 on iOS 4.3.2 (iTouch 4th gen). My guess is that there's a bug in the algorithm that's supposed to use -NormalQuantily(1-p) for p > 0.5, as suggested in the HP Museum thread you linked to earlier.

I also noticed that nCDF appears to be missing from the stat menu, did I screw it up somehow (I already restored the calculator) or is this a deliberate decision?
alm
 
Posts: 12
Joined: Sat Jul 16, 2011 12:26 pm

Re: NormalQuantily/StudentTQuantily values have wrong sign

Postby alm » Wed Apr 04, 2012 11:22 am

nCDF does not appear to be a standard ND1 function, not sure where I got it from, but that explains its absence from the stats menu.
alm
 
Posts: 12
Joined: Sat Jul 16, 2011 12:26 pm

Re: NormalQuantily/StudentTQuantily values have wrong sign

Postby oliver » Wed Apr 04, 2012 12:14 pm

Thank you for reporting!

I will fix this for the next update.

Here's the full code for the function's implementation, in case you're interested:
Code: Select all
      "NormalQuantile": function(x) { // as per http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/forum.cgi?read=182786#182786
         if (x <= 0) return +Infinity; else if (x >= 1) return -Infinity;
         var z, p = Math.min(x, 1-x), s = this.sign(0.5 - x);
         if (p < 0.2) { var u = -2*this.ln(p); z = Math.sqrt(-2*this.ln(p*Math.sqrt((u-1)*2*Math.PI))) + 1/(u*u); }
         else { var u = (0.5-p)*Math.sqrt(2*Math.PI); z = u + (u*u*u)/6;   }
         var k = 3;
         do {
            var t = (this.NormalDistribution(0, 1, z)-p)/this.NormalPDF(0, 1, z);
            z = z + t/(1 - t*z/2);
         }
         while (--k);
         return z*s;
      },


Are you sure the results for <0.5 are wrong? They seem to match the values discussed in the thread (e.g., 1.28155... for 0.1).

I'd like to look at accuracy but struggled to find an online tool that could provide quantile reference results. I tried WolframAlpha and (stock) Keisan, to no avail.

Did you, per chance, find/use one?

Thanks for the nCDF clarification. You had me wondering how you computed it...
If you have your own implementation, you know that you can add it to the Stat menu yourself on the Definition page, right? (And you're, of course, more than welcome to share it. A Statistics downloadable folder will manifest itself sooner or later...)
oliver
Site Admin
 
Posts: 433
Joined: Sat May 01, 2010 2:11 pm

Re: NormalQuantily/StudentTQuantily values have wrong sign

Postby oliver » Wed Apr 04, 2012 12:47 pm

Upon glancing over the museum thread a bit more carefully, I found the keisan stock reference function: normalicd.

The ND1 result for 0.025 matches the keisan result to all but the last digit. So, I'm going under the assumption for now that results for x<0.5 are already correct. Please correct me, if you think this is wrong.
oliver
Site Admin
 
Posts: 433
Joined: Sat May 01, 2010 2:11 pm

Re: NormalQuantily/StudentTQuantily values have wrong sign

Postby oliver » Wed Apr 04, 2012 12:54 pm

Hmm. keisan says normalicd(0.975) is -1.95996398454005423552.
oliver
Site Admin
 
Posts: 433
Joined: Sat May 01, 2010 2:11 pm

Re: NormalQuantile/StudentTQuantile values have wrong sign

Postby alm » Wed Apr 04, 2012 1:06 pm

I dug a little deeper, and I guess they were designed to mirror HP's UTPN/UTPT functions, which calculate the normal/t upper-tail probability. This is defined as the integral of the pdf from x to +infinity, or 1-cdf. I'm not sure why HP chose to define it this way. Every other program I have used defines it from -infinity to x. Renaming UTPN to Normal (why not NormalCDF by the way?) hides this fact. As does naming a function 'nQuant'. Some other programs I've tried:

WolframAlpha/Mathematica:
InverseCDF[NormalDistribution[0, 1], 0.975] = 1.95996

R:
> qnorm(0.975)
[1] 1.959964

MATLAB:
>> norminv(0.975)
ans =
1.9600

Octave:
octave:1> norminv(0.975)
ans = 1.9600

Maple:
> with(stats):
> statevalf[icdf,normald[0,1]](0.975);
1.959963985

In my opinion the functions should either be renamed to reflect the different definition (like UTPN), or the function should return values consistent with the common definition. I'm sure both introduce backwards compatibility issues, however.

Some references (random Google results, don't have any textbooks handy) that define the quantile function as inverse CDF:
https://en.wikipedia.org/wiki/Quantile_function
http://www.stat.wmich.edu/s160/book/node39.html
http://mathworld.wolfram.com/Quantile.html (this is very 'helpful', giving 9 definitions, but I don't think any of them agrees with the current result)
http://www.solvemymath.com/online_math_calculator/statistics/continuous_distributions/normal/quantile_normal.php
http://math.stackexchange.com/questions/51230/quantile-function-with-normal-distribution-and-weibull-distribution

I didn't find any supporting the current definition.
alm
 
Posts: 12
Joined: Sat Jul 16, 2011 12:26 pm

Re: NormalQuantily/StudentTQuantily values have wrong sign

Postby alm » Wed Apr 04, 2012 1:14 pm

Funny, the Keisan calculator supports both normalicd() and normalicdlower(). They also define normalcd() as integral from x to +infinity, and normalcdlower() for the integral from -infinity to x. I wonder where that definition came from? It disagrees with Mathworld and any textbook I've seen.
alm
 
Posts: 12
Joined: Sat Jul 16, 2011 12:26 pm

Re: NormalQuantily/StudentTQuantily values have wrong sign

Postby oliver » Wed Apr 04, 2012 2:40 pm

Thank you very much for your research and feedback. Much appreciated.

With keisan and HP adopting the upper tail default, I guess I will have to stick with it, but I'll consider changing the Modern naming and/or making both definitions available.

Latter makes the most sense, and will probably be done in one sweep of new statistics functions provided by an extra Statistics folder, via a new kind of integration that will appear with the upcoming CAS, very soon.
There'll be a proper announcement still this week, but here it is: ND1's CAS will be Mathematica via WolframAlpha commercial API. Results will be delivered as native objects into the stack (that is, you get normal looking expressions or numerical results--nothing about bringing you to the W|A site).

The system will be user-extensible. If you know how to do a computation in WolframAlpha, you can very easily build a ND1 function that will use inputs from the stack, do the query behind the scenes, and deliver the result to the stack.

So, for Mathematica syntax understood by W|A, such as the one you just told me, InverseCDF[NormalDistribution[0, 1], 0.975] (THANK YOU for that; I had not figured that out), you can write a function in one line of code that will do the job. Call it nQuantile and it will actually do what you want it to do! (Only drawback: you need to be connected to the network and it takes ~2s.)

Thanks again.

P.S. "normal" is just the naming of the key-cap, by the way. The function itself is named "NormalDistribution" (you see that, if you start an expression and then press the key). This still doesn't reveal the upper-tail character, of course. The problem with key-caps is finding names that fit into 6-8 characters and are not too cryptic. Not so easy for stat functions. I doubt any non-HP people would ever figure out what UTPN is. Or that NDIST really is NormalPDF.
oliver
Site Admin
 
Posts: 433
Joined: Sat May 01, 2010 2:11 pm

Re: NormalQuantile/StudentTQuantile values have wrong sign

Postby alm » Wed Apr 04, 2012 3:34 pm

The obvious thing to do is at least update the reference documentation to reflect the non-standard (outside HP and Keisan) definition.

I see your point about wanting to stick to the HP and Keisan (does this reflect the Casio standard?) definition. TI uses the lower tail definition of CDF and inverse CDF on their 83, by the way.

If you make both definitions available, putting upper/lower in the name in some way would probably make sense, since neither seems intuitive for all of the users. HP users will expect the upper definition, and almost everyone else the lower. The function name could be changed easily to something like NormalQuantileUpperT/NormalQuantileLowerT. I wouldn't have guessed what UTPN stood for, so I would use something else for the key caps in the modern layout. For the CDF, how about nCDFu (and an optional nCDFl)? This would be (mostly) consistent with nPDF (more intuitive than 'normal', which doesn't indicate that it's a distribution function IMO), and should easily fit. You could also use FCDF(u?) and χCDF(u?) (does iOS font have a lowercase chi?).

nCDF should be fairly intuitive, and users would have to check the documentation to understand the u/l suffix. I don't see any way around the latter, it's hard to explain upper tail / lower tail in 1-3 characters. At least they would remember next time.

nQuant is harder. nQuantU might be too long, and I don't like either an uppercase or lowercase 'u' there. How about 'I nCDFu' or 'nCDFu^-1' (this forum doesn't do superscript), for inverse nCDFu? It becomes a bit of an alphabet soup, but inverse CDF seems to be a more common term than quantile (only R used a name derived from quantile in my quick survey of math packages, including Keisan and a TI calc). I couldn't find an example of inverse functions (except IFFT) in the current menus to follow. Putting an I before an n is probably confusing.

The most important is to make the definition obvious, I can see why providing both would not make sense, and writing custom functions is of course completely trivial, nCDFl = 1 - nCDFu, and nCDFl^-1 = - nCDFu^-1.

The W|A integration is an interesting choice. Not that useful for iTouch or iPad w/o 3G users, but using one of the existing open-source ones or rolling your own won't ever come close in features and quality. The seamless integration is definitely something cool I've not seen before. I'll probably just stick to one of the competing CASes for iOS, however.
alm
 
Posts: 12
Joined: Sat Jul 16, 2011 12:26 pm

Re: NormalQuantily/StudentTQuantily values have wrong sign

Postby oliver » Thu Apr 05, 2012 3:27 am

Thanks for all your name ideas! I shall ponder them. And, yes, the documentation is the first thing that will be changed to properly explain what those functions do.

I looked into on-board CAS options (Xcas, Reduce) but ultimately the quality aspect made me go for Mathematica thru W|A. I'm hoping users will actually pick up the extensibility feature because a) it's so easy to use, and b) W|A has *a lot* to offer for custom functions (within and outside pure math).

Notwithstanding the CAS in the cloud, built-in math abilities will improve. Specifically, symbolic differentiation, Taylor, and solving are gaping holes that will be plucked with updates.
oliver
Site Admin
 
Posts: 433
Joined: Sat May 01, 2010 2:11 pm


Return to Bugs

Who is online

Users browsing this forum: No registered users and 1 guest

cron