[R] Regex exercise

[Michael Hannon]

> 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