> Florent Angly
> on Wed, 25 Jan 2017 16:31:45 +0100 writes:
> Hi all,
> The documentation for head() and tail() describes the behavior of
> these generic functions when n is strictly positive (n > 0) and
> strictly negative (n < 0). How these functions work when given
Last week, we've talked here about "xtabs(), factors and NAs",
-> https://stat.ethz.ch/pipermail/r-devel/2017-January/073621.html
In the mean time, I've spent several hours on the issue
and also committed changes to R-devel "in two iterations".
In the case there is a *Left* hand side part to xt
Dear developer list,
I want to submit the following problem that seems like a bug, as
confirmed by an other user [1], related to date-time parsing:
Here a simple script:
# that works:
as.numeric(as.POSIXlt(strptime('2016-03-27 01:05:50', format='%Y-%m-%d
%H:%M:%S')))
# that not (it returns NA):
Hi,
You don't give the time zone but this is probably due to the clock jumping by
one hour when switching to summer time. In UK this happens at 1am and on that
day there is no such thing as 01:05, etc., see eg
https://www.timeanddate.com/time/change/uk/london
In your time zone this probably ha
It would be cool if the default for tapply's init.value could be
FUN(X[0]), so it would be 0 for FUN=sum or FUN=length, TRUE for
FUN=all, -Inf for FUN=max, etc. But that would take time and would
break code for which FUN did not work on length-0 objects.
Bill Dunlap
TIBCO Software
wdunlap tibco.co
In addition, signed zeroes only exist for floating point numbers - the
bit patterns for as.integer(0) and as.integer(-0) are identical.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Thu, Jan 26, 2017 at 1:53 AM, Martin Maechler
wrote:
>> Florent Angly
>> on Wed, 25 Jan 2017 16:31:
On a related note, the storage mode should try to match ans[[1]] (or
unlist:ed and) when allocating 'ansmat' to avoid coercion and hence a full
copy.
Henrik
On Jan 26, 2017 07:50, "William Dunlap via R-devel"
wrote:
It would be cool if the default for tapply's init.value could be
FUN(X[0]), so
Thank you Georg!
It definitely resolves the problem!
Adding the correct time zone (tz='GMT') returns a valid number as my
data are in solar time.
rob
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.c
