[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Function categories

From: John Darrington
Subject: Function categories
Date: Mon, 16 Apr 2007 15:27:19 +0800
User-agent: Mutt/1.5.9i

On Sun, Apr 15, 2007 at 11:42:11PM -0600, Ben Pfaff wrote:

     So I thought about categories a little, and it seems to me that
     we want something like this, which also indicates my proposed
     syntax for operation.def.  The first word after "category" is a
     name for identifiers (which will probably go into an enum), the
     quoted string is a name for the category, and the parenthesized
     list gives the functions in the category (and accepts wildcards):
     The only real difference is that we break down the statistical
     functions into subcategories, and do so along two axes: by the
     type of statistical function and by the distribution.  The list
     of categories could either be hierarchical with a colon in the
     category name indicating the hierarchy, or it could just be a
     flat list with any category name that contains a colon sorted
     after any name that doesn't, seeing as the most common functions
     will probably not be those in subcategories.
     I haven't implemented this, just started thinking over
     categories.  If you like it, I could implement it.  (The
     expressions part, I mean; not the GUI part.)

I've been thinking about this too, and I've got an idea
which might give a more pleasing gui than that produced by the Chicago
company:  If we use the features of the GtkTreeView widget, then we
can present a list of categories and allow the user to expand or
collapse those categories in which (s)he's interested.  It means that
the dialog box doesn't have to be cluttered with more widgets, yet
allows easy filtering and selection of the functions.

Would it be possible to make an api which provides an iterator which
can be used to return all the functions which belong to a given
combination of catagories?  It may be better to use bitfields instead
of sequential enums.

Having made that request, I don't consider it to be the most important
thing for pspp right now, so I'm probably not going to get around to
using such an api until I've got some time on my hands.


PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]