Hi Ian, On Fri, 24 Aug 2001 23:24:26 +0200 "Ian Bearden" <bearden@nbi.dk> wrote concerning "Freeze the tracking! (was RE: brmodulematch track again)": > Yes, indeed, Flemming is correct. I did not have the line > track->SetID(i) in the copy of CopyDetectorTracks that I found. > Isn't this something that should be an 'official' piece of software? I'd prefer if it wasn't, but if you really want to add it to BRAT, then it should also be understood that it is transient, and will disappear as soon as the track matching uses the (superiour) BrTrack class. > That is, shouldn't we have > BrCopyDetectorTracksFromTpcTracksToTracksWeCanActuallyUseForReconstructingGl > obalSpectrometerTracks? LOL. > Perhaps the name needs some work, but I think that we are in a > confusing (at least it was for me) situation, in that our best > "local tracks" cannot be used directly with our track matching > routines. Yeap. Not a good situation at all. This reminds me of the 7P's :-) Perhaps the time would have been better spent fixing the matching rather than making an ad hoc and Q&D (to me that stands for Quirks and Deficiancies) "solution". In retrospect (for the N'th time, where N is rapidly approach infinity [thanks Djam for this nice phrase]) I'd say so. Remember, designing a piece of software (even a class) starts with talking a long work in the forest think hard what it should, contain, and so on. Designing a piece of software does not start by sitting down in front of the computer (as any CS student will tell you, that's the trivial part). > I propose, at least for discussion, that we freeze the tracking code > (except for obvious bug fixes) add BrCopyTpcTracks and concentrate > on analysis. There may be good reason to "freeze" over the weekend and until Wednesday next week (just don't update your BRAT), but since the "FS analysis" people will largely be out of the loop for the next 7 days or so, there is little reason to keep the freeze after wednesday next week. > It seems that our matching is working (at least when I'm not giving > it shitty input!) pretty well, and perhaps should be left alone long > enough to get some (more) results. > The only argument, to my mind, against this would be if there were > known serious problems with the code. It may well be that my idea of > a serious problem is not the same as the more fanatical c++'ers. I refer you to the so-called Q&D-"solution" approach and let it's merits speak (loudly) for it self. > Any comments? You betcha. Yours, Christian Holm Christensen ------------------------------------------- Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 DK-2200 Copenhagen N Cell: (+45) 28 82 16 23 Denmark Office: (+45) 353 25 305 Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
This archive was generated by hypermail 2b30 : Fri Aug 24 2001 - 18:14:00 EDT