▼
Posts: 167
Threads: 13
Joined: Sep 2008
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)
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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
▼
Posts: 653
Threads: 26
Joined: Aug 2010
Yes, at least in 2.2. 1782 this returns an error ("+infinity").
Dieter
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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 noninteger 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 Norml_{p} (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
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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
▼
Posts: 653
Threads: 26
Joined: Aug 2010
I don't think it's a good idea if understanding a nonobvious explanation on page 49 (Norml, Norml_{p} 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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
I don't think it's a good idea if understanding a nonobvious explanation on page 49 (Norml, Norml_{p} 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
▼
Posts: 429
Threads: 31
Joined: Jul 2011
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.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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.
▼
Posts: 429
Threads: 31
Joined: Jul 2011
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.
Posts: 429
Threads: 31
Joined: Jul 2011
Just read the updated manual: very elegantly done, indeed, without changing the sequence inside the table!
Posts: 228
Threads: 7
Joined: Aug 2011
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!
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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 tvalue from x. On the contrary, it takes a tvalue 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
▼
Posts: 429
Threads: 31
Joined: Jul 2011
I very much second Dieter's proposal.
Posts: 4,587
Threads: 105
Joined: Jul 2005
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.
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: However, I saw that the student distribution t(x) accepts noninteger 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
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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 Fquantile 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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
