Thanks David,
I never seem to get my intention clear when I post to the R-help list...
I am not sure why...
Anyways, my issue was not with the test (I came up with something
similar). It was actually with the name of the function which I had to
create, given that this test needed to be used dozens of times in the
framework I work with.
My choice of function name was less than optimal and got me into all the
troubles discussed in previous posts. My own debugging identified that
the test was not the problem but the function name somehow interfered
with lattice. So I already knew how to fix my problem before posting...
just choose a different name.
My post was actually intended to clarify the reason why the function
name itself was causing the issue... which I believe it now perfectly
clear, thanks to all the previous posts.
On 11/16/2015 12:59 PM, David Winsemius wrote:
On Nov 16, 2015, at 9:35 AM, sbihorel <sebastien.biho...@cognigencorp.com>
wrote:
Hi,
Thanks everyone for all your insights...
I feel that the discussion is getting way deeper and more technical and it needs to be
from the point of view of what I was trying to achieve with my little
"is.numeric.factor" function (ie, checking if an object is a factor and if all
levels of this factor can be coerced to numeric values).
You seem to be asking for a compound test: first with is.factor, then to see
whether all the levels could be coerced to numeric properly. I would think that
you would need something like:
if( is.factor(varname) ) { !sum(is.na(as.numeric(as.character(varname)))) }
else { FALSE }
—
David.
I guess that, as Duncan pointed point, using dots in function names becomes bad practice
for function starring "is". I'll rename my function, that's it.
On 11/16/2015 11:43 AM, Martin Maechler wrote:
Bert Gunter <bgunter.4...@gmail.com>
on Mon, 16 Nov 2015 08:21:09 -0800 writes:
> Thanks Duncan. You are right; I missed this.
> Namespaces and full qualification seems the only reliable solution to
> the general issue though -- right?
Not in this case; full qualification is very very rarely needed
in package code (even some "schools" do use and propagate it
much more than I would recommend), and we are talking about the
lattice code, i.e., package code, not user code, here.
I.e., using base::is.numeric() would not help at all: It
will still find the bogous is.numeric.factor because that is
taken before the internal default method.
Also, I'm almost sure S4 dispatch would suffer from the same
feature of S (and hence R) here: You are allowed to define
methods for your new classes and they are used "dynamically".
(I also don't think that the problem is related to the fact that this
a.b.c() case is S3-ambigous: a() method for "b.c" or a.b() method for "c".)
Unfortunately, this can be misused to define methods for
existing ("base") classes in case they are handled by the default method.
OTOH, if base/stats/... already *had* a 'factor' method for
is.numeric(), be it S3 or S4, no harm would have been done by
the bad user defined is.numeric.factor definition, thanks to the
namespace technology.
To get full protection here, we would have to
store "the dispatch table for all base classes" (a pretty vague notion)
with the package at package build time or install time ("load time" is too late:
the bad is.numeric.factor() could already be present at package load time).
I'm not sure this would be is easily feasible.... but it may be
something to envisage for R 4.0.0 ..
Martin
> Cheers,
> Bert
> Bert Gunter
> "Data is not information. Information is not knowledge. And knowledge
> is certainly not wisdom."
> -- Clifford Stoll
> On Mon, Nov 16, 2015 at 7:42 AM, Duncan Murdoch
> <murdoch.dun...@gmail.com> wrote:
>> On 16/11/2015 10:22 AM, Bert Gunter wrote:
>>>
>>> There is no multiple dispatch; just multiple misunderstanding.
>>>
>>> The generic function is "is.numeric" . Your method for factors is
>>> "is.numeric.factor".
>>>
>>> You need to re-study.
>>
>>
>>
>> I think the problem is with S3. "is.numeric.factor" could be a
>> "numeric.factor" method for the "is" generic, or a "factor" method for
the
>> "is.numeric" generic. Using names with dots is a bad idea. This would
be
>> all be simpler and less ambiguous if the class had been named
>> "numeric_factor" or "numericFactor" or anything without a dot.
>>
>> Duncan Murdoch
--
Sebastien Bihorel
Cognigen Corporation
(t) +1 716 633 3463 ext 323
Cognigen Corporation, a wholly owned subsidiary of Simulations Plus, Inc.
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.
David Winsemius
Alameda, CA, USA
--
Sebastien Bihorel
Cognigen Corporation
(t) +1 716 633 3463 ext 323
Cognigen Corporation, a wholly owned subsidiary of Simulations Plus, Inc.
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
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.
