From: John Stone (johns_at_ks.uiuc.edu)
Date: Mon Feb 16 2004 - 23:56:13 CST

Juan,
  I believe the cause of misunderstanding here is that
the implementation of veclength in VMD is done in single
precision, and so that's precisely the reason you're getting
a weird answer. The implementation in VMD is not using all of
the digits of the two constants in your example below, they are
being truncated to single-precision, and thus the answer is a
smaller number than the original double-precision numbers.
(keep in mind that the square of that second number is quite small..)

So, the answer is correct given that the implementation is all
single-precision floating point arithmetic (all the way through
including the squaring, summation, and square root call...)
That's also why its faster than doing it various other ways.

  John Stone
  vmd_at_ks.uiuc.edu

On Mon, Feb 16, 2004 at 07:54:55PM -0800, Juan Alfredo Freites wrote:
> Dear John and VMD users,
>
> In some instances veclegth isn't giving me the right answer, here is an
> example
>
> veclength {2.37137085199 0.000350952148438}
> 2.37137079239
>
> we can see that is wrong because the answer is less than one the
> components, conventional expr{} gives the right answer
>
> expr
> {sqrt((2.37137085199*2.37137085199)+(0.000350952148438*0.000350952148438))}
> 2.37137087796
>
> but it's twice more expensive than veclength. I also tried veclength [list
> ...] so as to avoid any ambiguity, but got the same result.
>
> any thoughts?
>
> --
> J. Alfredo Freites
> Department of Physics
> University of California, Irvine
> Irvine, CA 92697-4575
> (949) 824-9921
>

-- 
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email: johns_at_ks.uiuc.edu                 Phone: 217-244-3349              
  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078