i think most of these problems have been resoved in v3. coming soon to
a kiosk near you...
--chris
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