TODO

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