Look at this site under product tour, it takes you through each button function. Good graphics.
http://h20331.www2.hp.com/hpsub/cache/301034-0-0-225-121.html
HP 33S interactive site
|
|
« Next Oldest | Next Newest »
|
▼
02-28-2007, 01:08 AM
▼
03-01-2007, 12:46 AM
I think all of the present HP calcs have similar sites. Very helpful indeed! I like the wide collection of pdf downloads available, even if some of them do duplicate what is already in the manual. FWIW, I actually have a 33S routine for the normal and inverse normal distribution that is faster and more accurate since it works with the upper tail and doesn't depend on having to do an integration. I can share the listing if anyone wishes. I have also just acquired a 17bii+, and I must confess I rather like it, though I have yet to bash heads with any of its bugs. The solver, cashflow, and TVM applications are very neat to use. Les ▼
03-01-2007, 01:45 AM
Hi Les -- Would *definitely* be interested in your routines for the 33s. It's a great calc. Glad you're liking the 17bii+ -- Don and I have been having a blast with it -- admittedly sometimes frustrating -- and learning its nuances.
thanks! ▼
03-01-2007, 08:08 PM
Sure--basically, I have ported Baillard's HP41 routine for the error function, and added on another routine to compute the upper-tail normal distribution using it via the formula Q(x) = 0.5 erfc(x/sqrt(2)). Given this, you can set up a routine for the solver that finds x for a given upper-tail probability. Let me work out some of the inefficiencies and get the code to you in the next few days. I have made a preliminary submission to Dave but have asked him not to post it until I revise it. In the 33S memory saving isn't as important as efficient use of labels, and I am trying to find ways of reducing label usage even if it means repeating similar steps at various points in the program. Les ▼
03-02-2007, 02:31 AM
Here are those listings. Please note that the original routines for the HP41 are due to J-M Baillard and come from here, though I have necessarily had to retool things to work with the limitations of the 33S. Routine E computes erf and erfc for any real input using the alternating series expansion (http://mathworld.wolfram.com/Erf.html equation (6)) for x < 1.8 and the continued fraction expansion (a version of equation (33) on the same page, computed out to 35 terms) for larger values. Routine Q computes the upper tail and cumulative normal distribution using routine E and the relationship 1- P(z) = Q(z) = 0.5 erfc(z/sqrt(2)), where Q(z) is the upper tail and P(z) is the cumulative probability associated with z from a standard normal distribution (mean 0, variance 1). Routine I is basically a programmed equation to compute the inverse distribution using Solve. Thanks to the speed of the 33S, E and Q are surprisingly fast, returning a result in no more than a couple of seconds or so. Computing the inverse probabilities takes longer since it uses the solver and requires repeat evaluations of Q, but with decent initial guesses will return a result in under a minute, I find. Note in routine I I take the difference of logarithms. This is especially helpful when the probabilities get really tiny and it helps the Solver avoid converging prematurely since the difference between two tinies is a tiny and may signal convergence before it is desired. Taking logarithms lets the solver work with numbers of more normal magnitude.
E0001 LBL E Given any real x for input, XEQ E will return erf(x) in the X register and erfc(x) in the Y register. Given any real z for input, XEQ Q will return the upper tail normal probability associated with z in register X, and the complement lower tail cumulative probability in Y. For example 2 XEQ E returns erf(2) = 9.99532223502e-1 in register X and erfc(2) = 4.677734981e-3 in register Y. Similarly 2 XEQ Q returns Q(2) = 2.2750131948e-2 in register X (the upper tail probability associated with z = 2), and P(2) = 1 - Q(2) = 9.7724986805e-1 in register Y. To compute the inverse normal distribution, use the routine I with the Solver.
For example, to compute the z associated with an upper tail probability of 0.0001: Hope you get some use out of this. Les ▼
03-03-2007, 01:13 PM
Hi Les -- Looks great! Thank you. I'm out of town at the moment and didn't bring my 33s with me, but I'll take a gander at this next week. I appreciate the work.
thanks! ▼
03-03-2007, 07:05 PM
I have also produced a routine for the 42S that computes the cumulative normal and upper tail probabilities directly using formula 26.2.11 and 26.2.14 in Abramowitz and Stegun. I have discovered that with the 33S code above the scaling of the input by 1/sqrt(2) introduces rounding error that gets propagated throughout the calculations and leads to digit loss, so usually you can trust at most 10 digits and occasionally 11. Computing the cumulative normal distribution directly by its own series and continued fraction expansions tends to produce better results than routing the computation through erf and erfc. Of course, in Free42 with its 25 digits of precision, all of this is moot since there are so many guard digits internally that the 12 digits that get displayed, and then some (usually up to 20 or 21) are usually right. Of course, if you are interested in doing a lot better than, say, the SigmaNORMD routine in the HP41 Stat Pac, which uses an antiquated rational approximation that is prone to subtraction digit loss in the upper tail, then this routine will give great results as it is. I haven't ported the "normal distribution directly" routine to the 33S yet. It shouldn't be too hard, since there is nothing I did in the 42S routine that doesn't have a direct equivalent on the 33S. If you have any interest in this I will get to it when I can. The problem is I am running out of labels in my 33S! Looking at the relevant formulae in Abramowitz and Stegun, which can be found free online, is very informative. I think my point in all this is that I think it is more sensible and quicker to compute thes e things directly than by the numerical integration scheme in the 33S manual that takes at least a few seconds each time to give modest accuracy. Thanks to JM Baillard, I have also learned that it is feasible to write simple code that computes continued fractions from right to left that is fairly quick, and it takes just a little experimenting to discern how many iterations you should take for maximum accuracy. Les
03-02-2007, 02:09 AM
Edited: 2 Mar 2007, 2:09 a.m. |