HP Forum Archive 20

[ Return to Index | Top of Index ]

{WP34S] Minor stats bug Message #1 Posted by Nigel J Dowrick on 30 Oct 2011, 11:22 a.m. I'm running Build 1784 (on the actual calculator, not the emulator.) The function NORML returns the cumulative normal probability distribution from negative infinity up to its argument, for a distribution with mean stored in register J and spread in register K. When J contains 1 and K contains 10^-40, NORML returns 0 for an argument less than 1, 0.5 for an argument of 1, and 1 for an argument greater than 1. This is correct behaviour. However, when J contains 1 and K contains 0, NORML simply returns its argument, whatever that argument is. This is unlikely to be a problem, but I think it's a bug! Nigel (UK)

Re: {WP34S] Minor stats bug Message #2 Posted by Dieter on 30 Oct 2011, 11:40 a.m., in response to message #1 by Nigel J Dowrick Sounds like an error in the routine that checks for valid inputs: a zero standard deviation should throw an error here. BTW the same happens in the student case with an illegal parameter (d.o.f. =< 0) - in this case simply X is returned as well, while the routine is supposed to return an error message. Also, Norml-1 behaves the same way for illegal parameters, e.g. sdev in K =< 0. So there seems to be a general problem with the initial tests in the statistical distributions. Which should not be too difficult to fix. ;-) Dieter

Re: {WP34S] Minor stats bug - fixed Message #3 Posted by Marcus von Cube, Germany on 30 Oct 2011, 12:46 p.m., in response to message #2 by Dieter Since I did some updates to the error handler it's probably my fault. Does 0 1/x still throw an error? EDIT: It was my fault (sort of) and should be ok now. Edited: 30 Oct 2011, 1:28 p.m. after one or more responses were posted

Re: {WP34S] Minor stats bug Message #4 Posted by Dieter on 30 Oct 2011, 1:20 p.m., in response to message #3 by Marcus von Cube, Germany Yes, at least in 2.2. 1782 this returns an error ("+infinity"). Dieter

Re: {WP34S] Minor stats bug Message #5 Posted by Marcus von Cube, Germany on 30 Oct 2011, 1:28 p.m., in response to message #4 by Dieter Should be fixed now.

Re: {WP34S] Minor stats bug Message #6 Posted by Dieter on 30 Oct 2011, 4:23 p.m., in response to message #5 by Marcus von Cube, Germany Fine. I use the emulator and downloaded v. 1791 of wp34s.exe and wp34sgui.exe to replace the existing files in v. 1782. Now there is an error message, as expected. However, I saw that the student distribution t(x) accepts non-integer degrees of freedom (which is a thing that may be discussed), and even values between 0 and 1. Is this the way the function is supposed to work? BTW - the manual lists Norml (pdf) first, then Normlp (cdf), while the corresponding explanation states the cdf first, then the pdf (i.e. the other way round). This should be corrected. And finally: please do not compare these functions with the ones used in Excel (cf. footnotes). The 34s does not return hilariously incorrect results like the ones Excel may come up with. ;-) Dieter

Re: {WP34S] Minor stats bug Message #7 Posted by Walter B on 30 Oct 2011, 5:15 p.m., in response to message #6 by Dieter FYI, within the Index of Operations, the manual generally lists the command names in alphabetical order since they appear in the catalogues in that order as well (see page 33 for more). Distributions share a common remark, wherein the general order is pdf/pmf, cdf, inverse cdf. And I know Excel is far from excellent. It's just a tool most people have access to on their PCs. Walter

Re: {WP34S] Minor stats bug Message #8 Posted by Dieter on 30 Oct 2011, 6:14 p.m., in response to message #7 by Walter B I don't think it's a good idea if understanding a non-obvious explanation on page 49 (Norml, Normlp and Norml-1) requires an additional information somewhere else in the manual. Especially in this case where things can be improved so easily for the reader: in the remarks column, simply mention the cdf first, then the pdf, then the quantile function. Simply use the same order as in the function column. Not only for the normal distribution, but for all others as well. I also would suggest omitting the term "pmf" completely. But maybe there is a native speaker with mathematical/statistical background here to say a bite more on this. As far as footnote 4 on p. 15 is concerned: cdf is "(Wahrscheinlichkeits-)Verteilungsfunktion" and pdf is "(Wahrscheinlichkeits-)Dichtefunktion". It's really that simple. ;-) Dieter Edited: 31 Oct 2011, 3:41 p.m. after one or more responses were posted

Re: {WP34S] Minor stats bug Message #9 Posted by Paul Dale on 30 Oct 2011, 6:22 p.m., in response to message #8 by Dieter I'm a native speaker and completed undergraduate and postgraduate degrees in statistics at university many years ago. That ought to count as sufficient background :-) My understanding is that pdf is the term for continuous probability functions and pmf is the term for discrete ones. They are not interchangeable (although I tend to do so more than I should). - Pauli

Re: {WP34S] Minor stats bug Message #10 Posted by Dieter on 30 Oct 2011, 6:30 p.m., in response to message #9 by Paul Dale Ah, okay, in this case "pmf" of course has to stay where it is. However, to the best of my knowledge in German "Dichtefunktion" is used for both continuous as well as discrete probability functions. So the final sentence in footnote 4 should still get rewritten. Dieter

Re: {WP34S] Minor stats bug Message #11 Posted by Walter B on 31 Oct 2011, 3:41 a.m., in response to message #8 by Dieter Quote: I don't think it's a good idea if understanding a non-obvious explanation on page 49 (Norml, Normlp and Norml-1) requires an additional information somewhere else in the manual. I disagree. I don't think it's a good idea to pick an arbitrary location in the index without taking the slightest care of what was said before. Especially in this case where it's so easy to look up the table of contents for "Statistical ...", jump there, and find all explanations in a very concise text. Even the difference between pmf and pdf. While I can't change the alphabet ;-) the logical sequence IMHO is to start with the pdf/pmf, then sum up or integrate to get the cdf, then invert to get its inverse. Please try to find an easier alternative sequence ;-) Walter

Re: {WP34S] Minor stats bug Message #12 Posted by Alexander Oestert on 31 Oct 2011, 4:19 a.m., in response to message #11 by Walter B I agree with Dieter. When I first wanted to use those functions to follow my son's homework, I found the one I needed by the explanation on the right side of the table and used the calc function that corresponded to it on the left side - which was the wrong one.

Re: {WP34S] Minor stats bug Message #13 Posted by Walter B on 31 Oct 2011, 11:30 a.m., in response to message #12 by Alexander Oestert Ok ok, I modified the statistical texts a bit to make them even more - ummh, shall I say? - fool proof ;-) Please check the most recent manuals.

Re: {WP34S] Minor stats bug Message #14 Posted by Alexander Oestert on 31 Oct 2011, 12:10 p.m., in response to message #13 by Walter B Quote: fool proof ;-) Thank you, Walter, that's exactly what I (!) need! :-) And thanks again for all the hard work you've put into the manual.

Re: [WP34S] Minor stats bug Message #15 Posted by Alexander Oestert on 31 Oct 2011, 3:20 p.m., in response to message #13 by Walter B Just read the updated manual: very elegantly done, indeed, without changing the sequence inside the table!

Re: {WP34S] Minor stats bug Message #16 Posted by Dominic Richens on 31 Oct 2011, 4:50 p.m., in response to message #13 by Walter B Could you do something similar for Poisson? I believe that if you only want to specify the mean, it should go in K with 1 stored in J, since J needs to be less than or equal to 1.0 cheers!

Re: {WP34S] Minor stats bug Message #17 Posted by Dieter on 1 Nov 2011, 9:25 a.m., in response to message #11 by Walter B Quote: Please try to find an easier alternative sequence Obviously you found a solution yourself - great. :-) This leads to the question whether it's time for a general naming convention for the statistical distributions. Currently the binomial and normal cdfs are called Binom and Norml while the student and Fisher cdf are t(x) and F(x). The pdf has a subscript p suffix that on the calculator display is hard to identify as such. So what about a general and consistent naming convention. Assuming a maximum of six characters the pdf/pmf, cdf and quantile functions could be named like this: normpd binopd studpd poispd fishpd geompd ... normcd binocd studcd poiscd fishcd geomcd ... normqt binoqt studqt poisqt fishqt geomqt ... This would also improve the legibility of 34s programs and the usability in manual calculations: the user knows what he will get ...even without the manual. Dieter

Re: {WP34S] Minor stats bug Message #18 Posted by Walter B on 1 Nov 2011, 9:54 a.m., in response to message #17 by Dieter Quote: Quote: Please try to find an easier alternative sequence Obviously you found a solution yourself - great. :-) I didn't change the sequence at all :-) With respect to names, your suggestion reads well as long as all such functions are seen in one block as you put them. But if an arbitrary such function crosses your way without its companions you won't know it has to be read as four letters for its name and two letters for its type. That's the reason why I prefer a notation using indices and exponents: it allows for easy differentiation of function name and suffix. YMMV Walter

Re: {WP34S] Minor stats bug Message #19 Posted by Dieter on 1 Nov 2011, 12:57 p.m., in response to message #18 by Walter B Quote: With respect to names, your suggestion reads well as long as all such functions are seen in one block as you put them. But if an arbitrary such function crosses your way without its companions you won't know it has to be read as four letters for its name and two letters for its type I see. If the user comes across a function named "t(x)" it is completely obvious what it does while "studcd" will stay a miracle forever ?-) Come on... I would like to ask you - and the whole community of course - to consider the following aspects: You say that the suggested names look fine as long as they are seen side by side. That's exactly what they are. They will appear in the PROB menu one after the other: studcd, studpd, studqt. Or for the Normal case normcd, normpd and normqt. If you really think the function type does not stand out, simply use mixed case names: NormPD, NormCD, NormQu or StudPD, StudCD and StudQu. The current designation especially of the Student and Fisher distibution (t(x) resp. F(x)) is unintuitive, maybe even wrong. Suppose you want to determine the Student CDF for a certain value. You enter the PROB menu and you see a function named StudCD. Hmm... what may this function do ?-) On the other hand, the current names t(x) and F(x) will leave the user clueless unless they have been looked up in the manual. I even feel they are wrong since t(x) does not determine a t-value from x. On the contrary, it takes a t-value from x and returns its value of the Student CDF. That's why I think the proposed function names are a significant improvement over the current implementation. Dieter

Re: {WP34S] Minor stats bug Message #20 Posted by Alexander Oestert on 1 Nov 2011, 1:10 p.m., in response to message #19 by Dieter I very much second Dieter's proposal.

Re: {WP34S] Minor stats bug Message #21 Posted by Walter B on 2 Nov 2011, 2:52 a.m., in response to message #19 by Dieter Quote: You say that the suggested names look fine as long as they are seen side by side. That's exactly what they are. If you read a program and see a function named StudCD among good old RPN commands. Hmm... what may this function do ?-) Quote: If you really think the function type does not stand out, simply use mixed case names Which student needs a command to find a CD?? :-? Quote: The current designation especially of the Student and Fisher distibution (t(x) resp. F(x)) is unintuitive, maybe even wrong ... but common in statistics textbooks. Please turn to their authors ;-) FYI, in the beginning, I wanted to call all those functions like BINOM(n), BINOM-1(p), WEIBL(x), etc. but that exceeds six characters. Walter Edited: 2 Nov 2011, 3:06 a.m.

Re: {WP34S] Minor stats bug Message #22 Posted by Paul Dale on 30 Oct 2011, 5:22 p.m., in response to message #6 by Dieter Quote: However, I saw that the student distribution t(x) accepts non-integer degrees of freedom (which is a thing that may be discussed), and even values between 0 and 1. Is this the way the function is supposed to work? This was by design. I have no idea anymore why I did it :-( Adding a check for integer DoF isn't hard, is it warranted? - Pauli

Re: {WP34S] Minor stats bug Message #23 Posted by Dieter on 30 Oct 2011, 6:20 p.m., in response to message #22 by Paul Dale Quote: This was by design. I have no idea anymore why I did it :-( Adding a check for integer DoF isn't hard, is it warranted? Well, I can say that the intial guesses for the student and F-quantile were designed for integer d.o.f. values. I would say that at least values less than 1 should throw an error. Let's see what the community says on this. On the other hand, if you don't remember a good reason for the current implementation... ;-) Dieter

Re: {WP34S] Minor stats bug Message #24 Posted by Paul Dale on 30 Oct 2011, 6:27 p.m., in response to message #23 by Dieter I've changed the T and F distributions so that they require an integer for their degrees of freedom parameters. I vaguely remember seeing F distributions with fractional parameters but can't remember what for or why. Changing back is trivial if it is warranted. - Pauli

Re: {WP34S] Minor stats bug Message #25 Posted by Walter B on 31 Oct 2011, 2:58 a.m., in response to message #24 by Paul Dale I'd suggest to use the IP of J and K for computing those statistical functions. That's what some popular statistical tests do as well. Walter

Re: {WP34S] Minor stats bug Message #26 Posted by Paul Dale on 31 Oct 2011, 6:01 p.m., in response to message #25 by Walter B I'd suggest not. We don't truncate the n parameter for the binomial. Why should we truncate the DoF parameters here? In all cases it is possible to extend the definition of the distribution to have real parameters but we've not done so. Thus accepting a real parameter and truncating it is wrong anyway. - Pauli

[ Return to Index | Top of Index ]

Go back to the main exhibit hall