Henric Nilsson wrote:
I am, however, surprised of the fact that seq() prints it's internal representation of 0 as 0.0 when `from = 0.5', but as -1.110223e-16 when `from = 0.7'.
These second one isnt a zero!
> seq(from=0.5,by=-.1,len=6)==0 [1] FALSE FALSE FALSE FALSE FALSE TRUE
- in this case the last element is exactly zero. Internally it will be a string of 0 bits or some other representation that means precisely zero. Zero. Zilch, nada, zip.
> seq(from=0.7,by=-.1,len=8)==0 [1] FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE
- in this case the last element _isnt_ exactly zero. At some point in the calculation floating point's lack of precision kicks in, and the last element in that seq() will be represented internally by a pattern of ones and zeroes that isn't the zero-pattern, but is the pattern for -1.110223e-16 instead. Quite where that happens is controlled by the mechanism that seq() uses to generate its numbers.
I find it surprising that people still think that other people get surprised by this. Now that people start their programming with high-level languages like R, or Perl, or Visual Wotsit, they don't get exposed to internals, and think that numbers are just numbers. The idea that 0.1 != 1/10 would be surprising.
Assembly language for everyone, I say....
BSR
______________________________________________ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
