From fparlamis at mac.com  Sat Sep 23 20:44:50 2006
From: fparlamis at mac.com (Parlamis Franklin)
Date: Sat, 23 Sep 2006 08:44:50 -1000
Subject: [Rd] generics for primitive functions
In-Reply-To: <45153826.3010203@r-project.org>
References: <6E529B79-B0D5-4F9B-AB5D-11D588D47D0A@mac.com>
	<45153826.3010203@r-project.org>
Message-ID: <7399B135-3D5F-4839-9C9F-7C0BD2CDB79D@mac.com>

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
>> day            22
>> svn rev        39471
>> language       R
>> version.string R version 2.4.0 beta (2006-09-22 r39471)
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>




[Rd] generics for primitive functions
Parlamis Franklin