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
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
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
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
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
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
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
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)
One of the very best fortunes nominations!
[...]
I suspect something like
if (stats::runif(1) > 0.5) export(someFunction)
would work too, for a particularly frustrating experience for your
users. It would mean half the installs export the function, and half don't.
Duncan Murdoch
Returning to the original question, if it's helpful: I'd like to know what
constraints led to considering an export only available on Windows, and see
if we can suggest some other designs. It'd be good to keep the user's
mental model abstracted from the platform they're working on. There are
often
On Fri, 24 Sep 2021 21:48:12 +0200
Jan van der Laan wrote:
> my tests run fine when run with R CMD check, but not with R CMD check
> --as-cran
<...>
> pandoc then calls R again with a script which is part of the package
Part of R CMD check --as-cran is placing fake R and Rscript executables
You are correct, it most definitely is a convoluted way to identify a path,
but this is one incredibly specific scenario. The case I'm talking about
only occurs when running a script in Rgui for Windows using Ctrl+R (or
pasting into the R Console) to run a piece of code. Scenarios such as
running
Hello,
I'm updating my package 'this.path' which is supposed to retrieve the
absolute path of the executing script when called. It's similar to 'here',
except that 'here' constructs paths relative to a project directory,
whereas 'this.path' constructs paths relative to script directories. I was
What if you are on Windows but running R at the command prompt, or via cygwin,
or in the console window of RStudio?
This seems unstable to me.
On September 30, 2021 11:52:16 AM PDT, Andrew Simmons
wrote:
>Hello,
>
>
>I'm updating my package 'this.path' which is supposed to retrieve the
On 30/09/2021 5:21 p.m., Jeff Newmiller wrote:
What if you are on Windows but running R at the command prompt, or via cygwin,
or in the console window of RStudio?
This seems unstable to me.
Sorry, too much context missing. What's unstable?
Duncan Murdoch
On September 30, 2021 11:52:16
I don't have cigwin installed but from the command window, the terminal
that Git installs, RGui, and RStudio they all return "windows" for the
.Platform$OS.type for me.
On Thu, Sep 30, 2021 at 2:38 PM Duncan Murdoch
wrote:
> On 30/09/2021 5:21 p.m., Jeff Newmiller wrote:
> > What if you are on
Expecting a window handle relevant to the script to exist for the purpose of
identifying a path seem to be orthogonal problems to me. But Andrew has
indicated offlist that he has alternate code for other cases only uses this
technique when appropriate.
I still feel this is too convoluted as a
Hi Zheng,
The builders all have Python installed, but how you access it depends on the
OS: for Mac and Linux, use `python3` and for Windows, use `python`. The issue
we see in Rbowtie2's build error is related to the lines
432 invisible(.callbinary(lang = "python",
433
18 matches
Mail list logo
