TODO

   1 Time-stamp: <2005-03-02 16:08:59 blp>
   2
   3 What Ben's working on now.
   4 --------------------------
   5
   6 Workspace exhaustion heuristics.
   7
   8 Update q2c input format description.
   9
  10 Rewrite output subsystem, break into multiple processes.
  11
  12 CROSSTABS needs to be re-examined.
  13
  14 RANK, which is needed for the Wilcoxon signed-rank statistic, Mann-Whitney U,
  15 Kruskal-Wallis on NPAR TESTS and for Spearman and the Johnkheere trend test (in
  16 other procedures).
  17
  18 TODO
  19 ----
  20
  21 Make valgrind --leak-check=yes --show-reachable=yes work.
  22
  23 Add NOT_REACHED() macro.
  24
  25 Add compression to casefiles.
  26
  27 There needs to be another layer onto the lexer, which should probably be
  28 entirely rewritten anyway.  The lexer needs to read entire *commands* at a
  29 time, not just a *line* at a time.  It also needs to support arbitrary putback,
  30 probably by just backing up the "current position" in the command buffer.
  31
  32 Scratch variables should not be available for use following TEMPORARY.
  33
  34 Details of N OF CASES, SAMPLE, FILTER, PROCESS IF, TEMPORARY, etc., need to be
  35 checked against the documentation.  See notes on these at end of file for a
  36 start.
  37
  38 Check our results against the NIST StRD benchmark results at
  39 strd.itl.nist.gov/div898/strd
  40
  41 In debug mode hash table code should verify that collisions are reasonably low.
  42
  43 Use AFM files instead of Groff font files, and include AFMs for our default
  44 fonts with the distribution.
  45
  46 Storage of value labels on disk is inefficient.  Invent new data structure.
  47
  48 Add an output flag which would cause a page break if a table segment could fit
  49 vertically on a page but it just happens to be positioned such that it won't.
  50
  51 Fix spanned joint cells, i.e., EDLEVEL on crosstabs.stat.
  52
  53 Cell footnotes.
  54
  55 PostScript driver should emit thin lines, then thick lines, to optimize time
  56 and space.
  57
  58 New functions?  var_name_or_label(), tab_value_or_label()
  59
  60 Should be able to bottom-justify cells.  It'll be expensive, though, by
  61 requiring an extra metrics call.
  62
  63 Perhaps instead of the current lines we should define the following line types:
  64 null, thin, thick, double.  It might look pretty classy.
  65
  66 Perhaps thick table borders that are cut off by a page break should decay to
  67 thin borders.  (i.e., on a thick bordered table that's longer than one page,
  68 but narrow, the bottom border would be thin on the first page, and the top and
  69 bottom borders on middle pages.)
  70
  71 Support multi-line titles on tables. (For the first page only, presumably.)
  72
  73 Rewrite the convert_F() function in data-out.c to be nicer code.
  74
  75 In addition to searching the source directory, we should search the current
  76 directory (for data files).  (Yuck!)
  77
  78 Fix line-too-long problems in PostScript code, instead of covering them up.
  79 setlinecap is *not* a proper solution.
  80
  81 Fix som_columns().
  82
  83 Has glob.c been pared down enough?
  84
  85 Improve interactivity of output by allowing a `commit' function for a page.
  86 This will also allow for infinite-length pages.
  87
  88 Implement thin single lines, should be pretty easy now.
  89
  90 SELECT IF should be moved before other transformations whenever possible.  It
  91 should only be impossible when one of the variables referred to in SELECT IF is
  92 created or modified by a previous transformation.
  93
  94 The manual: add text, add index entries, add examples.
  95
  96 The inline file should be improved: There should be *real* detection of whether
  97 it is used (in dfm.c:cmd_begin_data), not after-the-fact detection.
  98
  99 Figure out a stylesheet for messages displayed by PSPP: i.e., what quotation
 100 marks around filenames, etc.
 101
 102 New SET subcommand: OUTPUT.  i.e., SET OUTPUT="filename" to send output to that
 103 file; SET OUTPUT="filename"(APPEND) to append to that file; SET OUTPUT=DEFAULT
 104 to reset everything.  There might be a better approach, though--think about it.
 105
 106 From Zvi Grauer <z.grauer@csuohio.edu> and <zvi@mail.ohio.net>:
 107
 108    1. design of experiments software, specifically Factorial, response surface
 109    methodology and mixrture design.
 110
 111    These would be EXTREMELY USEFUL for chemists, engineeris, and anyone
 112    involved in the production of chemicals or formulations.
 113
 114    2. Multidimensional Scaling analysis (for market analysis) -
 115
 116    3. Preference mapping software for market analysis
 117
 118    4. Hierarchical clustering (as well as partition clustering)
 119
 120    5. Conjoint analysis
 121
 122    6. Categorical data analsys ?
 123
 124 IDEAS
 125 -----
 126
 127 In addition to an "infinite journal", we should keep a number of
 128 individual-session journals, pspp.jnl-1 through pspp.jnl-X, renaming and
 129 deleting as needed.  All of the journals should have date/time comments.
 130
 131 Qualifiers for variables giving type--categorical, ordinal, ...
 132
 133 Analysis Wizard
 134
 135 Consider consequences of xmalloc(), fail(), hcf() in interactive
 136 use:
 137 a. Can we safely just use setjmp()/longjmp()?
 138 b. Will that leak memory?
 139 i. I don't think so: all procedure-created memory is either
 140 garbage-collected or globally-accessible.
 141 ii. But you never know... esp. w/o Checker.
 142 c. Is this too early to worry? too late?
 143
 144 Need to implement a shared buffer for funny functions that require relatively
 145 large permanent transient buffers (1024 bytes or so), that is, buffers that are
 146 permanent in the sense that they probably shouldn't be deallocated but are only
 147 used from time to time, buffers that can't be allocated on the stack because
 148 they are of variable and unpredictable but usually relatively small (usually
 149 line buffers).  There are too many of these lurking around; can save a sizeable
 150 amount of space at very little overhead and with very little effort by merging
 151 them.
 152
 153 Clever multiplatform GUI idea (due partly to John Williams): write a GUI in
 154 Java where each statistical procedure dialog box could be downloaded from the
 155 server independently.  The statistical procedures would run on (the/a) server
 156 and results would be reported through HTML tables viewed with the user's choice
 157 of web browsers.  Help could be implemented through the browser as well.
 158
 159 HOWTOs
 160 ------
 161
 162 MORE NOTES/IDEAS/BUGS
 163 ---------------------
 164
 165 Sometimes very wide (or very tall) columns can occur in tables.  What is a good
 166 way to truncate them?  It doesn't seem to cause problems for the ascii or
 167 postscript drivers, but it's not good in the general case.  Should they be
 168 split somehow?  (One way that wide columns can occur is through user request,
 169 for instance through a wide PRINT request--try time-date.stat with a narrow
 170 ascii page or with the postscript driver on letter size paper.)
 171
 172 NULs in input files break the products we're replacing: although it will input
 173 them properly and display them properly as AHEX format, it truncates them in A
 174 format.  Also, string-manipulation functions such as CONCAT truncate their
 175 results after the first NUL.  This should simplify the result of PSPP design.
 176 Perhaps those ugly a_string, b_string, ..., can all be eliminated.
 177
 178 From Moshe Braner <mbraner@nessie.vdh.state.vt.us>: An idea regarding MATCH
 179 FILES, again getting BEYOND the state of SPSS: it always bothered me that if I
 180 have a large data file and I want to match it to a small lookup table, via
 181 MATCH FILES FILE= /TABLE= /BY key, I need to SORT the large file on key, do the
 182 match, then (usually) re-sort back into the order I really want it.  There is
 183 no reason to do this, when the lookup table is small.  Even a dumb sequential
 184 search through the table, for every case in the big file, is better, in some
 185 cases, than the sort.  So here's my idea: first look at the /TABLE file, if it
 186 is "small enough", read it into memory, and create an index (or hash table,
 187 whatever) for it.  Then read the /FILE and use the index to match to each case.
 188 OTOH, if the /TABLE is too large, then do it the old way, complaining if either
 189 file is not sorted on key.
 190
 191 ----------------------------------------------------------------------
 192 Statistical procedures:
 193
 194 For each case we read from the input program:
 195
 196 1. Execute permanent transformations.  If these drop the case, stop.
 197 2. N OF CASES.  If we have already written N cases, stop.
 198 3. Write case to replacement active file.
 199 4. Execute temporary transformations.  If these drop the case, stop.
 200 5. Post-TEMPORARY N OF CASES.  If we have already analyzed N cases, stop.
 201 6. FILTER, PROCESS IF.  If these drop the case, stop.
 202 7. Pass case to procedure.
 203
 204 Ugly cases:
 205
 206 LAG records cases in step 3.
 207
 208 AGGREGATE: When output goes to an external file, this is just an ordinary
 209 procedure.  When output goes to the active file, step 3 should be skipped,
 210 because AGGREGATE creates its own case sink and writes to it in step 7.  Also,
 211 TEMPORARY has no effect and we just cancel it.  Regardless of direction of
 212 output, we should not implement AGGREGATE through a transformation because that
 213 will fail to honor FILTER, PROCESS IF, N OF CASES.
 214
 215 ADD FILES: Essentially an input program.  It silently cancels unclosed LOOPs
 216 and DO IFs.  If the active file is used for input, then runs EXECUTE (if there
 217 are any transformations) and then steals vfm_source and encapsulates it.  If
 218 the active file is not used for input, then it cancels all the transformations
 219 and deletes the original active file.
 220
 221 CASESTOVARS: ???
 222
 223 FLIP:
 224
 225 MATCH FILES: Similar to AGGREGATE.  This is a procedure.  When the active file
 226 is used for input, it reads the active file; otherwise, it just cancels all the
 227 transformations and deletes the original active file.  Step 3 should be
 228 skipped, because MATCH FILES creates its own case sink and writes to it in step
 229 7.  TEMPORARY is not allowed.
 230
 231 MODIFY VARS:
 232
 233 REPEATING DATA:
 234
 235 SORT CASES:
 236
 237 UPDATE: same as ADD FILES.
 238
 239 VARSTOCASES: ???
 240 ----------------------------------------------------------------------
 241 N OF CASES
 242
 243   * Before TEMPORARY, limits number of cases sent to the sink.
 244
 245   * After TEMPORARY, limits number of cases sent to the procedure.
 246
 247   * Without TEMPORARY, those are the same cases, so it limits both.
 248
 249 SAMPLE
 250
 251   * Sample is just a transformation.  It has no special properties.
 252
 253 FILTER
 254
 255   * Always selects cases sent to the procedure.
 256
 257   * No effect on cases sent to sink.
 258
 259   * Before TEMPORARY, selection is permanent.  After TEMPORARY,
 260     selection stops after a procedure.
 261
 262 PROCESS IF
 263
 264   * Always selects cases sent to the procedure.
 265
 266   * No effect on cases sent to sink.
 267
 268   * Always stops after a procedure.
 269
 270 SPLIT FILE
 271
 272   * Ignored by AGGREGATE.  Used when procedures write matrices.
 273
 274   * Always applies to the procedure.
 275
 276   * Before TEMPORARY, splitting is permanent.  After TEMPORARY,
 277     splitting stops after a procedure.
 278
 279 TEMPORARY
 280
 281   * TEMPORARY has no effect on AGGREGATE when output goes to the active file.
 282
 283   * SORT CASES, ADD FILES, RENAME VARIABLES, CASESTOVARS, VARSTOCASES,
 284     COMPUTE with a lag function cannot be used after TEMPORARY.
 285
 286   * Cannot be used in DO IF...END IF or LOOP...END LOOP.
 287
 288   * FLIP ignores TEMPORARY.  All transformations become permanent.
 289
 290   * MATCH FILES and UPDATE cannot be used after TEMPORARY if active
 291     file is an input source.
 292
 293   * RENAME VARIABLES is invalid after TEMPORARY.
 294
 295   * WEIGHT, SPLIT FILE, N OF CASES, FILTER, PROCESS IF apply only to
 296     the next procedure when used after TEMPORARY.
 297
 298 WEIGHT
 299
 300   * Always applies to the procedure.
 301
 302   * Before TEMPORARY, weighting is permanent.  After TEMPORARY,
 303     weighting stops after a procedure.
 304
 305
 306 -------------------------------------------------------------------------------
 307 Local Variables:
 308 mode: text
 309 fill-column: 79
 310 End: