TODO

   1 Time-stamp: <2003-12-27 12:03:42 blp>
   2
   3 TODO
   4 ----
   5
   6 Probably should get rid of approx.h.  The user really needs to be responsible
   7 for his own precision.
   8
   9 Use AFM files instead of Groff font files, and include AFMs for our default
  10 fonts with the distribution.
  11
  12 The way that data-in.c and data-out.c deal with strings is wrong.  Instead of
  13 the way it's done now, we should make it dynamically allocate a buffer and
  14 return a pointer to it.  This is a much safer interface.
  15
  16 Add libplot output driver.  Suggested by Robert S. Maier
  17 <rsm@math.arizona.edu>: "it produces output in idraw-editable PS format, PCL5
  18 format, xfig-editable format, Illustrator format,..., and can draw vector
  19 graphics on X11 displays also".
  20
  21 Storage of value labels on disk is inefficient.  Invent new data structure.
  22
  23 Add an output flag which would cause a page break if a table segment could fit
  24 vertically on a page but it just happens to be positioned such that it won't.
  25
  26 Fix spanned joint cells, i.e., EDLEVEL on crosstabs.stat.
  27
  28 Cell footnotes.
  29
  30 PostScript driver should emit thin lines, then thick lines, to optimize time
  31 and space.
  32
  33 New functions?  var_name_or_label(), tab_value_or_label()
  34
  35 Should be able to bottom-justify cells.  It'll be expensive, though, by
  36 requiring an extra metrics call.
  37
  38 Perhaps instead of the current lines we should define the following line types:
  39 null, thin, thick, double.  It might look pretty classy.
  40
  41 Perhaps thick table borders that are cut off by a page break should decay to
  42 thin borders.  (i.e., on a thick bordered table that's longer than one page,
  43 but narrow, the bottom border would be thin on the first page, and the top and
  44 bottom borders on middle pages.)
  45
  46 Support multi-line titles on tables. (For the first page only, presumably.)
  47
  48 Rewrite the convert_F() function in data-out.c to be nicer code.
  49
  50 In addition to searching the source directory, we should search the current
  51 directory (for data files).  (Yuck!)
  52
  53 Fix line-too-long problems in PostScript code, instead of covering them up.
  54 setlinecap is *not* a proper solution.
  55
  56 Need a better way than MAX_WORKSPACE to detect low-memory conditions.
  57
  58 When malloc() returns 0, page to disk and free() unnecessary data.
  59
  60 Remove ccase * argument from procfunc argument to procedure().
  61
  62 See if process_active_file() has wider applicability.
  63
  64 Eliminate private data in struct variable through use of pointers.
  65
  66 Fix som_columns().
  67
  68 There needs to be another layer onto the lexer, which should probably be
  69 entirely rewritten anyway.  The lexer needs to read entire *commands* at a
  70 time, not just a *line* at a time.  This would vastly simplify the
  71 (yet-to-be-implemented) logging mechanism and other stuff as well.
  72
  73 Has glob.c been pared down enough?
  74
  75 Improve interactivity of output by allowing a `commit' function for a page.
  76 This will also allow for infinite-length pages.
  77
  78 All the tests need to be looked over.  Some of the SET calls don't make sense
  79 any more.
  80
  81 Implement thin single lines, should be pretty easy now.
  82
  83 SELECT IF should be moved before other transformations whenever possible.  It
  84 should only be impossible when one of the variables referred to in SELECT IF is
  85 created or modified by a previous transformation.
  86
  87 The manual: add text, add index entries, add examples.
  88
  89 The inline file should be improved: There should be *real* detection of whether
  90 it is used (in dfm.c:cmd_begin_data), not after-the-fact detection.
  91
  92 Figure out a stylesheet for messages displayed by PSPP: i.e., what quotation
  93 marks around filenames, etc.
  94
  95 Data input and data output are currently arranged in reciprocal pairs: input is
  96 done directly, with write_record() or whatever; output is done on a callback
  97 event-driven basis.  It would definitely be easier if both could be done on a
  98 direct basis, with read_record() and write_record() routines, with a coroutine
  99 implementation (see Knuth).  But I'm not sure that coroutines can be
 100 implemented in ANSI C.  This will require some thought.  Perhaps 0.4.0 can do
 101 this.
 102
 103 New SET subcommand: OUTPUT.  i.e., SET OUTPUT="filename" to send output to that
 104 file; SET OUTPUT="filename"(APPEND) to append to that file; SET OUTPUT=DEFAULT
 105 to reset everything.  There might be a better approach, though--think about it.
 106
 107 HDF export capabilities (http://hdf.ncsa.uiuc.edu).  Suggested by Marcus
 108 G. Daniels <mgd@santafe.edu>.
 109
 110 From Zvi Grauer <z.grauer@csuohio.edu> and <zvi@mail.ohio.net>:
 111
 112    1. design of experiments software, specifically Factorial, response surface
 113    methodology and mixrture design.
 114
 115    These would be EXTREMELY USEFUL for chemists, engineeris, and anyone
 116    involved in the production of chemicals or formulations.
 117
 118    2. Multidimensional Scaling analysis (for market analysis) -
 119
 120    3. Preference mapping software for market analysis
 121
 122    4. Hierarchical clustering (as well as partition clustering)
 123
 124    5. Conjoint analysis
 125
 126    6. Categorical data analsys ?
 127
 128 IDEAS
 129 -----
 130
 131 In addition to an "infinite journal", we should keep a number of
 132 individual-session journals, pspp.jnl-1 through pspp.jnl-X, renaming and
 133 deleting as needed.  All of the journals should have date/time comments.
 134
 135 Qualifiers for variables giving type--categorical, ordinal, ...
 136
 137 Analysis Wizard
 138
 139 Consider consequences of xmalloc(), fail(), hcf() in interactive
 140 use:
 141 a. Can we safely just use setjmp()/longjmp()?
 142 b. Will that leak memory?
 143 i. I don't think so: all procedure-created memory is either
 144 garbage-collected or globally-accessible.
 145 ii. But you never know... esp. w/o Checker.
 146 c. Is this too early to worry? too late?
 147
 148 Need to implement a shared buffer for funny functions that require relatively
 149 large permanent transient buffers (1024 bytes or so), that is, buffers that are
 150 permanent in the sense that they probably shouldn't be deallocated but are only
 151 used from time to time, buffers that can't be allocated on the stack because
 152 they are of variable and unpredictable but usually relatively small (usually
 153 line buffers).  There are too many of these lurking around; can save a sizeable
 154 amount of space at very little overhead and with very little effort by merging
 155 them.
 156
 157 Clever multiplatform GUI idea (due partly to John Williams): write a GUI in
 158 Java where each statistical procedure dialog box could be downloaded from the
 159 server independently.  The statistical procedures would run on (the/a) server
 160 and results would be reported through HTML tables viewed with the user's choice
 161 of web browsers.  Help could be implemented through the browser as well.
 162
 163 Design a plotting API, with scatterplots, line plots, pie charts, barcharts,
 164 Pareto plots, etc., as subclasses of the plot superclass.
 165
 166 HOWTOs
 167 ------
 168
 169 1. How to add an operator for use in PSPP expressions:
 170
 171 a. Add the operator to the enumerated type at the top of expr.h.  If the
 172 operator has arguments (i.e., it's not a terminal) then add it *before*
 173 OP_TERMINAL; otherwise, add it *after* OP_TERMINAL.  All these begin with OP_.
 174
 175 b. If the operator's a terminal then you'll want to design a structure to hold
 176 its content.  Add the structure to the union any_node.  (You can also reuse one
 177 of the prefab structures, of course.)
 178
 179 c. Now switch to expr-prs.c--the module for expression parsing.  Insert the
 180 operator somewhere in the precedence hierarchy.
 181
 182 (1) If you're adding a operator that is a function (like ACOS, ABS, etc.) then
 183 add the function to functab in `void init_functab(void)'.  Order is not
 184 important here.  The first element is the function name, like "ACOS".  The
 185 second is the operator enumerator you added in expr.h, like OP_ARCOS.  The
 186 third element is the C function to parse the PSPP function.  The predefined
 187 functions will probably suit your needs, but if not, you can write your own.
 188 The fourth element is an argument to the parsing function; it's only used
 189 currently by generic_str_func(), which handles a rather general syntax for
 190 functions that return strings; see the comment at the beginning of its code for
 191 details.
 192
 193 (2) If you're adding an actual operator you'll have to put a function in
 194 between two of the operators there already in functions `exprtype
 195 parse_*(any_node **n)'.  Each of these stores the tree for its result into *n,
 196 and returns the result type, or EX_ERROR on error.  Be sure to delete all the
 197 allocated memory on error before returning.
 198
 199 d. Add the operator to the table `op_desc ops[OP_SENTINEL+1]' in expr-prs.c,
 200 which has an entry for every operator.  These entries *must* be in the same
 201 order as they are in expr.h.  The entries have the form `op(A,B,C,D)'.  A is
 202 the name of the operator as it should be printed in a postfix output format.
 203 For example, the addition operator is printed as `plus'.  B is a bitmapped set
 204 of flags:
 205
 206 * Set the 001 bit (OP_VAR_ARGS) if the operator takes a variable number of
 207 arguments.  If a function can take, say, two args or three args, but no other
 208 numbers of args, this is a poor way to do it--instead implement the operator as
 209 two separate operators, one with two args, the other with three.  (The main
 210 effect of this bit is to cause the number of arguments to be output to the
 211 postfix form so that the expression evaluator can know how many args the
 212 operator takes.  It also causes the expression optimizer to calculate the
 213 needed stack height differently, without referencing C.)
 214
 215 * Set the 002 bit (OP_MIN_ARGS) if the operator can take an optional `dotted
 216 argument' that specified the minimum number of non-SYSMIS arguments in order to
 217 have a non-SYSMIS result.  For instance, MIN.3(e1,e2,e3,e4,e5) returns a
 218 non-SYSMIS result only if at least 3 out of 5 of the expressions e1 to e5 are
 219 not missing.
 220
 221 Minargs are passed in the nonterm_node structure in `arg[]''s elements past
 222 `n'--search expr-prs.c for the words `terrible crock' for an example of this.
 223
 224 Minargs are output to the postfix form.  A default value is output if none was
 225 specified by the user.
 226
 227 You can use minargs for anything you want--they're not limited to actually
 228 describing a minimum number of valid arguments; that's just what they're most
 229 *commonly* used for.
 230
 231 * Set the 004 bit (OP_FMT_SPEC) if the operator has an argument that is a
 232 format specifier.  (This causes the format specifier to be output to the
 233 postfix representation.)
 234
 235 Format specs are passed in the nonterm_node structure in the same way as
 236 minargs, except that there are three args, in this order: type, width, # of
 237 decimals--search expr-prs.c for the words `is a crock' for an example of this.
 238
 239 * Set the 010 bit (OP_ABSORB_MISS) if the operator can *ever* have a result of
 240 other than SYSMIS when given one or more arguments of SYSMIS.  Operators
 241 lacking this bit and known to have a SYSMIS argument are short-circuited to
 242 SYSMIS by the expression optimizer.
 243
 244 * If your operator doesn't fit easily into the existing categories,
 245 congratulations, you get to write lots of code to adjust everything to cope
 246 with this new operator.  Are you really sure you want to do that?
 247
 248 C is the effect the operator has on stack height.  Set this to `varies' if the
 249 operator has a variable number of arguments.  Otherwise this 1, minus the
 250 number of arguments the operator has.  (Since terminals have no arguments, they
 251 have a value of +1 for this; other operators have a value of 0 or less.)
 252
 253 D is the number of items output to the postfix form after the operator proper.
 254 This is 0, plus 1 if the operator has varargs, plus 1 if the operator has
 255 minargs, plus 3 if the operator has a format spec.  Note that minargs/varargs
 256 can't coexist with a format spec on the same operator as currently coded.  Some
 257 terminals also have a nonzero value for this but don't fit into the above
 258 categories.
 259
 260 e. Switch to expr-opt.c.  Add code to evaluate_tree() to evaluate the
 261 expression when all arguments are known to be constants.  Pseudo-random
 262 functions can't be evaluated even if their arguments are constants.  If the
 263 function can be optimized even if its arguments aren't all known constants, add
 264 code to optimize_tree() to do it.
 265
 266 f. Switch to expr-evl.c.  Add code to evaluate_expression() to evaluate the
 267 expression.  You must be absolutely certain that the code in evaluate_tree(),
 268 optimize_tree(), and evaluate_expression() will always return the same results,
 269 otherwise users will get inconsistent results, a Bad Thing.  You must be
 270 certain that even on boundary conditions users will get identical results, for
 271 instance for the values 0, 1, -1, SYSMIS, or, for string functions, the null
 272 string, 1-char strings, and 255-char strings.
 273
 274 g. Test the code.  Write some test syntax files.  Examine the output carefully.
 275
 276 NOTES ON SEARCH ALGORITHMS
 277 --------------------------
 278
 279 1. Trees are nicer when you want a sorted table.  However, you can always
 280 sort a hash table after you're done adding values.
 281
 282 2. Brent's variation of Algorithm D is best when the table is fixed: it's
 283 memory-efficient, having small, fixed overhead.  It's easier to use
 284 when you know in advance how many entries the table will contain.
 285
 286 3. Algorithm L is rather slow for a hash algorithm, however it's easy.
 287
 288 4. Chaining is best in terms of speed; ordered/self-ordering is even
 289 better.
 290
 291 5. Rehashing is slow.
 292
 293 6. Might want to decide on an algorithm empirically since there are no
 294 clear mathematical winners in some cases.
 295
 296 7. gprof?  Hey, it works!
 297
 298 MORE NOTES/IDEAS/BUGS
 299 ---------------------
 300
 301 The behavior of converting a floating point to an integer when the value of the
 302 float is out of range of the integer type is UNDEFINED!  See ANSI 6.2.1.3.
 303
 304 What should we do for *negative* times in expressions?
 305
 306 Sometimes very wide (or very tall) columns can occur in tables.  What is a good
 307 way to truncate them?  It doesn't seem to cause problems for the ascii or
 308 postscript drivers, but it's not good in the general case.  Should they be
 309 split somehow?  (One way that wide columns can occur is through user request,
 310 for instance through a wide PRINT request--try time-date.stat with a narrow
 311 ascii page or with the postscript driver on letter size paper.)
 312
 313 NULs in input files break the products we're replacing: although it will input
 314 them properly and display them properly as AHEX format, it truncates them in A
 315 format.  Also, string-manipulation functions such as CONCAT truncate their
 316 results after the first NUL.  This should simplify the result of PSPP design.
 317 Perhaps those ugly a_string, b_string, ..., can all be eliminated.
 318
 319 From Moshe Braner <mbraner@nessie.vdh.state.vt.us>: An idea regarding MATCH
 320 FILES, again getting BEYOND the state of SPSS: it always bothered me that if I
 321 have a large data file and I want to match it to a small lookup table, via
 322 MATCH FILES FILE= /TABLE= /BY key, I need to SORT the large file on key, do the
 323 match, then (usually) re-sort back into the order I really want it.  There is
 324 no reason to do this, when the lookup table is small.  Even a dumb sequential
 325 search through the table, for every case in the big file, is better, in some
 326 cases, than the sort.  So here's my idea: first look at the /TABLE file, if it
 327 is "small enough", read it into memory, and create an index (or hash table,
 328 whatever) for it.  Then read the /FILE and use the index to match to each case.
 329 OTOH, if the /TABLE is too large, then do it the old way, complaining if either
 330 file is not sorted on key.
 331
 332 -------------------------------------------------------------------------------
 333 Local Variables:
 334 mode: text
 335 fill-column: 79
 336 End: