Long reply- > > 2) I guess you meant "mark delayed channels by setting bit 128". > > That would be bit 8 right. Bit 128 would reguire a 16 byte word > (that's long long - right?). No, it would be bit 7. Bits (unlike wires) are counted from from 0. > ... "The lower 7 bits sets the wire number, and if bit 8 > is set, the wire is delayed." - just like 8 bit character encoding > needed to implement an alphabet for any civilised language; like > Russian and Danish :-) This might be described as "binary coding" (bit 7 has special meaning). My scheme is exactly the same, but uses "decimal coding" (3rd digit from the right has special meaning). (Digits are counted from one: the first digit is digit one, not digit zero. There is no zero-th digit). > I was more curious why you didn't choose such a scheme. After all, you > are a CS PhD, so I thought you'd think more in terms of bit > manipulations, then say the average Physichs PhD would, who's like to > make scheme that say "Event numbers are delayed, odd are prompt", or > "count delayed from 255 and down and prompt from 0 and up", or > something similar :-( But I am not "CS". My training is in "applied math", and it makes a world of a difference. All the "CS" bozos are taught is bits and bytes, and know squat about the real world, while applied math is all about problem domains, mathematical models and speaking the same language as the experts one is working with. In practical terms, I do not decide on a whim: "let's count wires starting from one" (or from zero). I go and ask the folks who build chambers: "how do *you* count the wires?" (and in which direction?). How are they labeled on the engineering drawings and on the chamber itself? But sometimes, as in this case, a non-trivial and convoluted scheme has to be invented. Here I use my professional software developer experience- things should be easy to use and easy to debug (always at the expense of computational efficiency). Why is my scheme easier to use and debug? Human limitations: our common arithmetic is base-10, not base 2 or 16 or 256. I am not good at base-16 and base-256 math, I am not good at adding 128 and subtracting from 255, but most of the time I have no problem adding and subtracting 100 and I suspect most people find this easy, too. So when looking at raw data dumps, or sitting in the debugger, wire and channel numbers look more natural (and easier for people to deal with) in decimal, rather than in hex. That said, comes the main software development idea- write correct software (obviously correct! No tricky operations and fancy algorithms that require a CS PhD to understand), run it, profile it, find the bottlenecks and *then* optimize (i.e. use binary instead of decimal coding to save on integer-divide/multiply operations). In this case, I did this times enough to know that the type of software we write is dominated by FP sin(), cos() and sqrt() calculations in the tracking code, and that raw data packing and unpacking contribute very little the total running times, so it is at best pointless to optimize them (even counter-productive if the code and data become more complicated and less transparent). > > 0) ... there is no "wire zero". > > That's probably because the DAQ for the old DCs was written in Fortran > (4 if they were lucky!), and not the yougster C or even the infant Java! When you count bananas, do you say "banana zero, banana one, banana two, hey, I got three bananas!"? I hope not, and I do not think you (or anybody else) ever will, regardless of acceptance and use of Fortran, C and Java. So when you count bananas (or wires), please better start with "1" and make no excuses that C and Java make you add "+1" in funny places. > > P.S. The example in (2) has a mistake: 128+3 = 131, not 132. Did you spot it? > Ofcourse I did! Did others? Tired, unfamiliar with the code, in the middle of the night, during the run, while minutes of precious beam tick away? > Sure. Again, I was more curious as to how you came up with the > encoding you did, rather then some bit based one. Also, I know how > frustating it is to not get reponse to a proposal, say _something_ :-) Decimal coding is hardly uncommon. Examples: 10-digit US phone numbers (coded as AAA-BBB-CCCC), dates (YYYY-MM-DD), US library catalog book codes, ISBN's, ethernet addresses (the first few bytes are the manufacturer code). -- Konstantin Olchanski Physics Department, Brookhaven National Laboratory, Long Island, New York olchansk@bnl.gov
This archive was generated by hypermail 2b29 : Fri Mar 23 2001 - 11:16:40 EST