On Oct 24, 2007, at 9:27 PM, Arlo Faria wrote:

> > > Be aware that there's a big in v3_20 (and earlier) that causes
> > > problems if there are a lot of reject frames. Specifically if the
> > > fraction of frames rejected ever passes the fraction of work being
> > > done by a given thread (e.g. 12.5% reject with 8 threads). There's
> > > been a fix around for a while but I haven't had time to release
> it (or
> > > merge Arlo's recent improvements).
> > Noted. Thank goodness I'm an accepting kind of guy, and don't tend
> > to reject much. :-)
>
> Rejecting frames is no joke! We've recently found that it's a great
> way
> to speed up training if you reject them in such a way as to leave a
> subset of data that has a uniform distribution over classes. This can
> reduce training time by an order of magnitude.

Yeah, that's similar to the kind of thing that Jun Hou and Larry
Rabiner were seeing in their TDNN trainings, if I interpret what
you're saying to mean equalizing the class priors in the data. I
assume this means that you want to randomly select individual frames
across utterances, rather than patches within utterances? Or does
this disrupt the caching too much?

It strikes me that this is in fact what we were trying to replicate,
without success (one of my students ran the experiment). Didn't
think to look for a bug, though.

Do you notice any degradation/gain in accuracy?

David -- no hurry on the patch, although it will be useful over here
when it gets in.

-Eric