TODO

   1 Time-stamp: <2006-04-15 18:11:46 blp>
   2
   3 Get rid of need for GNU diff in `make check'.
   4
   5 Get rid of need for file name canonicalization.
   6
   7 Format specifier code needs to be rewritten for lowered crappiness.
   8
   9 CROSSTABS needs to be re-examined.
  10
  11 RANK, which is needed for the Wilcoxon signed-rank statistic, Mann-Whitney U,
  12 Kruskal-Wallis on NPAR TESTS and for Spearman and the Johnkheere trend test (in
  13 other procedures).
  14
  15 lex_token_representation() should take a buffer to fill.
  16
  17 Make valgrind --leak-check=yes --show-reachable=yes work.
  18
  19 Add NOT_REACHED() macro.
  20
  21 Add compression to casefiles.
  22
  23 Scratch variables should not be available for use following TEMPORARY.
  24
  25 Check our results against the NIST StRD benchmark results at
  26 strd.itl.nist.gov/div898/strd
  27
  28 In debug mode hash table code should verify that collisions are reasonably low.
  29
  30 Storage of value labels on disk is inefficient.  Invent new data structure.
  31
  32 Add an output flag which would cause a page break if a table segment could fit
  33 vertically on a page but it just happens to be positioned such that it won't.
  34
  35 Fix spanned joint cells, i.e., EDLEVEL on crosstabs.stat.
  36
  37 Cell footnotes.
  38
  39 Should be able to bottom-justify cells.  It'll be expensive, though, by
  40 requiring an extra metrics call.
  41
  42 SELECT IF should be moved before other transformations whenever possible.  It
  43 should only be impossible when one of the variables referred to in SELECT IF is
  44 created or modified by a previous transformation.
  45
  46 The manual: add text, add index entries, add examples.
  47
  48 Figure out a stylesheet for messages displayed by PSPP: i.e., what quotation
  49 marks around filenames, etc.
  50
  51 From Zvi Grauer <z.grauer@csuohio.edu> and <zvi@mail.ohio.net>:
  52
  53    1. design of experiments software, specifically Factorial, response surface
  54    methodology and mixrture design.
  55
  56    These would be EXTREMELY USEFUL for chemists, engineeris, and anyone
  57    involved in the production of chemicals or formulations.
  58
  59    2. Multidimensional Scaling analysis (for market analysis) -
  60
  61    3. Preference mapping software for market analysis
  62
  63    4. Hierarchical clustering (as well as partition clustering)
  64
  65    5. Conjoint analysis
  66
  67    6. Categorical data analsys ?
  68
  69 MORE NOTES/IDEAS/BUGS
  70 ---------------------
  71
  72 Sometimes very wide (or very tall) columns can occur in tables.  What is a good
  73 way to truncate them?  It doesn't seem to cause problems for the ascii or
  74 postscript drivers, but it's not good in the general case.  Should they be
  75 split somehow?  (One way that wide columns can occur is through user request,
  76 for instance through a wide PRINT request--try time-date.stat with a narrow
  77 ascii page or with the postscript driver on letter size paper.)
  78
  79 From Moshe Braner <mbraner@nessie.vdh.state.vt.us>: An idea regarding MATCH
  80 FILES, again getting BEYOND the state of SPSS: it always bothered me that if I
  81 have a large data file and I want to match it to a small lookup table, via
  82 MATCH FILES FILE= /TABLE= /BY key, I need to SORT the large file on key, do the
  83 match, then (usually) re-sort back into the order I really want it.  There is
  84 no reason to do this, when the lookup table is small.  Even a dumb sequential
  85 search through the table, for every case in the big file, is better, in some
  86 cases, than the sort.  So here's my idea: first look at the /TABLE file, if it
  87 is "small enough", read it into memory, and create an index (or hash table,
  88 whatever) for it.  Then read the /FILE and use the index to match to each case.
  89 OTOH, if the /TABLE is too large, then do it the old way, complaining if either
  90 file is not sorted on key.
  91
  92 ----------------------------------------------------------------------
  93 Statistical procedures:
  94
  95 For each case we read from the input program:
  96
  97 1. Execute permanent transformations.  If these drop the case, stop.
  98 2. N OF CASES.  If we have already written N cases, stop.
  99 3. Write case to replacement active file.
 100 4. Execute temporary transformations.  If these drop the case, stop.
 101 5. Post-TEMPORARY N OF CASES.  If we have already analyzed N cases, stop.
 102 6. FILTER, PROCESS IF.  If these drop the case, stop.
 103 7. Pass case to procedure.
 104
 105 Ugly cases:
 106
 107 LAG records cases in step 3.
 108
 109 AGGREGATE: When output goes to an external file, this is just an ordinary
 110 procedure.  When output goes to the active file, step 3 should be skipped,
 111 because AGGREGATE creates its own case sink and writes to it in step 7.  Also,
 112 TEMPORARY has no effect and we just cancel it.  Regardless of direction of
 113 output, we should not implement AGGREGATE through a transformation because that
 114 will fail to honor FILTER, PROCESS IF, N OF CASES.
 115
 116 ADD FILES: Essentially an input program.  It silently cancels unclosed LOOPs
 117 and DO IFs.  If the active file is used for input, then runs EXECUTE (if there
 118 are any transformations) and then steals vfm_source and encapsulates it.  If
 119 the active file is not used for input, then it cancels all the transformations
 120 and deletes the original active file.
 121
 122 CASESTOVARS: ???
 123
 124 FLIP:
 125
 126 MATCH FILES: Similar to AGGREGATE.  This is a procedure.  When the active file
 127 is used for input, it reads the active file; otherwise, it just cancels all the
 128 transformations and deletes the original active file.  Step 3 should be
 129 skipped, because MATCH FILES creates its own case sink and writes to it in step
 130 7.  TEMPORARY is not allowed.
 131
 132 MODIFY VARS:
 133
 134 REPEATING DATA:
 135
 136 SORT CASES:
 137
 138 UPDATE: same as ADD FILES.
 139
 140 VARSTOCASES: ???
 141 ----------------------------------------------------------------------
 142 N OF CASES
 143
 144   * Before TEMPORARY, limits number of cases sent to the sink.
 145
 146   * After TEMPORARY, limits number of cases sent to the procedure.
 147
 148   * Without TEMPORARY, those are the same cases, so it limits both.
 149
 150 SAMPLE
 151
 152   * Sample is just a transformation.  It has no special properties.
 153
 154 FILTER
 155
 156   * Always selects cases sent to the procedure.
 157
 158   * No effect on cases sent to sink.
 159
 160   * Before TEMPORARY, selection is permanent.  After TEMPORARY,
 161     selection stops after a procedure.
 162
 163 PROCESS IF
 164
 165   * Always selects cases sent to the procedure.
 166
 167   * No effect on cases sent to sink.
 168
 169   * Always stops after a procedure.
 170
 171 SPLIT FILE
 172
 173   * Ignored by AGGREGATE.  Used when procedures write matrices.
 174
 175   * Always applies to the procedure.
 176
 177   * Before TEMPORARY, splitting is permanent.  After TEMPORARY,
 178     splitting stops after a procedure.
 179
 180 TEMPORARY
 181
 182   * TEMPORARY has no effect on AGGREGATE when output goes to the active file.
 183
 184   * SORT CASES, ADD FILES, RENAME VARIABLES, CASESTOVARS, VARSTOCASES,
 185     COMPUTE with a lag function cannot be used after TEMPORARY.
 186
 187   * Cannot be used in DO IF...END IF or LOOP...END LOOP.
 188
 189   * FLIP ignores TEMPORARY.  All transformations become permanent.
 190
 191   * MATCH FILES and UPDATE cannot be used after TEMPORARY if active
 192     file is an input source.
 193
 194   * RENAME VARIABLES is invalid after TEMPORARY.
 195
 196   * WEIGHT, SPLIT FILE, N OF CASES, FILTER, PROCESS IF apply only to
 197     the next procedure when used after TEMPORARY.
 198
 199 WEIGHT
 200
 201   * Always applies to the procedure.
 202
 203   * Before TEMPORARY, weighting is permanent.  After TEMPORARY,
 204     weighting stops after a procedure.
 205
 206
 207 -------------------------------------------------------------------------------
 208 Local Variables:
 209 mode: text
 210 fill-column: 79
 211 End: