Mildly related (?) to this discussion, if you happen to be in a situation
where you know something is a C NAN, but need to check if its a proper R
NA, the R_IsNA function is surprisingly (to me, at least) expensive to do
in a tight loop because it calls the (again, surprisingly expensive to me)
isn
On Thu, 30 Sep 2021, brodie gaslam via R-devel wrote:
André,
I'm not an R core member, but happen to have looked a little bit at this
issue myself. I've seen similar things on Skylake and Coffee Lake 2
(9700, one generation past your latest) too. I think it would make sense
to have some hand
Brodie Gaslam wrote:
> André,
> I'm not an R core member, but happen to have looked a little bit at this
> issue myself. I've seen similar things on Skylake and Coffee Lake 2
> (9700, one generation past your latest) too. I think it would make sense
> to have some handling of this, although I wo
Sorry for missing the issue on Bugzilla with Dirk's (better) proposal before
posting on the list. I agree adding the whole family (ceiling(), floor(),
trunc(x), and round ()) would be very useful (while it may be useful to provide
the enhanced trunc.Date in the meantime). I unfortunately don't h
Excuse the exceptional top-reply:
Note that a very related issue has been raised not so long ago
by Dirk (in CC) on R's Bugzilla :
trunc.Date should support months and years arguments as trunc.POSIXt does
https://bugs.r-project.org/show_bug.cgi?id=18099
which had some agreement (also with y
André,
I'm not an R core member, but happen to have looked a little bit at this
issue myself. I've seen similar things on Skylake and Coffee Lake 2
(9700, one generation past your latest) too. I think it would make sense
to have some handling of this, although I would want to show the trade-of
About fractional days, trunc.Date2 actually seems to have no regression and to
be backward compatible compared to the original trunc.Date:
frac <- as.Date("2020-01-01") + 0.5
identical(trunc(frac), trunc.Date2(frac))
(I may still miss something since I do not understand how trunc.Date manage
fr
Dear R developers,
By default, R uses the "long double" data type to get extra precision for
intermediate computations, with a small performance tradeoff.
Unfortunately, on all Intel x86 computers I have ever seen, long doubles
(implemented in the x87 FPU) are extremely slow whenever a special
