> William Dunlap via R-devel
> on Sun, 29 Jul 2018 10:06:40 -0700 writes:
> Bugzilla issue 16101 describes another
> first-list-name-printed-differently oddity with
> the Windows GUI version of R:
Indeed:
1) "first-list-name-pri
> David Hugh-Jones
> on Mon, 30 Jul 2018 05:33:19 +0100 writes:
> Forgive me if this has been asked many times before, but I
> couldn't find anything on the mailing lists.
> I'd expect apply(m, 1, foo) not to call `foo` if m is a
> matrix with zero rows. In fact:
Hi Martin,
Fair enough for R functions in general. But the behaviour of apply violates
the expectation that apply(m, 1, fun) calls fun n times when m has n rows.
That seems pretty basic.
Also, I understand from your argument why it makes sense to call apply and
return a special result (presumably
On 30 July 2018 at 05:35, David Hugh-Jones wrote:
| Hi guys,
|
| Perhaps someone here can help.
|
| I am trying to build versions of R 1 for the rcheology package (just
| arrived on CRAN).
|
| For R prior to 1.5.0, I cannot configure support for tcl-tk.
|
| I am building on Debian Woody (prov
> David Hugh-Jones
> on Mon, 30 Jul 2018 10:12:24 +0100 writes:
> Hi Martin, Fair enough for R functions in general. But the
> behaviour of apply violates the expectation that apply(m,
> 1, fun) calls fun n times when m has n rows. That seems
> pretty basic.
Well, th
Hi David,
Besides Martins point, there is also the issue that for a lot of cases you
would still like to have the right class returned.
Right now these are returns:
> apply(matrix(NA_integer_,0,5), 1, class)
character(0)
> apply(matrix(NA_integer_,0,5), 1, identit
Try pmap and related functions in purrr:
pmap(as.data.frame(m), ~ { cat("Called...\n"); print(c(...)) })
## list()
On Mon, Jul 30, 2018 at 12:33 AM, David Hugh-Jones
wrote:
> Forgive me if this has been asked many times before, but I couldn't find
> anything on the mailing lists.
>
> I'd exp
Interesting discussion. I'm not wholly convinced by Martin's and Emil's
arguments. The behaviour seems to violate an obvious expectation (fun is
called once per row) to satisfy a subtle one (result has a guaranteed
dimension and type).
In any case, here's a suggested chunk of rd to go at the end o
Thanks for the tip. That could be a huge timesaver. But it lists only a
single package for versions 0.90.1-2 ... how does that work?
David
On Mon, 30 Jul 2018 at 12:27, Dirk Eddelbuettel wrote:
>
> On 30 July 2018 at 05:35, David Hugh-Jones wrote:
> | Hi guys,
> |
> | Perhaps someone here can h
On 30 July 2018 at 16:26, David Hugh-Jones wrote:
| Thanks for the tip. That could be a huge timesaver. But it lists only a
| single package for versions 0.90.1-2 ... how does that work?
The lookip is source or binary-package based. Eg here are three binaries
built from source 'r-base':
http:
Hi,
I have run into a problem with parseData from the utils package. When
an assignment is done with = instead of <-, the information provided by
parseData does not include an entry for the assignment.
For this input, stored in file "BadPosition.R":
y <- 5
foo = 7
And running this code:
par
In looking at rootfinding for the histoRicalg project (see
gitlab.com/nashjc/histoRicalg),
I thought I would check how uniroot() solves some problems. The following short
example
ff <- function(x){ exp(0.5*x) - 2 }
ff(2)
ff(1)
uniroot(ff, 0, 10)
uniroot(ff, c(0, 10), trace=1)
uniroot(ff, c(0, 10
Dear R Developers,
I would like to propose a simple optimization for print.data.frame
base function:
To add: x <- as.data.frame(head(x, n = options("max.print")))
This would prevent that, if for example, we have a 10GB data.frame
(e.g.: Instead of a data.table), and we accidentally print it, the
I polished a little bit more the function:
* Used: getOption("max.print")
* Added comment at the end: cat('[ reached getOption("max.print") --
omitted ', omitted,' rows ]')
function (x, ..., digits = NULL, quote = FALSE, right = TRUE,
row.names = TRUE)
{
n <- length(row.names(x))
On Mon, Jul 30, 2018 at 6:08 PM, Martin Maechler
wrote:
>> David Hugh-Jones
>> on Mon, 30 Jul 2018 10:12:24 +0100 writes:
>
> > Hi Martin, Fair enough for R functions in general. But the
> > behaviour of apply violates the expectation that apply(m,
> > 1, fun) calls fun n t
15 matches
Mail list logo
