The problem first, then the route and why I did this.
I did a 2-way frequency table of counts (not html). This was of project by Country (for 5 countries). Quite interesting.
Then I ran it again and opted to Store Results. It only half-worked in that the results seemed to be only for the first factor - project. I expected them to be for both factors. I then realised that I did have all the tables - 4 of them - which is more than I needed. And the visible one is a margin and not the 2-way table.
I suggest usually it is nice to see the margins in the output, but not necessarily to then store them all.
So 2 changes are suggested:
a) When margins are stored (i.e. 4 data frames are produced for a 2-way table), then could we have the tables in the opposite order, so the current one is then the 2-way table.
b) When you opt to Store Results, if margins are not ticked all is sweetness and light. If margins are ticked then a second checkbox is enabled that says Store Margins. By default it is un-ticked.
The problem first, then the route and why I did this. I did a 2-way frequency table of counts (not html). This was of project by Country (for 5 countries). Quite interesting. Then I ran it again and opted to Store Results. It only half-worked in that the results seemed to be only for the first factor - project. I expected them to be for both factors. I then realised that I did have all the tables - 4 of them - which is more than I needed. And the visible one is a margin and not the 2-way table.
I suggest usually it is nice to see the margins in the output, but not necessarily to then store them all.
So 2 changes are suggested: a) When margins are stored (i.e. 4 data frames are produced for a 2-way table), then could we have the tables in the opposite order, so the current one is then the 2-way table. b) When you opt to Store Results, if margins are not ticked all is sweetness and light. If margins are ticked then a second checkbox is enabled that says Store Margins. By default it is un-ticked.