1.  08/17/2009, 05:20 PM Hi TomJ> I'm not emulating any specific keyboard from an existing real-life calculator. It just emulates the look of the HP1xC range, not the layout. Here's what I have in mind, please let me know what you all think before I do it because it involves a few changes. 1: CONV and % move to where x! and SQRT are now. 2: x! and SQRT move to where ->HEX and ->BIN are now 3: in the 2 spots freed by CONV and % I'll put a direct x<>y and RollDown (with shifted RollUp) 4: ->HEX, ->BIN etc. become shifted functions of numeric keys. This would probably be the last big keyboard rearrangement. After that I can just finish implementing the few unimplemented functions and possibly add some more. Opinions welcome! My shiny new TouchPad apps: Scientific RPN Calculator HD - Screamager HD
2.  08/17/2009, 05:30 PM Originally Posted by TheMarco If there's a formula for small datasets I can implement it. Can you point me to the formula? The formula that the HP-15C used is in Appendix A, p206 of the manual here: http://hp15c.org/hp15c.pdf I coded that formula up in Excel, and get a value of 1 for stdev(2,3,4). Just for my sanity: could you possibly have a look at the examples in the HP15c manual and verify that at least those are working as they should? I used those myself for testing but of course it's possible that I overlooked something. I'll try to work through those later this evening. quicksilver: I'll think about the pi thing. Maybe dwhitman can tell me what his HP15c does with this? There IS a difference between how my HP-11C (the 15C is packed away) and v1.0b21 handles quicksilver's example: 1 enter pi enter HP-11C: 1, 3.142, 3.142 1.0b21: 1,1, 3.142 That said, I don't know why quicksilver uses either of those "enter" keystrokes. I'd just do: 1 pi HP-11C: 1, 3.142 1.0b21: 1, 3.142 There's a section in the appendices of the HP-15C manual that might offer a different way of thinking about stack handling that might at once simplify your code, and make a whole bunch of apparently special cases suddenly become more ordered. Look at page 209-211 where they classify operations on the calculator as either stack lift enabling, stack lift disabling or stack lift neutral. I never paid a whole bunch of attention to this section, but suspect it might be a real rosetta stone to one trying to emulate these operations.
3.  08/17/2009, 06:08 PM Originally Posted by dwhitman The formula that the HP-15C used is in Appendix A, p206 of the manual here: http://hp15c.org/hp15c.pdf I coded that formula up in Excel, and get a value of 1 for stdev(2,3,4). I'll try to work through those later this evening. There IS a difference between how my HP-11C (the 15C is packed away) and v1.0b21 handles quicksilver's example: 1 enter pi enter HP-11C: 1, 3.142, 3.142 1.0b21: 1,1, 3.142 This is because pi now lifts the stack (pushing what's in the display up one level). I still need to 100% figure out when to clear the display and when not to prevent this kind of weird behaviour. That said, I don't know why quicksilver uses either of those "enter" keystrokes. I'd just do: 1 pi HP-11C: 1, 3.142 1.0b21: 1, 3.142 Agreed. This is what I'd use too. There's a section in the appendices of the HP-15C manual that might offer a different way of thinking about stack handling that might at once simplify your code, and make a whole bunch of apparently special cases suddenly become more ordered. Look at page 209-211 where they classify operations on the calculator as either stack lift enabling, stack lift disabling or stack lift neutral. I never paid a whole bunch of attention to this section, but suspect it might be a real rosetta stone to one trying to emulate these operations. This is excellent. Maybe I can use this and run through ALL functions in order to emulate this exactly. Overall remark: The reason why all this is taking a lot of time and tinkering is because it seems I've now reached a level where no one else has really gone before. I've looked at tons of online JSJSJS \$RPN\$ \$calculators\$ \$but\$ \$I\$'\$m\$ \$now\$ \$at\$ \$a\$ \$point\$ \$where\$ \$mine\$ \$is\$ \$way\$ \$more\$ \$advanced\$ \$than\$ \$anything\$ \$else\$ \$out\$ \$there\$. \$At\$ \$least\$ \$more\$ \$advanced\$ \$than\$ \$anything\$ \$else\$ \$I\$'\$ve\$ \$personally\$ \$found\$. \$Also\$, \$most\$ \$of\$ \$the\$ \$ones\$ \$found\$ \$online\$ \$have\$ \$more\$ \$quirks\$ \$than\$ \$mine\$ \$rather\$ \$than\$ \$less\$. Bear with me guys, At some point I'll get all of this 100% right. I'm determined! My shiny new TouchPad apps: Scientific RPN Calculator HD - Screamager HD
4.  08/17/2009, 08:29 PM Sorry, this is going to be long. Here are the results of running the statistical function examples from the HP-15C manual, p47-57. Executive Summary: 1.0b21 generally passes with flying colors, with some discussion around the Sx and Sy results, where 1.0B21 is calculating a different statistic than a HP-15C does - not wrong, but probably the less appropriate choice for most uses. Details: Example 1 keystrokes: 5 enter 3 Py,x HP-11C: 60 1.0b21: 60 conclusion: correct result Example 2 keystrokes: 52 enter 4 Cx,y HP-11C: 270725 1.0b21: 270725 conclusion: correct result (skipped the random number example, don't think my 11C has a RAN# function) Example 4, grain yield vs. nitrogen applied, many keystrokes). HP-11C results (I just learned that the 11C uses different registers than the 15C to store stat results, so we're hitting different RCL numbers in the two results): RCL 1 (sum of x values): 200.00 RCL 2 (sum of squared x values): 12000.00 RCL 3 (sum of y values): 31.01 RCL 4 (sum of squared y values): 200.49 RCL 5(sum of x-y products): 1415.00 1.0b21 results: RCL 3 (sum of x values): 200 RCL 4 (sum of squared x values): 12000 RCL 5 (sum of y values): 31.01 RCL 6 (sum of squared y values): 200.4899 RCL 7 (sum of x-y products): 1415 conclusion: taking different register use into account, correct result Example 5: keystrokes: 4.78 enter 20 sigma- 5.78 enter 20 sigma plus HP-11C results: X = 5 RCL 3 (corrected sum of y values) 32.01 1.0B21 results X = 5 RCL 5(corrected sum of y values) 32.01 conclusion: taking different register use into account, correct result Example 6: mean HP-11C x-bar: 40 y-bar: 6.40 1.0b21 x-bar: 40 y-bar: 6.402 conclusion: correct result Example 7: standard deviation HP-11C Sx: 31.62 Sy: 1.24 Sx: 28.284 Sy: 1.1065 Conclusion: discrepency between the two calculators. Discussion: p53 of the HP-15C manual points out that the s function calculates an estimate of the population standard deviation from sample data, i.e. this is the SAMPLE standard deviation. If the data entered constitutes the entire population, you can correct the calculated value by multiplying by sqrt((n-1)/n) to get the population standard deviation (which is generally represented with a lower case sigma, not the letter "s"). In this example, n=5 so the correction is sqrt(4/5) = 0.89. Multiplying the HP-11C results by this number gives the 1.0b21 results. Bingo! So, which result set is right? Well, that depends on what the numbers you're entering represent. Any experiment I've ever done, the sample standard deviation "s" is the right one, and it is the correct one for the grain yield vs. nitrogen used example. You only calculate sigma if you literally have covered all possible inputs to the experiments, which in the case of real number variables, isn't possible. Note that if you collect a LOT of data so that n is large, s approaches little sigma asymptotically, since the correction goes to 1. That's what I was vaguely trying to remember about small vs. large data sets from oh-so-long ago when I had a statistics class. Example 8: linear regression: HP-11C y-intercept: 4.86 slope: 0.04 1.0b21 y-intercept: 4.856 slope: 0.03865 Conclusion: correct result Example 9: linear estimation and correlation coefficient HP-11C predicted yield for 70 tons nitrogen: 7.56 r: 0.99 1.0b21 predicted yield for 70 tons nitrogen: 7.5615 r: 0.98795 Conclusion: correct result
5.  08/17/2009, 09:41 PM Wow thanks man! This is great! Now the big question is: Do we use the correction or not? A hybrid solution is possible as well by setting some sort of treshold: use the correction when n < [a value DBD] and not when n >= [a value TBDTBDTBD] What makes most sense you think? My shiny new TouchPad apps: Scientific RPN Calculator HD - Screamager HD
6.  08/17/2009, 09:41 PM Originally Posted by TheMarco ... Finally, a big fat f*** you to whoever is making an effort to down-vote the rating on my app. It's gone down quite a lot suddenly. Even though I'm the author saying this, I know this is an A-class app that doesn't deserve that kind of petty stuff. Surely they should implement the same mechanism as with polls. ie one user one vote. It would probably be the same dipstick voting multiple times.
7.  08/17/2009, 09:54 PM Originally Posted by TheMarco Wow thanks man! This is great! Now the big question is: Do we use the correction or not? A hybrid solution is possible as well by setting some sort of treshold: use the correction when n < [a value DBD] and not when n >= [a value TBDTBDTBD] What makes most sense you think? Except for some very special cases, the statistic the HP-15C calculates is generally the right one. What I was remembering as two different formulas is just the convenience that as n gets large, you can ignore part of the equation and do the simpler calculation, since one of the terms approaches 1 as n gets big and can safely be ignored. If you do the full calculation, you're always right although you're doing more work for a tiny refinement when n is big. Little sigma is almost a theoretical thing, something you calculate if you literally know the entire population of inputs and results that can possibly occur. In the case of inputs that are real numbers (i.e. numbers with decimal points) there is no way to have the entire population experimentally, since there are always inputs in-between the one's you choose so that you're always working with a (hopefully representative!) sample of the real population. So you calculate s, not sigma, and if your budget is big enough, you collect enough data so that n is big and the difference is moot since s--->sigma at large n. So, no need for a threshold - the function itself does that. As n gets big, the HP-15C function evaluates to the same result that your current function does. It's automagic.
8.  08/17/2009, 10:24 PM Replying to myself. I don't think I'm doing a good job of expressing the difference between s and little sigma, confusing myself and I'm sure everyone else. Let me try doing a better job, and please remember I'm not a statistician, just a scientist who (weakly!) uses statistics. little sigma is an almost theoretical statistic that you calculate if you know the true distribution of observations around the mean. Like if for theoretical reasons you could literally write down a function that described the expected distribution of observations around the mean. As experimentalists, we almost never have that luxury. We generally assume that our observations follow the "normal distribution" around the mean, but this is a hypothesis, and one that is often not really supported by the data we collect; for example, data can be skewed so that the distribution around the mean is not symmetrical, unlike the normal distribution which is perfectly symmetrical. Given the observations that we do have, we can calculate s as our best estimate of what the value of sigma is, if we make the assumption that the scatter in our data follows the normal distribution. Our estimate is pretty shaky if we have only a little bit of data to support it, so the equation makes the uncertainly wider for small n. The functional form tightens as n gets bigger because we're more confident of our estimate with more data to support it. Bottom line: when we have experimental data rather than a theoretical requirement of the functional form of the distribution, s is the proper statistic to calculate. And the HP-15C manual gives the proper equation for s.
9.  08/18/2009, 12:39 AM dwhitman thanks for the brilliant testing. Awesome! It's about time I add you to the credits for all this In the next release I'll try to change the formula to the one from the manual. New B22 release uploaded. Changes in this release: - New app icon - Fixes issues with entering larger numbers - Fixes issues with entering zeroes after the period - Fixed an issue where haptic feedback couldn't get switched off and on properly - Made Stack Display go on and off immediately after changing the preference for it Enjoy! My shiny new TouchPad apps: Scientific RPN Calculator HD - Screamager HD
10.  08/18/2009, 02:29 AM Function request. (assuming that others also want it) Polar <-> Rectangular coordinates conversion. For those not familiar with it, this is useful so that you can use the x,y summation available with the statistical 'sigma' function to add vectors. The conversion can also be used for complex number operations. The procedure for vector summation is... For each vector, enter direction and magnitude, convert to rectangular (x,y) and sum (sigma). When all vectors are entered, RCL 1 (sum of x values), RCL 3 (sum of y values), convert to polar, and the x register then contains the resultant magnitude and the y register the resultant direction. Since there is no 'I agree' button, and to save extra posts, maybe people could just click the 'Thanks' button to indicate an interest in this.
11.  08/18/2009, 12:29 PM Originally Posted by TheMarco Hi TomJ> I'm not emulating any specific keyboard from an existing real-life calculator. It just emulates the look of the HP1xC range, not the layout. Here's what I have in mind, please let me know what you all think before I do it because it involves a few changes. 1: CONV and % move to where x! and SQRT are now. 2: x! and SQRT move to where ->HEX and ->BIN are now 3: in the 2 spots freed by CONV and % I'll put a direct x<>y and RollDown (with shifted RollUp) 4: ->HEX, ->BIN etc. become shifted functions of numeric keys. This would probably be the last big keyboard rearrangement. After that I can just finish implementing the few unimplemented functions and possibly add some more. Opinions welcome! I would make just one very minor tweak to this: starting with the layout changes you note, I would suggest you swap the SQRT and CONV key positions. The thought is to keep the x^2 and SQRT keys together. Otherwise, this new layout looks GREAT! I especially like the inclusion of the shifted roll up, which I hadn't even mentioned -- good catch! And thanks! Regards, Tom
12.  08/18/2009, 01:17 PM Originally Posted by johncc Function request. (assuming that others also want it) Polar <-> Rectangular coordinates conversion. Agree - I asked for this as well several pages back, but haven't seen it show up yet. Consider this my second request Also, the stack operates a little differently than the standard HP stack. Once you fill up all the registers, as you perform operations, this program begins to show zeroes in the upper registers as they are freed up. HP's don't do this. They keep the number of the uppermost stack item and continue to populate the stack with these. This is how you get a constant to multiply or divide with in HP RPN (or add/subtract). Example. Suppose you've entered some numbers and the stack looks like this: b: 2 a: 4 y: 3 x: 1 display: 1 Now, if I press "+", the stack shows: b: 0 a: 2 y: 4 x: 3 display: 2 In HP, the b part of the stack would remain at 2. As I perform another "+", the HP stack would show this: b: 2 a: 2 y: 2 x: 4 display: 5 In this program, the a and b stack show up as 0. Overall, a really nice program. I still give it 5 stars. I would still like the rolldown operation for the stack as I asked about before, to go along with the x <--> y stack operation. I see I can move the stack around another way, but it takes more time/effort than having the stack rolldown function. On edit: let me say this is one of best HP emulations out there, and well done. The blend of the Pre's abilities with the HP's functionality is a great combo, and all the comments by others plus TheMarco's development efforts are going to make this a fantastic app for those of us who use HP calculators and RPN. Last edited by jp99; 08/18/2009 at 01:21 PM. Reason: added final paragraph
13.  08/18/2009, 01:24 PM It's easy for me to change this stack behavior. I find it a bit strange that new values that didn't used to be on the stack appear out of nowhere but... I guess this is useful somehow? Opinions welcome! My shiny new TouchPad apps: Scientific RPN Calculator HD - Screamager HD
14.  08/18/2009, 01:27 PM Also: polar/rectangular coordinates sounds like a good idea. However, I'm now first focusing on finishing the already visible on the keyboard but not yet functional features, optimizations/bugfixes and adding a help section. After this I'll start adding features again! No worries, all feedback in this thread is noted, even if I don't respond to every bit My shiny new TouchPad apps: Scientific RPN Calculator HD - Screamager HD
15.  08/18/2009, 02:38 PM Originally Posted by TheMarco I find it a bit strange that new values that didn't used to be on the stack appear out of nowhere but... I guess this is useful somehow? Opinions welcome! Although I rarely take advantage of the functionality, I will at least corroborate that this is how all the HP calcs I've ever owned work. And, I have to say, it is one of the things I noted while checking out stack functionality on this calculator for the first time. I'd definitely vote for adding it, just because I think it'll be expected by a lot of users, moreso than anyone expecting values past the stack pointer to be a well-defined "0" as it appears to be now. Regards, Tom
16.  08/18/2009, 04:49 PM It's easy for me to change this stack behavior. I find it a bit strange that new values that didn't used to be on the stack appear out of nowhere but... I guess this is useful somehow? Opinions welcome! I can't say that this would effect me one way or the other but there's certainly merit in using the same behavior as the calculators that you're emulating. Here's what I have in mind, please let me know what you all think before I do it because it involves a few changes. 1: CONV and % move to where x! and SQRT are now. 2: x! and SQRT move to where ->HEX and ->BIN are now 3: in the 2 spots freed by CONV and % I'll put a direct x<>y and RollDown (with shifted RollUp) 4: ->HEX, ->BIN etc. become shifted functions of numeric keys. I had intended to vote for this arrangement but I just grabbed my Pre to perform a quick calculation out on the floor and discovered that I don't care for the way the change in base units is setup. On the three calculators I use you specify the base (hex, bin, decimal, octal) and work with it in that mode. Whatever values are in the stack are converted to the active base. With this Scientific RPN Calculator you can convert but you have to do that with every value. In addition there's no way (or I couldn't figure out what it is) to enter the values in anything other than DEC so it's a one way conversion. That also means that the ->DEC function is un-needed. If you used a base key you could not only make the base conversion more useful but you would free up at least one primary key and a bunch of shifted keys. My 32SII uses the top row of keys to enter A,B,C,D,E and F while in HEX mode since they're assigned to functions that would return floating point values in DEC mode. Free42 and the 42S that it emulates use a similar system but with a menu with values assigned to the top row of keys. You don't have enough keys in the top row for this to really work nicely but you could wrap around to the second row for the F.
17.  08/18/2009, 07:04 PM I'm not entirely sure how much hex, oct, bin support I want to put in (at least at first). The ->HEX, ->BIN etc. are merely convenience buttons to do a quick conversion (display only, it does nothing with the stack or anything). Working with different bases only becomes useful if you add a slew of other functionality which I haven't really planned for at this moment. Possibly in the future but for now there's other stuff I want to finish first. My shiny new TouchPad apps: Scientific RPN Calculator HD - Screamager HD
18.  08/18/2009, 07:53 PM I'm not entirely sure how much hex, oct, bin support I want to put in (at least at first). The ->HEX, ->BIN etc. are merely convenience buttons to do a quick conversion (display only, it does nothing with the stack or anything). Working with different bases only becomes useful if you add a slew of other functionality which I haven't really planned for at this moment. Possibly in the future but for now there's other stuff I want to finish first. That makes sense. I wonder if there's any need to use up two keys and two g-shift spots for the current functionality. Were it me I'd leave them right off and add a shifted base key at a later date. If you're only doing one way conversion you could add base conversion to your conversion buttons.
19.  08/18/2009, 08:15 PM OK guys, here's the proposed new keyboard layout. Please let me know what you think! Attached Images calc7.png (31.0 KB, 17 views) My shiny new TouchPad apps: Scientific RPN Calculator HD - Screamager HD
20.  08/18/2009, 09:28 PM It looks good! And leaves room for additional functionality later with additional shifted keys.