Hi,
Many thanks for your replies.
On principle I expected to get the following advice. Create a simple
class describing the mapping (both of you say this), then make a T*List*
with all possible mappings, then make a couple of Hash functions (one Hash
function per "sort"-type), then create some T*Hash* objects using these
Hash functions. Somehow none of you thought about it. Why ? What's wrong
in such approach ?
The solution proposed by Rene is a one-way solution. I think that even if
I "optimize" it (separate branches for BoardID, ModuleID, ...), the time
needed to find a particular board/module/... combination would be quite
significant. Moreover, if I require a particular "wire" (I mean from
WireNumber and WireType give me board/module/...), then I would need
to look for it all over the tree (scan all "entries" - that's why I call
it one-way solution).
The solution proposed by Valeri requires me to know the number of channels
in advance (I need to set the "size" of the table, don't I), which is not
always true (unfortunately it may happen that the number of "hardware
electronics" channels is bigger or smaller then the number of "detector
wires" - some "electronics" channels may be spare and/or some wires
may be disconnected). Thus, I would prefer NOT to set any hard
"limits" on the number of "slots".
Rene writes :
> (... comparing "TTable" versus "TTree" approach ...)
> etc). In case of a large table, this will make a substantial difference
> in time.
I think I disagree. Consider that you usually anyhow have to read mappings
for all channels, so ... you can read them in "portions" from the tree, or
you can read them as a whole table in one piece in the beginning.
There should be no "substantial difference in time", shouldn't it ?
Jacek.
PS. I was thinking about two hash functions : from board/module/channel -
"BoardID*65536 + ModuleID*256 + ChannelID", from WireNumber/WireType -
"WireType*65536 + WireNumber". Jacek.
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:50 MET