Hello R-dev,
Yesterday, while I was testing the newly implemented function pmean in
package kit, I noticed a mismatch in the output of the below R expressions.
set.seed(123)
n=1e3L
idx=5
x=rnorm(n)
y=rnorm(n)
z=rnorm(n)
a=(x[idx]+y[idx]+z[idx])/3
b=mean(c(x[idx],y[idx],z[idx]))
a==b
# [1] FALSE
Expected, see FAQ 7.31.
You just can't trust == on FP operations. Notice also
> a2=(z[idx]+x[idx]+y[idx])/3
> a2==a
[1] FALSE
> a2==b
[1] TRUE
-pd
> On 20 May 2020, at 12:40 , Morgan Morgan wrote:
>
> Hello R-dev,
>
> Yesterday, while I was testing the newly implemented function pmean in
> p
Thanks for reporting this, it is a bug, now fixed in R-devel and
R-patched (PR#17800).
Best
Tomas
On 5/15/20 3:50 AM, William Dunlap via R-devel wrote:
Is it just my installation or does edit() (or fix(), etc.) in R-4.0.0
double all the backslashes when options(keep.source=TRUE)? E.g.,
opti
Hi Kurt,
Thank you for fixing quantile(). However, do you think c.factor() can
potentially break more functions? For example, with this new change,
classification from the partykit package using predict() comes back NA
because of this:
https://github.com/cran/partykit/blob/597245ef3dfc98411ce919b
> Trang Le writes:
> Hi Kurt,
> Thank you for fixing quantile(). However, do you think c.factor() can
> potentially break more functions? For example, with this new change,
> classification from the partykit package using predict() comes back NA because
> of this:
> https://github.com/cran/pa
On 5/14/20 8:34 PM, Jan Gorecki wrote:
Hi R developers,
I observed that system(timeout=) may still return exit code 0, when
killing the process due to timeout.
In src/unix/sys-unix.c there is
#define KILL_SIGNAL1 SIGINT
#define KILL_SIGNAL2 SIGTERM
#define KILL_SIGNAL3 SIGKILL
#define EMERGENC
Dear R Developers,
###
# Context:
###
When managing Search Path Conflicts (See:
https://developer.r-project.org/Blog/public/2019/03/19/managing-search-path-conflicts/index.html),
with:
options(conflicts.policy = "strict")
We get the following behaviour when loading a package (Eg: dplyr):
libra
> On Wednesday, May 20, 2020, 7:00:09 AM EDT, peter dalgaard
> wrote:
>
> Expected, see FAQ 7.31.
>
> You just can't trust == on FP operations. Notice also
Additionally, since you're implementing a "mean" function you are testing
against R's mean, you might want to consider that R uses a two-p
You can get what you are asking for now in R 4.0.0 with
globalCallingHandlers and using the packageConflictError object that
is signaled. This should get you started:
```
options(conflicts.policy = "strict")
packageConflictError
handle_conflicts <- function(e) {
cat(conditionMessage(e))
On Wed, May 20, 2020 at 11:10 AM brodie gaslam via R-devel
wrote:
>
> > On Wednesday, May 20, 2020, 7:00:09 AM EDT, peter dalgaard
> wrote:
> >
> > Expected, see FAQ 7.31.
> >
> > You just can't trust == on FP operations. Notice also
>
> Additionally, since you're implementing a "mean" function
> An IDE could provide a more sophisticated interface, like a dialog
> allowing separate choices for each conflict. But this is best left up
> to the IDE or the user.
An IDE (or other user interface) should not alter the behavior of R,
especially the installing/loading/attaching of packages.
Ther
Providing a way to more easily resolve situations that otherwise would
be errors is a reasonable thing for an IDE to do. I would prefer is
such things were optional and off by default, but other way not.
If an IDE does this and you don't approve then you don't have to use
it.
Best,
luke
On Wed
On Thu, May 21, 2020 at 10:37 AM wrote:
> Providing a way to more easily resolve situations that otherwise would
> be errors is a reasonable thing for an IDE to do.
In principle, yes.
However, I note that the word "easily" could mean different things to
different people.
Certain IDE* (not naming
13 matches
Mail list logo
