#6 0.4 gates not always correctly handled.

Ron Fox
Ron Fox

Colin has observed some cases where there are inconsistent results in
applying gates to spectra when the events are varying in shape, and
events are applied across shapes... what I mean by this is: Suppose you
have a pair of event packets A, B you set a gate on parameters in A and
apply it to spectra created from B... if there are cases where A does
not exist but B does, the gated spectra may be incremented when they
should not be:

This error is due to my stupidity and has a long history which I'll
relate for people who may be interested in it:

In the begining, parameters were initialized to a 'bad value' (all bits
set), and the fact that this bad value was out of range 'automatically'
prevented spectra from being initialized.

Then along came bitmask spectra...all bits set is a valid value for
them. Therefore, parameters became pairs of valid flags and value
data. Much of SpecTcl was just fine, because constructing an Event
still initialized the value to something bad, bit spectra were modified
to pay attention to the valid flag.

Then along came reports of performance problems. A profile analysis
revealed that constructing the CEvent objects over and over again was a
major player in this. Therefore, I started recycling these objects...
When I did this I was only half smart... I recognized that this meant
that I 'd better make all spectra care about the valid flag, but was
stupid enough to forget that gates evaluation also needed to start
paying attention to the valid flags since parameters were not gaurenteed
to have invalid values anymore (events are recycled by setting all the
valid flags false). This error on my part causes some spectra to be
over-incremented if it happens that the recycled event contains a set of
values which makes the gates required by the spectra in packet B e.g.

Fixes and tests of the fixes are in the works... watch
msu.nscl.daq.announce for an announcement that you really need to relink
all your code.

Note that SpecaTcl-0.3 users are, for once, unaffected as event
recycling is a 0.4 performance 'enhancement'.



  • Ron Fox

    Ron Fox - 2001-10-23
    • assigned_to: nobody --> ron-fox
  • Ron Fox

    Ron Fox - 2001-10-31
    • status: open --> closed

Log in to post a comment.