Re: Dinner prospect etc

From: Dennis_Young@CIS.ucsd.edu
Date: Wed Jul 02 1997 - 10:45:00 EST


I'd like to see the $LOST keyword used to record the total number of events 
NOT listed:

1) Acquire sample ungated to estimate populations (e.g. CD45)

2) Gate for rare events and acquire GATED (e.g. CD34). You see, this is 
where the lost events go...


Dennis
*************************************************************************
* Dennis J. Young                            Voice : (619) 822-0407     *
* Flow Cytometry Core Facility               FAX   : (619) 822-0412     *
* University of California, San Diego  USA   e-mail: djyoung@ucsd.edu   *
*                       http://www-core.ucsd.edu/flow-core.html         *
*************************************************************************RE

Reply Sep------------

Ray asks:

> On the FCS side, are there any programs that do cover
> all of the permutations of any version? Are there any
> that actually conform yet?

The answer to the first part is definitely no. The FCS standard is
unfortunately much too flexible--thus writing code to read all possible variants
is nearly impossible, not to mention simply not worth the effort! For
example-who now stores bivariate histograms in data files? Anyone? And yet,
this is part of the FCS standard. And I will buy dinner, with wine, for the
first person who shows me a legitimate, non-hypothetical use for the $LOST
keyword.

In particular, the problem becomes considerably more difficult when you consider
fully bit-packed data (i.e., putting 10 bit data in only 10 bits instead of 16).
For those who thought byte order was a problem for FCS, this is a nightmare by
comparison. Even for those who didn't think byte order was difficult, this is
still a nightmare.

It also seems that the evolution of FCS is only going towards greater
flexibility rather than less. This is like the evolution of CPU's--for a while,
manufacturers were putting greater and greater power into each--supporting
thousands of different instructions. Then someone discovered that supporting
LESS instructions made for MORE efficient processers (i.e., RISC processors). I
hope that the FCS standard will soon evolve in a similar direction--simplify!
Especially, in a way that encourages rigorous data analysis (e.g., not allowing
the storage of non-listmode data).

Why not make the new FCS actually only allow those formats which are currently
supported by a vast majority of software? The distilled version would be far
easier to support programmatically, and would result in far fewer problems for
cross-compatibility.

mr



This archive was generated by hypermail 2b29 : Wed Apr 03 2002 - 11:49:54 EST