HP 50g — import statistical data into hypothesis test

[cdmackay]

apologies if this is too obvious, but…

I've not done any statistics on my 50g before; I need to compare two small samples, and thought that it would be fun to try it.

I'm wanting to use the Student's t-test to compare the means of the two samples. I see hypothesis testing on the 50g, but it wants me to enter in the statistics already gathered from the samples, i.e. mean, sd & n for each sample.

On the Prime, it seems (from reading the manual) that a similar app (Inference) is able to import the sample data from the 1-var or 2-var apps.

Is this possible on the 50g? Or do I have to make a note of the calculated stats from each sample and then manually enter them into the hypothesis test app?

thank you…

[BartDB]

Hi,

You can copy the data as a text file to an SD card, then on the calculator recall it to the stack.
You will have to do some editing to put it into the correct data format (the command STR-> will be useful here)

If you have a 50g emulator on your PC, you can paste text data to the stack (Edit, Paste stack). Then do the editing to put it into the correct data format on the emulator and save it as a 50g object (Edit, Save Object). Then this can be copied to the calculator using the SD card.

EDIT:
On re-reading your post it seems you may need a program on the 50g to do a bit more statistical analysis. Look on hpcalc.org:
https://www.hpcalc.org/search.php?query=...ics&hp49=1

Regards.

[cdmackay]

Thanks very much Bart. I saw there were some relevant apps there, but as the 50g has an app built-in that does what I need (basic two-sample Student's t), I didn't investigate further.

It's just that there seems a disconnect between the single-var stats app's tools that calculate mean & sdev, and then having to enter those values manually into the stats app's hypothesis feature.

It may be that if I were doing it using functions alone, it might be easier (or not).

The Prime's Inference app's import feature makes this trivial; given its apps are otherwise quite similar to those on the 50g, I thought I might be missing something obvious.

thanks.

[cdmackay]

To put it another way, it seems that I need to do this, on the 50g:

1. enter sample data into the ΣDAT stats matrix, for each sample (possibly via two columns)
2. use the stat app single-var tool to calculate mean and sdev, for each sample
3. write those calculated values on a piece of paper
4. go to the hypothesis test tool, and manually re-enter those calculated values
   

I was hoping that I didn't have to manually record and re-enter the mean and sdev.

On the Prime, it's simpler:

1. enter sample data into the Stats 1Var app (via two columns)
2. optionally in that app, view the calculated mean and sdev, for each sample
3. go to the Inference app, hypothesis test and import from the Stats 1Var app
   

[Carsen]

(12-04-2018 07:27 PM)cdmackay Wrote:  3. write those calculated values on a piece of paper
4. go to the hypothesis test tool, and manually re-enter those calculated values

The values do not have to be written down on a piece of paper. If they are on the stack, you can use the HIST key to access the stack. Press HIST when you are in the T-Test environment, move the pointer to the value you want, press the soft menu ECHO, and then press ENTER.

Another way is to store the values in variables. I would use A, B, C... and so on. Then you could simply type ALPHA A or use the VAR menu in the T-Test environment to put in the value.

And of course, the power of programming can speed up the process greatly, depending on how far you want to go.

Ultimately, you are correct. A vanilla HP Prime will beat a vanilla HP 50g in this situation. It makes the HP Prime really cool in my eyes.

[cdmackay]

(12-05-2018 06:15 AM)Carsen Wrote:  The values do not have to be written down on a piece of paper…

thanks very much indeed, Carsen, I'll give this a try.

[cdmackay]

(12-05-2018 06:15 AM)Carsen Wrote:  The values do not have to be written down on a piece of paper. If they are on the stack, you can use the HIST key to access the stack. Press HIST when you are in the T-Test environment, move the pointer to the value you want, press the soft menu ECHO, and then press ENTER.

thanks Carsen; it doesn't seem quite that simple, at least in the two-sample case that I'm considering.

If I use a 2-column arrangement in ΣDAT and the forms-based STAT (RS-5), I can select the column corresponding to the sample I want and request mean and sdev, and what gets put on the stack is a tagged object, e.g:

Code:

Mean:3
Std Dev:1.58

so when I then try to use HIST/ECHO to enter it into the hypothesis form, I have to muck about removing the text tag prefix. Or I could use DTAG before going into the stats form. Or, as you say, store it in a variable which would remove the tag. But I have to do each line separately.

If I instead use the soft-menu stats from the 96 MENU, it can handle both columns at once, and I get the results as an array on the stack:

Code:

[3. 4.]
[1.58 1.58]

which might be slightly easier to access from the hypothesis form, once it's in a var. It's also slightly easier to store, since it's easier to do mean and sdev separately, with the soft-menu keys, instead of having to go into the forms menu twice (for each column) with the RS-5 STAT.

I think I am spoiled by the import feature on the Prime's Inference app

thanks again for the suggestions.

[cdmackay]

(12-06-2018 11:25 PM)cdmackay Wrote:  If I instead use the soft-menu stats from the 96 MENU, it can handle both columns at once, and I get the results as an array on the stack:

Code:

[3. 4.]
[1.58 1.58]

which might be slightly easier to access from the hypothesis form, once it's in a var.

looks like I can store those arrays in vars M & S, say, then from the hypothesis form I can edit a field like mean, to enter:

Code:

'M(1)' EVAL

and the corresponding mean gets entered. Then repeat for M(2), and then S(1)/S(2).

Is there a quicker way of getting an array element into a form?

[Carsen]

(12-06-2018 11:25 PM)cdmackay Wrote:  If I instead use the soft-menu stats from the 96 MENU, it can handle both columns at once, and I get the results as an array on the stack...

Actually, that is what I used to get the values in the stack. I simply didn't specify that. I put the array on the stack and used the OBJ-> command to retrieve the values out of the arrays, which is in the TYPE submenu in the PRG menu (LS PRG TYPE).

(12-06-2018 11:40 PM)cdmackay Wrote:  Is there a quicker way of getting an array element into a form?

I don't know how to getting an element into a form faster. I would have to play around and teach myself.

My Solution
If I had to use the T-Stat form all the time, this would be my solution on speeding things up. I would write a quick userRPL program like this...

Code:


<<  MEAN OBJ-> DROP SDEV OBJ-> DROP 'S2' STO 'S1' STO 'X2' STO 'X1' STO { X1 X2 S1 S2 } ORDER >> ***Assuming column 1 of ∑DAT is X and column 2 is Y.***

Then I could enter the T-Stat form and press VAR X1 ENTER VAR X2 ENTER and so on.

(12-06-2018 11:25 PM)cdmackay Wrote:  I think I am spoiled by the import feature on the Prime's Inference app

We both are!

[cdmackay]

That's very nice, thanks very much Carsen.

I was trying to get it as lean as possible without resorting to programming; but perhaps that's the wrong way of thinking? I'm new to the 50g, and its programming and customisation seem to be the most flexible areas, so I need to adjust my approach

(12-07-2018 04:22 AM)Carsen Wrote:  

Code:


<<  MEAN OBJ-> DROP SDEV OBJ-> DROP 'S2' STO 'S1' STO 'X2' STO 'X1' STO { X1 X2 S1 S2 } ORDER >> ***Assuming column 1 of ∑DAT is X and column 2 is Y.***

I hadn't thought of OBJ→, I was wondering about GET, but yours above is better.

Is the use of ORDER solely so it looks better with the VAR softkeys, and Filer?

thanks again, very useful.

[DavidM]

(12-07-2018 04:22 AM)Carsen Wrote:  

Code:


<<  MEAN OBJ-> DROP SDEV OBJ-> DROP 'S2' STO 'S1' STO 'X2' STO 'X1' STO { X1 X2 S1 S2 } ORDER >> ***Assuming column 1 of ∑DAT is X and column 2 is Y.***

I'm mostly ignorant of the statistical features of the 50g (and statistics in general), but looking at the above code, it strikes me that there's a simplification that might be useful here. STO has the ability to accept lists of both values and variable names, so an alternative form of the above could be:

Code:

\<<
    MEAN AXL SDEV AXL + REVLIST { S2 S1 X2 X1 } STO
\>>

STO iterates through the ID list in the order given, matching the IDs with the corresponding values in the list from stack level 2. Since the most recently stored object shows up at the beginning of your var list (assuming it hasn't already been stored in the current search path), I've reversed the order of values and IDs so that they end up in the desired order without having to execute the ORDER command. The downside to this is that subsequent calls to the program won't move the variables to the beginning of the directory. If this is important, a slight change to the above should take care of that:

Code:

\<<
    MEAN AXL SDEV AXL + { X1 X2 S1 S2 } SWAP OVER STO ORDER
\>>

Finally, a word of caution about the ORDER command:

If ORDER is executed from a running program, there's a particular situation that will cause it to throw an "Invalid Syntax" error. If the program object containing the ORDER command would itself be moved as a result of its execution, the command will fail, sometimes after already having moved some of the identified objects. I believe that's not likely to happen here, but it's useful to bear that in mind whenever using ORDER in a program.

[cdmackay]

(12-07-2018 05:30 PM)DavidM Wrote:  

Code:

\<<
    MEAN AXL SDEV AXL + REVLIST { S2 S1 X2 X1 } STO
\>>

oh, that's very neat, thanks very much David.

AXL is new to me; most of my limited 50g knowledge comes from studying the HLP49 help file, which uses AXL in a code snippet but doesn't detail it as a command. I should get more familiar with the AUR

thanks again, all who made suggestions. Clearly I have a lot to learn.

[Carsen]

(12-07-2018 05:55 AM)cdmackay Wrote:  I was trying to get it as lean as possible without resorting to programming; but perhaps that's the wrong way of thinking?

Well, it all depends on how much you plan to use the T-Stat form. If I had to use it frequently, I would create the program and keep it stored in my STATISTICS directory. On the other hand, if I didn't plan to use it frequently, then I would not use the program and stick to the OBJ-> and HIST method.

(12-07-2018 05:55 AM)cdmackay Wrote:  Is the use of ORDER solely so it looks better with the VAR softkeys, and Filer?

ORDER is used so that I can simply press VAR F1 ENTER VAR F2 ENTER VAR F3 ENTER VAR F4 ENTER (i.e. I don't have to hesitate and search for the variables in the VAR menu). However, David taught me the risks of ORDER in his post and that was something I was unaware of. So organization of the current directory is necessary.

(12-07-2018 05:55 AM)cdmackay Wrote:  I'm new to the 50g, and its programming and customisation seem to be the most flexible areas, so I need to adjust my approach

This reminds me of post #10 by Tim Wessman on this thread. You should read what he says about the 48 series because it also applies to the 50 series and I believe his point of view is correct.

Thanks again to David for teaching me some more RPL!

[DavidM]

(12-07-2018 11:53 PM)cdmackay Wrote:  AXL is new to me; most of my limited 50g knowledge comes from studying the HLP49 help file, which uses AXL in a code snippet but doesn't detail it as a command. I should get more familiar with the AUR

thanks again, all who made suggestions. Clearly I have a lot to learn.

We all have much to learn! I think of AXL simply as a toggler between arrays and lists. Whichever of the two you give it, the object is converted to the other.

Now it's my turn to learn some things, and possibly help to streamline this process even further. Specifically, which stats app (form) are you loading to perform the hypothesis testing? I see that there are two tests labeled as "T-Test", and my ignorance of statistics means that I'm not entirely sure of the appropriate means to experiment with this.

The reason I ask is this: it's possible to create a program which would populate multiple fields on the form with only one invocation, but to try this out I would need to know what values to use. If you wouldn't mind sharing a small example of your data and which form and values to select, I believe I could show you what I'm referring to. If this is something that you'd want to do fairly often, it might save you a lot of time (and keystrokes).

[cdmackay]

thanks very much, Carsen,

(12-08-2018 02:43 AM)Carsen Wrote:  Well, it all depends on how much you plan to use the T-Stat form. If I had to use it frequently, I would create the program and keep it stored in my STATISTICS directory. On the other hand, if I didn't plan to use it frequently, then I would not use the program and stick to the OBJ-> and HIST method.

That makes good sense.

Quote:ORDER is used so that I can simply press VAR F1 ENTER VAR F2 ENTER VAR F3 ENTER VAR F4 ENTER (i.e. I don't have to hesitate and search for the variables in the VAR menu). However, David taught me the risks of ORDER in his post and that was something I was unaware of. So organization of the current directory is necessary.

Right. I read (in the HLP49 help file) a warning that items (in the current dir) not specified in the list are deleted by ORDER. But that contradicts the AUR, which says that they will placed after the listed vars. I'll test this later, but presumably the HLP49 doc is in error.

Quote:This reminds me of post #10 by Tim Wessman on this thread. You should read what he says about the 48 series because it also applies to the 50 series and I believe his point of view is correct.

I'd read that thread before, but it's good to be reminded; yes, sounds right.


thanks again

[cdmackay]

thanks very much indeed, David,

(12-08-2018 04:55 PM)DavidM Wrote:  Now it's my turn to learn some things, and possibly help to streamline this process even further. Specifically, which stats app (form) are you loading to perform the hypothesis testing? I see that there are two tests labeled as "T-Test", and my ignorance of statistics means that I'm not entirely sure of the appropriate means to experiment with this.

In this case, I'm using the two-sample T test; that would be RS-5 STAT menu, 5 "Hypoth. tests", test 6 "μ1-μ2". Then filling in the form values: x1, s1, n1 and x2, s2, n2, from arrays on the stack: [x1 x2], [s1 s2], [n1 n2]. The α and pooled values I enter manually (or leave alone). [the stack arrays are produced by the 96 MENU stats softkeys]

Quote:The reason I ask is this: it's possible to create a program which would populate multiple fields on the form with only one invocation, but to try this out I would need to know what values to use. If you wouldn't mind sharing a small example of your data and which form and values to select, I believe I could show you what I'm referring to. If this is something that you'd want to do fairly often, it might save you a lot of time (and keystrokes).

thank you!

[cdmackay]

forgot to add my data, but it's trivial, you could use these stack arrays to test:

x1 x2: [3. 4.]

s1 s2: [1.5 1.6]

n1 n2: [5. 6.]

thanks.

[John Keith]

(12-08-2018 07:28 PM)cdmackay Wrote:  Right. I read (in the HLP49 help file) a warning that items (in the current dir) not specified in the list are deleted by ORDER. But that contradicts the AUR, which says that they will placed after the listed vars. I'll test this later, but presumably the HLP49 doc is in error.

No, ORDER certainly does not delete any objects. It places them after the newly ordered objects, in their original order.

[cdmackay]

(12-08-2018 09:11 PM)John Keith Wrote:  No, ORDER certainly does not delete any objects. It places them after the newly ordered objects, in their original order.

thanks John, yes, I assumed so.

The HLP49 (v6.0) text has:

Quote:Reorders vars in a directory.
{edited list from VARS cmd} →
You can process the list with various commands, such as SORT for alphabetical order. Use with
caution, since ORDER will delete vars with missing names.

perhaps there's some other meaning?

[DavidM]

(12-08-2018 07:42 PM)cdmackay Wrote:  ...you could use these stack arrays to test:
x1 x2: [3. 4.]
s1 s2: [1.5 1.6]
n1 n2: [5. 6.]

I was actually more hoping for an example of the ΣDAT array, as the method I'm suggesting takes care of computing the mean/sdev/count automatically. I have no idea if my data here is sensible, but here's an example of what I'm talking about:

Use whatever means you're comfortable with for creating a ΣDAT array with the following contents:

Code:

[
   [ 1 1.1 ]
   [ 2 2.2 ]
   [ 3 3.3 ]
   [ 4 4.4 ]
   [ 5 5.5 ]
]

Store the following program in the same directory as the above array. I've named mine ST2 for "Student's T-Test 2-variable":

Code:

ST2
\<<
   MEAN AXL EVAL
   SDEV AXL EVAL
   \GSDAT SIZE EVAL NDUPN DROP
\>>

Activate the appropriate form with:
right-shift 5
5 ENTER
6 ENTER

You'll then be shown the input form. With the value for x1 currently highlighted, press alpha, then ST2, then ENTER.

That's where the magic happens. The ST2 program is run, which outputs (in order) x1, x2, s1, s2, n1, n2. These values are then automatically inserted into their corresponding fields in the form. You are then free to enter whatever you like for α and "pooled?" to continue.

For reference, the above data creates the following values when run on my 50g:
x1: 3
x2: 3.3
s1: 1.58113883008
s2: 1.73925271309
n1: 5
n2: 5

Hopefully my intent is clear enough, even if my sample data is totally meaningless!

Does this make sense?

Notes:
- I have no idea if the dimensions of this sample ΣDAT are correct for this type of application
- This method of "auto-populating" fields in a form doesn't work universally. Many forms have special restrictions and utility routines which keep this type of mechanism from working as it does here.