Re: [Rd] Regular expressions
On Sat, 23 Sep 2006, Dominick Samperi wrote:
> When I type
>
> ls("package:base", pattern="log*")
> functions with names like "floor" and
> "Sys.setlocale" are included. I don't
> think this is how "*" is supposed to work.
>
> To get the desired response I have to use:
> ls("packge:base", pattern="logg*")
If you want a wildcard-like behaviour, use glob2rx, e.g.
> glob2rx("log*")
[1] "^log"
> I thought "log*" means "log" followed by anything?
Please read ?regexp.
It means 'lo' followed by zero or more occurrences of 'g'.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] generics for primitive functions
Probably a bug, but not at all the one you imply. You have found a way
to subvert a guarantee in R that methods for primitives can never be
redefined for basic data types.
As you no doubt found, but didn't show us, so long as you say sqrt(4)
the result is correct. (Your "Works" should really read "Gotcha!").
Since a large amount of effort and not a little programming pain has
been spent retaining the purity of primitive calls to satisfy the
efficiency lobby, it's not clear what should happen when one insists on
calling the generic function directly. Either an error or just a call
to the primitive would be the two likely candidates. Not what happens
in your first example though.
If you really want a "numeric" class that does something different for
sqrt(), define an S4 class that contains "numeric"
> setClass("WeirdNumber", contains="numeric")
[1] "WeirdNumber"
> setMethod("Math", "WeirdNumber", function(x) "Weird")
[1] "Math"
> xx = new("WeirdNumber", 1:10)
> sqrt(xx)
[1] "Weird"
Parlamis Franklin wrote:
> i think these two code snippets exhibit a bug. they are identical
> but for the inclusion of an initial line in snippet [2]
>
> [1]
> setMethod("Math", signature(x = "numeric"), function(x) "Works")
> getGeneric("sqrt")(4)
>
> [2]
> getGeneric("sqrt")(4)
> setMethod("Math", signature(x = "numeric"), function(x) "Works")
> getGeneric("sqrt")(4)
>
> these are my results, when each is run from a fresh R session
>
> [1]
> > setMethod("Math", signature(x = "numeric"), function(x) "Works")
> [1] "Math"
> > getGeneric("sqrt")(4)
> [1] "Works"
>
> [2]
> > getGeneric("sqrt")(4)
> `__Deferred_Default_Marker__`
> > setMethod("Math", signature(x = "numeric"), function(x) "Works")
> [1] "Math"
> > getGeneric("sqrt")(4)
> `__Deferred_Default_Marker__`
>
> the section in "How Methods Work" that deals with this is unfinished,
> but i think it suggests that getGeneric("sqrt")(4) should work out of
> the box.
>
> franklin parlamis
>
> > version
> _
> platform powerpc-apple-darwin8.7.0
> arch powerpc
> os darwin8.7.0
> system powerpc, darwin8.7.0
> status beta
> major 2
> minor 4.0
> year 2006
> month 09
> day22
> svn rev39471
> language R
> version.string R version 2.4.0 beta (2006-09-22 r39471)
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] generics for primitive functions
Yes, I figured I might have entered the forbidden zone (one hint was
that I had to set the group method to achieve my goal -- an attempt
to directly set a method for the 'sqrt' function was frustrated in
the manner you suggest). I have two followup questions and a request:
(i) Should I expect that the fix will be to seal group methods for
groups that contain primitive functions and signatures comprising
only basic data types, or that group methods will remain unsealed
(and thus still work as desired for non-primitive underliers) and
some other block applied?
(ii) In "How Methods Work" (pg. 8), you write: "So long as
computations access the generic function through getGeneric(), most
computations should be unaffected." I took this as a suggestion that
calls like getGeneric("sqrt")(4) were the suggested way to operate
with primitives under S4. What does it really mean?
Now the request (with some explanation). I am not really interested
in redefining primitives for class 'numeric.' What I really want to
do is define working non-primitive variants of primitives for class
'expression'. I have already done this for a class 'Expression'
which contains 'expression' as you suggest, but I have been somewhat
frustrated to go through the formality of dealing with a "custom"
class for this purpose (as it adds unnecessary bulk and coercion to
my code). Since AFAIK none of the primitives in the 'Ops' or 'Math'
groups work for objects of class 'expression' anyway, I don't see
what purity we are retaining by sealing the methods on these
functions for signatures comprising only objects of class 'expression'.
I'd like to request (as a feature change) that these methods be
unsealed for signatures comprising only objects of class
'expression'. More broadly, I think it would be nice to unseal
methods for primitive functions on all signatures for which the
primitive would produce an error. Sealing things that don't work is
slightly cruel. Perhaps a 'sealedPrimitives' option that the
efficiency guys could check and freaks like me (who want to make 2+2
= 3) could uncheck would be the simplest solution. Of course I make
this request humbly -- I have no idea what might be the cost in code
of the discrimination I am requesting.
Franklin
On Sep 23, 2006, at 3:35 AM, John Chambers wrote:
> Probably a bug, but not at all the one you imply. You have found a
> way to subvert a guarantee in R that methods for primitives can
> never be redefined for basic data types.
>
> As you no doubt found, but didn't show us, so long as you say sqrt
> (4) the result is correct. (Your "Works" should really read
> "Gotcha!").
>
> Since a large amount of effort and not a little programming pain
> has been spent retaining the purity of primitive calls to satisfy
> the efficiency lobby, it's not clear what should happen when one
> insists on calling the generic function directly. Either an error
> or just a call to the primitive would be the two likely
> candidates. Not what happens in your first example though.
>
> If you really want a "numeric" class that does something different
> for sqrt(), define an S4 class that contains "numeric"
> > setClass("WeirdNumber", contains="numeric")
> [1] "WeirdNumber"
> > setMethod("Math", "WeirdNumber", function(x) "Weird")
> [1] "Math"
> > xx = new("WeirdNumber", 1:10)
> > sqrt(xx)
> [1] "Weird"
>
>
> Parlamis Franklin wrote:
>> i think these two code snippets exhibit a bug. they are
>> identical but for the inclusion of an initial line in snippet [2]
>>
>> [1]
>> setMethod("Math", signature(x = "numeric"), function(x) "Works")
>> getGeneric("sqrt")(4)
>>
>> [2]
>> getGeneric("sqrt")(4)
>> setMethod("Math", signature(x = "numeric"), function(x) "Works")
>> getGeneric("sqrt")(4)
>>
>> these are my results, when each is run from a fresh R session
>>
>> [1]
>> > setMethod("Math", signature(x = "numeric"), function(x) "Works")
>> [1] "Math"
>> > getGeneric("sqrt")(4)
>> [1] "Works"
>>
>> [2]
>> > getGeneric("sqrt")(4)
>> `__Deferred_Default_Marker__`
>> > setMethod("Math", signature(x = "numeric"), function(x) "Works")
>> [1] "Math"
>> > getGeneric("sqrt")(4)
>> `__Deferred_Default_Marker__`
>>
>> the section in "How Methods Work" that deals with this is
>> unfinished, but i think it suggests that getGeneric("sqrt")(4)
>> should work out of the box.
>>
>> franklin parlamis
>>
>> > version
>> _
>> platform powerpc-apple-darwin8.7.0
>> arch powerpc
>> os darwin8.7.0
>> system powerpc, darwin8.7.0
>> status beta
>> major 2
>> minor 4.0
>> year 2006
>> month 09
>> day22
>> svn rev39471
>> language R
>> version.string R version 2.4.0 beta (2006-09-22 r39471)
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-dev
[Rd] Incomplete loading of files into Windows script editor, suspected bug regarding non-standard EOL marker handling (PR#9248)
Full_Name: Klaus Thul Version: R2.3.1 (CRAN binary for Windows) OS: Windows XP Submission from: (NULL) (220.132.142.175) When I read a longer text file created on Mac OS X into the built-in script editor of R for windows, it is read only incomplete. The same file can be loaded without problem e. g. into WordPad. I think the reason for the behavior is that Mac OS X uses different EOL markers, and R for windows doesn't handle these markers correctly. I don't have access to an UNIX/LINUX system, but I guess files generated on these systems will cause the same problem. I can provide an example file which fails if necessary. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#9248) Incomplete loading of files into Windows script
Please, we do need complete reproduction instructions (and not speculation) as the FAQ asks. 1) How exactly did you read the file in? 2) 'longer' than what? 3) What line ending is this? I've just tried loading a 1000-line 50kb file using the 'Open Script' menu item, and it worked with CRLF, LF or CR line endings. Some guesses are that there are control characters in the file or an encoding problem (what is your locale?). On Sun, 24 Sep 2006, [EMAIL PROTECTED] wrote: > Full_Name: Klaus Thul > Version: R2.3.1 (CRAN binary for Windows) > OS: Windows XP > Submission from: (NULL) (220.132.142.175) > > > When I read a longer text file created on Mac OS X into the built-in script > editor of R for windows, it is read only incomplete. The same file can be > loaded > without problem e. g. into WordPad. > > I think the reason for the behavior is that Mac OS X uses different EOL > markers, > and R for windows doesn't handle these markers correctly. I don't have access > to > an UNIX/LINUX system, but I guess files generated on these systems will cause > the same problem. > > I can provide an example file which fails if necessary. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
