Re: [BLAST_ANAWARE] plee for a few variable unit conventions

From: zhangchi (zhangchi@general.lns.mit.edu)
Date: Thu Jun 26 2003 - 14:40:38 EDT


Hi Aaron,

I am interesting to know where the mistake was. which file, which line, in
v2 or v3?

I remember Doug mentioned in one of his emails that the difference between
using integer(hence microns) and float(mm or cm) is not significant. And I
100% agree that the CPU time gained must be weighed against the human time
spent. If we want run time speed for any expense, we should have used
Fortran which is still the king of speed in numerical computation. One
still has to play a lot of tricks to make C++ codes or even C codes to
run as fast as Fortran.

I do not know of any place that uses micro-sec/meter though, except in
time to distance. TBLWc1 now uses mm while every other piece of code
uses cm.

Chris and I already made the decision to change mm to cm and the codes are
already written. So there can be a gazillion email exchanges on this issue
but we will be using centimeters within the reconstruction. How do we
present the results to the larger community is ofcouse a totally different
issue.

GeV, cm, ns will be the units we will be using uniformly in v3. v2 now
also uses mm, ps. which causes confusion, unecessary conversion.

About Time2Distance classes, we get from you guys and did some copy and
paste. I dare not change them for the exact reason you mentioned. a lot of
numerical constants hard coded in. The bless is that it interfaces with
the rest of the codes pretty good so I can just use them as they are.
Feel bad that you have to dig into those codes.

Good Luck.

Chi

On Thu, 26 Jun 2003, Aaron Joseph Maschinot wrote:

>
> i just spent two hours hunting down an error which ultimately turned out
> to have to do with the code assuming the wrong units for a variable. i
> wonder how many more similar errors are lying deep within our
> reconstruction.
>
> at the risk of initiating yet another slew of pointless e-mails, i have to
> say, once again, that i really think that we should be using a common set
> of units for all variables.
>
> has anyone ever checked the difference in run-time efficiency from working
> in, say, microns as opposed to centimeters? on modern computers/compilers
> is it even noticeable? if this is the primary reason for working in
> different sets of units, then the amount of efficiency gained should be
> weighed against the number of hours people will spend debugging unit
> errors.
>
> at least, can we all agree to the following:
>
> 1. if you write a subroutine that has variables with units passed
> into or returned, then please document the expected units at the
> beginning of the subroutine.
>
> 2. don't place numerical literals directly in the code. for example,
> don't place a "2.0" when you could define NS2TDC = 2.0 and use that
> instead. products of several literals in the code take some time to
> decipher.
>
> 3. on the subject of time versus tdc variables, don't include "tdc"
> in the name of an honest-to-goodness time variable. this gets
> confusing. especially when you then go on to include "t" in the name
> of a tdc variable (which is exactly what our reconstruction does
> right now (see the TBLWc1Time2Distance class)).
>
> our reconstruction library has now grown to phenominal size. if we don't
> start enforcing some coding conventions, it will soon become unfixable.
>
> aaron
>



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST