Hi Dima,
I think I can answer the part of your mail that pertains to Track.
Your concern, which is certainly justified, is exactly the reason why I
added the ParameterName class to the Track interface. The order of the
definitions in the enum determins what ordinal() returns, so if you use
Track.ParameterName.d0.ordinal() you should be fine. Having the enum be
more explicit, however, is a good idea.
It is unfortunate that this is so verbose, but you can reduce verbosity
by importing Track.ParameterName statically.
Furthermore, the javadoc contains information as to which number belongs
to which parameter.
Your suggestion to have getParameter accept a name as input is
unfortunately not going to be implemented easily, because, Track being
an interface, this would mean that all implementations of Track would
also have to add this method.
The current solution is admittedly a bit of a hack, but it was the least
invasive solution I could come up with.
I have made an attempt at a cleaner approach in my contrib area, and I
would be thankful for comments on that (even though it may not work for
you know, I view this as an experimental area to find out what works or
doesn't work for people).
The Parameters class, by the way, is probaly a mistake caused by a
misunderstanding on my behalf and I hope it doesn't lead to any
confusion.
Regards,
Jan
Furthermore there is
On Wed, 2006-12-13 at 13:47 -0600, Dmitry Onoprienko wrote:
> I've been trying to make different track finders work together in a single
> job, mainly to test the calorimeter assisted tracking performance in various
> modes, and the deficiencies of standard Track and TrackerHit interfaces
> really get in the way.
>
> The biggest problem with TrackerHit (besides being unusable for describing
> 2-dimensional hits like those in silicon strips) is that it's completely
> detached from any detector related objects, like layers or surfaces. I
> cannot even extract this information from underlying simulated hits in any
> reliable way since what kind of hits getRawHits() returns is up to
> implementation. I ended up using reflection framework to analyze hits I get
> from other track finders, which slows things down quite a bit.
>
> Problems with org.lcsim.Track have been discussed recently, so just one more
> observation: getTrackParameter(int i) seems to be a source of bugs, since
> mapping of indices to parameters is not defined in the interface. May be it
> should be complemented by getTrackParameter(Track.ParameterName par), and/or
> ParameterName should be extended to associate index with the parameter, like
>
> enum ParameterName {
>
> d0(0),
> phi0(1),
> omega(2),
> z0(3),
> s(4)
>
> public final int index;
> private ParameterName(int index) {this.index = index;}
>
> }
>
> - Dima.
>
--
Jan Fridolf Strube University of Oregon
Stanford Linear Accelerator Center
mailstop 35
bldg 48, rm 244
phone: (650) 926-2913
|