Re: [Rd] '==' operator: inconsistency in data.frame(...) == NULL

2019-09-25 Thread Martin Maechler
> Hilmar Berger 
> on Tue, 24 Sep 2019 19:31:51 +0200 writes:

> Dear Martin,
> thanks a lot for looking into this. Of course you were right that the 
> fix was not complete - I apologize for not having tested what I believed 
> to be the solution.

> My comments on the S4 classes seemed to stem from a misunderstanding on 
> my side. I now believe to understand that S4 classes that inherit from R 
> base object types might dispatch Ops for the same object types.

> If the base object value of such S4 classes is unset and therefore 
> empty, this empty value will be passed on to e.g. Ops.data.frame where 
> it would trigger the same issue as e.g. logical(0).

> setClass("MyClass", slots = list(x="numeric", label="character"), 
> contains = "numeric")
> a = new("MyClass", x=3, label="FOO")
> a@.Data

>> logical(0)

> a == data.frame(a=1:3)
> # error

> I understand that this is all as expected and the error should most 
> likely disappear with the fix you submitted for other 0-extent cases.


> Thanks again and best regards,
> Hilmar

You are welcome!
Indeed, I had modified code in R-devel that makes these Ops work with many
0-extent data frames (compatibly with corresponding 0-extent
matrices).
Thank you, Hilmar!

In addition I confirm that indeed comparison with S4 objects as
above now works too :


R Under development (unstable) (2019-09-23 r77210) -- "Unsuffered Consequences"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

  ## {learn: you can use the return value of setClass() !}

  MY  <- setClass("MyClass", slots = list(x="numeric",label="character"), 
 contains = "numeric")
  a <- MY(x=pi, label="FOO")
  D3 <- data.frame(a=1:3)

> identical(D3 == a, D3 == logical())
[1] TRUE
> 

Best,
Martin

> Am 18/09/2019 um 11:29 schrieb Martin Maechler:
>>> Martin Maechler
>>> on Wed, 18 Sep 2019 10:35:42 +0200 writes:
>> > Hilmar Berger
>> > on Sat, 14 Sep 2019 13:31:27 +0200 writes:
>> 
>> >> Dear all,
>> >> I did some more tests regarding the == operator in Ops.data.frame (see
>> >> below).  All tests done in R 3.6.1 (x86_64-w64-mingw32).
>> 
>> >> I find that errors are thrown also when comparing a zero length
>> >> data.frame to atomic objects with length>0 which should be a valid 
case
>> >> according to the documentation. This can be traced to a check in the
>> >> last line of Ops.data.frame which tests for the presence of an empty
>> >> result value (i.e. list() ) but does not handle a list of empty values
>> >> (i.e. list(logical(0))) which in fact is generated in those cases.
>> 
>> >> There  is a simple fix (see also below).
>> 
>> > I'm pretty sure what you write above is wrong:  For some reason
>> > you must have changed more in your own version of Ops.data.frame :
>> 
>> > Because there's a line
>> 
>> > value <- unlist(value, ...)
>> 
>> > there, value is *not*  list(logical(0)) there, but rather  logical(0)
>> > and then indeed, your proposed line change (at the end of 
Ops.data.frame)
>> > has no effect for the examples you give.
>> 
>> On the other hand, there *is* a simple "fix" at the end of
>> Ops.data.frame()  which makes all your examples "work" (i.e. not
>> give an error), namely
>> 
>> --
>> 
>> @@ -1685,7 +1684,7 @@
>> else { ## 'Logic' ("&","|")  and  'Compare' 
("==",">","<","!=","<=",">=") :
>> value <- unlist(value, recursive = FALSE, use.names = FALSE)
>> matrix(if(is.null(value)) logical() else value,
>> -   nrow = nr, dimnames = list(rn,cn))
>> +   nrow = nr, ncol = length(cn), dimnames = list(rn,cn))
>> }
>> 
>> --
>> 
>> i.e., explicitly specifying 'ncol' compatibly with the column names.
>> However, I guess that this change would *not* signal errors
>> where it *should* and so am *not* (yet?) proposing to "do" it.
>> 
>> Another remark, on  S4  which you've raised several times:
>> As you may know that the 'Matrix' package (part of every
>> "regular" R installation) uses S4 "everywhere" and it does
>> define many methods for its Matrix classes, all in source file  
Matrix/R/Ops.R
>> the development version (in svn / subversion) being online on R-forge 
here:
>> 
>> 
https://r-forge.r-project.org/scm/viewvc.php/pkg/Matrix/R/Ops.R?view=markup&root=matrix
>> 
>> and "of course", there we define S4 group methods for Ops all
>> the time, and (almost) never S3 ones...
>> [[but I hope you don't want to start combining data frames
>> with Matrix package matrices, now !]]
>> 
>> Mart

Re: [Rd] depending on orphaned packages?

2019-09-25 Thread Martin Maechler
> Ben Bolker 
> on Tue, 24 Sep 2019 20:09:55 -0400 writes:

> SuppDists is orphaned on CRAN (and has been since 2013).
> https://cran.r-project.org/web/checks/check_results_.html

> Oddly, the simulate method for the inverse.gaussian family
> [inverse.gaussian()$simulate] depends (in a loose sense) on SuppDists
> (it fails if the SuppDists namespace is not available:

> if (!requireNamespace("SuppDists", quietly = TRUE))
> stop("need CRAN package 'SuppDists' for simulation from the
> 'inverse.gaussian' family")


> The statmod package also implements inverse gaussian d/p/q/r functions
> .  It is
> lightweight (depends on R >= 3.0.0, imports only base packages [stats
> and graphics]) and has been around for a long time (archived versions on
> CRAN go back to 2003).

> Would it make sense to replace the call to SuppDists::rinvGauss with a
> corresponding call to statmod::rinvgauss ?  Would a patch be considered?

> Ben Bolker

I'd say "yes" & "yes".

"Base" code weekly depending on CRAN packages (apart from
formally 'Recommended' ones)  is somewhat sub-optimal in any
case, ((but possibly still the best thing, given reality
[maintenance efforts, copyrights, ...])),
but your proposal seems a  "uniformly not worse"  change
((and I have very much liked delving into parts of Gordon
  Smyth's textbook on GLMs as a really nice mixture / in-between
  of rigorous math and applied stats))

Martin Maechler
ETH Zurich and R Core

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel