On 02/11/2016 07:02 AM, Michael Lawrence wrote:
Changing the vapply() behavior makes sense in principle.
Sorry to disagree, Changing the behavior of sapply() so we end up
with consistent treatment of USE.NAMES across sapply(), vapply(),
and mapply() sounds much better *in principle*.
I underst
The two CRAN packages I'm (co)authoring, dplR and sisal, would both be
OK with the change. (Cc'ing to the Maintainer of dplR and my other email
address)
- Mikko
On 11.02.2016 17:02, Michael Lawrence wrote:
> Changing the vapply() behavior makes sense in principle. I analyzed
> the CRAN code base
Changing the vapply() behavior makes sense in principle. I analyzed
the CRAN code base using the R parser and found 143 instances of
calling vapply with USE.NAMES=FALSE. These would need to be inspected
to understand the consequences of the change.
For reference:
/AzureML/R/datasets.R:226
/BBmisc/
> Hervé Pagès
> on Mon, 8 Feb 2016 10:48:50 -0800 writes:
> Hi,
> Both vapply() and sapply() support the 'USE.NAMES' argument. According
> to the man page:
> USE.NAMES: logical; if ‘TRUE’ and if ‘X’ is character, use ‘X’ as
>‘names’ for the result unless it ha
Hi,
Both vapply() and sapply() support the 'USE.NAMES' argument. According
to the man page:
USE.NAMES: logical; if ‘TRUE’ and if ‘X’ is character, use ‘X’ as
‘names’ for the result unless it had names already.
But if 'X' has names already and 'USE.NAMES' is FALSE, it's not clear
w
