> You are essentially doing the eval and parsing by hand instead of > letting eval(parse()) do the work. I prefer the latter.
Hi, Bert. Yes, I agree with both your analysis and your preference. > However, your code did something that I did not expect and for which I > can find no documentation -- I would have thought it shouldn't work. > > ... and that is, the return of your sapply is n1:n2 where n1 and n2 > are _character values_ (because that's what gsub returns, of course). > I would have thought this would give an error, but in fact it gives > the "correct" result. That is, to my complete surprise: > > > "3":"5" > [1] 3 4 5 > > seq(from= "3", to= "5") > [1] 3 4 5 > > seq.int( "3", "5") > [1] 3 4 5 > > "3":5 > [1] 3 4 5 > > all work! Is this behavior documented anywhere and I've missed it or > is it a secret "feature." And to what extent does it work, noting > that: > > seq(from="3.5",to="5.5",by="1") > Error in to - from : non-numeric argument to binary operator I think this worked because I started my variable names with 'n', the same as in "number" ;-) I just stumbled across this behavior, and I don't understand it either. There does seem to be an ethos in some parts of the R community that says "let's make this sucker work, regardless of the type of garbage that's input", but it certainly isn't applied consistently: > sin(pi) [1] 1.2246e-16 > sin("3.1415927") Error in sin("3.1415927") : Non-numeric argument to mathematical function No suitable frames for recover() Note that I'm not complaining about this, just noting an apparent inconsistency. Also, the details of the ':' function are not immediately obvious: > `:` .Primitive(":") > I suppose the source code would reveal all, but I have other things to do. -- Mike ______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.