Any trailing spaces I think will be in there because there were in the
original version--line copying, etc. TABs indeed have nothing to do with
it. I looked through a bit with vi and no problems are popping out at me,
so I think we're safe from any leading TABs sneaking in.
On Mon, Apr 17, 2017 at 9:53 PM, Hai Nguyen <nhai.qn.gmail.com> wrote:
> I don't think the trailing whitespace is always due to TAB.
>
> Copy a line with a extra space will cause that too.
>
> Hai
>
> On Mon, Apr 17, 2017 at 9:52 PM, David Cerutti <dscerutti.gmail.com>
> wrote:
>
> > We're getting several discussions going at once. First, Silicon Valley
> > looks like a promising evolution of Big Bang Theory.
> >
> > Second, I get 96K on Pascal!? Yes!!!! I've been working very hard
> trying
> > to figure out how to use 48K, and of course I'll be coding for backwards
> > compatibility, but that's amazing if they're giving us more SMEM to work
> > with. The approach I'm looking at would be completely separate from the
> > current non-bonded inner loop, so your shared memory footprint will not
> > affect what I've got. That being said, I can see how you're boxed in
> with
> > regard to __shared__ and I will be too in the sense that I'll be
> importing
> > as many atoms as I can before I hit "the wall." The more atoms I can get
> > into __shared__ simultaneously, the better, so gemstones could indeed
> scale
> > very well going forward.
> >
> > Third, I AM an emacs user like that idiot, but I'll hit some of the
> > libraries with vi to see what's really happening. I DO NOT intentionally
> > put tabs in anything. As long as the spacing changes get taken care of
> > now, in quick succession with the rest of the revision, it will not make
> > commit diffs any harder to view. There will be one giant change with a
> > clear understanding of what happened, and any commits thereafter will be
> > easy to interpret.
> >
> > Finally, the lookup table: if texture memory is unreliable, I can fit
> this
> > in __shared__. (That's what I had initially planned to do before I
> learned
> > what texture memory was). For a 10A cutoff, I'm looking at one table
> that
> > is 800 bytes and another that is 1224 bytes, so less than 2kb of lookup
> > tables overall. The first lookup table grows as the square of the cutoff
> > distance (not good--but it's still only 4k with a very large 16A cutoff),
> > the second (which is where the coefficients really reside) only grows as
> > the log of the squared cutoff distance (so the second table is still only
> > 1.7kb for a 16A cutoff). You multiply r2 by 8.0, then do a float ==> int
> > conversion to get the index to read from the first lookup table, and that
> > provides you an 8-bit int which tells you the place to look in the second
> > lookup table, which provides six coefficients for a rational function of
> r2
> > that approximates the derivative of erfc(r)/r. Accuracy to within a few
> > parts per billion out to 6A, and thereafter the *relative* accuracy falls
> > merely because the value of erfc(r)/r is nearly zero already.
> >
> > Dave
> >
> >
> > On Mon, Apr 17, 2017 at 9:14 PM, David Case <david.case.rutgers.edu>
> > wrote:
> >
> > > On Mon, Apr 17, 2017, Ruxi Qi wrote:
> > >
> > > >
> > > > FYI, trailing whitespace can be easily eliminated by the sed in-place
> > > > substitution as follows, say to process all .F90 files in batch, do:
> > > >
> > > > sed -i "s/\s\+$//g" *.F90
> > >
> > > True, but let's not do this just for the sake of doing it, or because
> > > some integration script or compiler complains about trailing
> whitespace.
> > > Large-scale changes like this can make it impossible to track true code
> > > changes, and for really minimal gain.
> > >
> > > Even with Dave's changes, some which were made to satisfy a rather
> > > arbitrary
> > > 96-character line limit, have to balance the pain of having some
> > > long lines with the pain of not being able to compare code to earlier
> > > versions.
> > >
> > > Establishing consistent indentation at the beginning of lines (to make
> > > code flow and logic clearer) is probably worth the pain in most cases.
> > > Removing trailing whitespace is often not worth the pain.
> > >
> > > ....dac
> > >
> > >
> > > _______________________________________________
> > > AMBER-Developers mailing list
> > > AMBER-Developers.ambermd.org
> > > http://lists.ambermd.org/mailman/listinfo/amber-developers
> > >
> > _______________________________________________
> > AMBER-Developers mailing list
> > AMBER-Developers.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber-developers
> >
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Apr 17 2017 - 19:30:01 PDT
