Re: Dinner prospect etc

Dennis_Young@CIS.ucsd.edu
Wed, 2 Jul 1997 08:45:00 -0700

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