[Rd] Precision of function mean,bug?

[Morgan Morgan]

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

For idx= 1, 2, 3, 4 the last line is equal to TRUE. For 5, 6 and many
others the difference is small but still.
Is that expected or is it a bug?

Thank you
Best Regards
Morgan Jacob

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Precision of function mean,bug?

[peter dalgaard]

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
> 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
> 
> For idx= 1, 2, 3, 4 the last line is equal to TRUE. For 5, 6 and many
> others the difference is small but still.
> Is that expected or is it a bug?
> 
> Thank you
> Best Regards
> Morgan Jacob
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] edit() doubles backslashes when keep.source=TRUE

[Tomas Kalibera]

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.,


options(keep.source=TRUE)
f <- function(x) { cat("\t", x, "\n", sep="") }
edit(f) # exit the editor without making any changes

The editor (vi or notepad) shows doubled backslashes
 function(x) { cat("\\t", x, "\\n", sep="") }
as does the return value of edit().

If I set options(keep.source=FALSE) before defining 'f' or remove t's
'srcref' attribute then the backslashes are left alone.

Bill Dunlap
TIBCO Software
wdunlap tibco.com

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] quantile() type 1 for some ordered factors in R-devel

[Trang Le]

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/597245ef3dfc98411ce919b74c68ba565f077c47/R/party.R#L500

I understand that most of the fixes will probably be simple with
as.numeric() or as.integer(), but tracing down these breaks can be
time-consuming .
What about a warning whenever code that would trigger c.factor() is called?
This way users are given a chance to update packages and code.

Thanks,
Trang

On Wed, May 20, 2020 at 1:53 AM Kurt Hornik  wrote:

> > Tobias Rockel writes:
>
> Thanks for spotting this, and also to Hadley for reporting to me
> directly.
>
> Fixed now with c78501.
>
> Best
> -k
>
> > Hi,
> > In R-devel (2020-05-17 r78478) quantile() type 1 seems to behave a little
> > bit strange for some ordered factors:
> > quantile(factor(1:3, ordered = TRUE), 0.5, type = 1)
> > returns “2” as expected. But
> > quantile(factor(2:4, ordered = TRUE), 0.5, type = 1)
> > returns “4” and
> > quantile(factor(3:5, ordered = TRUE), 0.5, type = 1)
> > returns “NA”. Furthermore, the function returns “NA” for calls like
> > quantile(factor(c("a", "b", "c"), ordered = TRUE), 0.5, type = 1)
>
> > In R 4.0.0 everything seems fine (return values “2”, “3”, “4”, “b”). If
> the
> > vectors are treated as numeric, everything seems to work fine in R-devel,
> > too. For example
> > quantile(3:5, 0.5, type = 1)
> > returns “4” in R-devel and R 4.0.0.
>
> > Best regards,
> > Tobias Rockel
>
> >   [[alternative HTML version deleted]]
>
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] quantile() type 1 for some ordered factors in R-devel

[Kurt Hornik]

> 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/partykit/blob/597245ef3dfc98411ce919b74c68ba565f077c47/R/party.R#L500

All issues in the CRAN checks were identified and reported, and should
be fixed shortly.

Best
-k

> I understand that most of the fixes will probably be simple with as.numeric()
> or as.integer(), but tracing down these breaks can be time-consuming. What
> about a warning whenever code that would trigger c.factor() is called? This
> way users are given a chance to update packages and code.

> Thanks,
> Trang

> On Wed, May 20, 2020 at 1:53 AM Kurt Hornik  wrote:

>> Tobias Rockel writes:
   
> Thanks for spotting this, and also to Hadley for reporting to me
> directly.
   
> Fixed now with c78501.
   
> Best
> -k
   
>> Hi,
>> In R-devel (2020-05-17 r78478) quantile() type 1 seems to behave a
> little
>> bit strange for some ordered factors:
>> quantile(factor(1:3, ordered = TRUE), 0.5, type = 1)
>> returns “2” as expected. But
>> quantile(factor(2:4, ordered = TRUE), 0.5, type = 1)
>> returns “4” and
>> quantile(factor(3:5, ordered = TRUE), 0.5, type = 1)
>> returns “NA”. Furthermore, the function returns “NA” for calls like
>> quantile(factor(c("a", "b", "c"), ordered = TRUE), 0.5, type = 1)
   
>> In R 4.0.0 everything seems fine (return values “2”, “3”, “4”, “b”). If
> the
>> vectors are treated as numeric, everything seems to work fine in
> R-devel,
>> too. For example
>> quantile(3:5, 0.5, type = 1)
>> returns “4” in R-devel and R 4.0.0.
   
>> Best regards,
>> Tobias Rockel
   
>>        [[alternative HTML version deleted]]
   
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
   
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] system(timeout=) may timeout with 0 exit code

[Tomas Kalibera]

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 EMERGENCY_TIMEOUT 20

After little bit of debugging I observed that total time of system
call is provided timeout value + 20s. That means EMERGENCY_TIMEOUT 20
kicked in, adding 20 seconds.

I don't have a reproducible example, but following code, and output
file below should be enough to ensure that there is a problem there
(exit code 0 despite timeout).


Thanks for the report, but I can't tell from the report what the problem 
is, I would really need a reproducible example, and ideally one that 
uses only minimal/trivial child processes. I tried with such examples on 
my system, but they did not trigger the problem.


In this example, SIGINT succeeds in terminating the child process

> system.time(print(system("while /bin/true ; do /bin/true ; done", 
timeout=1)))

[1] 124
   user  system elapsed
  0.712   0.316   1.002

In this example, SIGTERM succeeds (after additional 20s)

> system.time(print(system("trap '' INT ; while /bin/true ; do 
/bin/true ; done", timeout=1)))

[1] 124
   user  system elapsed
 14.813   6.641  21.002

In this example, SIGKILL succeeds (after additional 40s)

> system.time(print(system("trap '' INT TERM ; while /bin/true ; do 
/bin/true ; done", timeout=1)))

[1] 124
   user  system elapsed
 29.075  12.918  41.002

In these examples, the execution time and the exit status is as 
documented in ?system.


Best
Tomas



warn = NULL
p = proc.time()[[3L]]
tryCatch(
   ret <- system(cmd, timeout=timeout_s),
   warning = function(w) {
 warn <<- w[["message"]]
   }
)
if (length(warn) && ret==0L)
   cat(sprintf("command '%s' timed out(?) but still exited with 0 code,
timeout %ss, took %ss, warning '%s'\n",
   cmd, timeout_s, proc.time()[[3L]]-p, warn),
file="timeout-exit-codes.out", append=TRUE)

And the content of timeout-exit-codes.out:

command '/bin/bash -c "./_launcher/solution.R > log.out 2> log.err"'
timed out(?) but still exited with 0 code, timeout 7200s, took
7220.005s, warning '/bin/bash -c "./_launcher/solution.R > log.out 2>
log.err"' timed out after 7200s'

Thank you,
Jan Gorecki

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Feature Request: User Prompt + Message First Execution when "Managing Search Path Conflicts"

[Juan Telleria Ruiz de Aguirre]

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):

library(dplyr)
## Error: Conflicts attaching package ‘dplyr’:
##
## The following objects are masked from ‘package:stats’:
##
## filter, lag
##
## The following objects are masked from ‘package:base’:
##
## intersect, setdiff, setequal, union

So we would have to solve the conflict by writing:

library(dplyr,
mask.ok = c("filter", "lag",
"intersect", "setdiff", "setequal",
"union"))

So my feature request proposals:

###
# Feature Request 1: Interactive Session
###

Would it be possible to raise an input prompt, which asks user for an
action to be taken as regards conflicts?

This would make the package loading process more dynamic when being
loaded for first time in an interactive session (Eg: R Notebook). An
example:

The first time the package is loaded:

options(conflicts.policy = "strict", conflicts.policy.ask = TRUE)

library(dplyr)

Executes iteratively the code, in order to ask the user for action
(See toy example):

opt <- readline(prompt="1: mask.ok; 2: exclude. Choose: ")

if (opt == "1"){

  txt <- sprintf(
fmt = "conflictRules(pkg = '%s' , mask.ok = '%s')",
"package.name",
"variable.name"
  )

  eval(parse(text = txt))

  message(txt)

} else if(opt == "2"){

  txt <- sprintf(
fmt = "conflictRules(pkg = '%s' , exclude = '%s')",
"package.name",
"variable.name"
  )

  eval(parse(text = txt))

  message(txt)

}

And afterwards, a message is printed with the selected
"conflictRules()" Configuration for the dynamic setup.

The user will only have to put the printed pre-configured
"conflictRules()" setup into his code, and when re-executing, the
input prompt asking for action will not be raised back again.

Such behaviour is similar in spirit to how 'conflicted' R package
works, which prints for example, for dplyr::filter :

Error: [conflicted] `filter` found in 2 packages.
Either pick the one you want with `::`
* dplyr::filter
* stats::filter
Or declare a preference with `conflict_prefer()`
* conflict_prefer("filter", "dplyr")
* conflict_prefer("filter", "stats")

Where the user will only have to copy "conflict_prefer("filter",
"dplyr")" and paste it into his script. The difference, is that with:
options(conflicts.policy = "strict", conflicts.policy.ask = TRUE),
such message is printed at package load.

I would put the required code within the library() function with the
following conditional:
...
if (length(conflicts)) {
   if(getOption("conflicts.policy.ask") == TRUE){
  ...
   }
}
...

###
# Feature Request 2: Source Execution
###

Another alternative, which could apply when executing the .R file from
source, would be to suggest the user a default conflictRules() setup:

options(conflicts.policy = "strict")
library(dplyr)

# Error: Conflicts attaching package ‘dplyr’:
#
# The following objects are masked from ‘package:stats’:
#
# filter, lag
#
# The following objects are masked from ‘package:base’:
#
# intersect, setdiff, setequal, union
#
# Declare preference with `conflictRules()` before loading:
# * conflictRules("dplyr", mask.ok = list(stats = TRUE, base = TRUE))
# * conflictRules("dplyr", mask.ok = list(stats = c("filter",
"lag"), base = c("intersect", "setdiff", "setequal", "union")))
# * conflictRules("dplyr", exclude = c("filter", "lag",
"intersect", "setdiff", "setequal", "union"))

In this case, the error message would have to be extended with
sensible suggested defaults.

Thanks,
Juan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Precision of function mean,bug?

[brodie gaslam via R-devel]

 > 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-pass
calculation[1] to reduce floating point precision error.

Best,

Brodie.

[1] https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/summary.c#L482

> > 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
> > 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
> >
> > For idx= 1, 2, 3, 4 the last line is equal to TRUE. For 5, 6 and many
> > others the difference is small but still.
> > Is that expected or is it a bug?

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [External] Feature Request: User Prompt + Message First Execution when "Managing Search Path Conflicts"

[luke-tierney]

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))
opt <- readline(prompt="1: mask.ok; 2: exclude. Choose: ")
if (opt == "1")
conflictRules(e$package, mask.ok = as.character(unlist(e$conflicts)))
else if (opt == "2")
conflictRules(e$package, exclude = as.character(unlist(e$conflicts)))
stop("unresolved conflicts") ## ideal invode a restart here
}

globalCallingHandlers(packageConflictError = handle_conflicts)

library(dplyr)
```

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.

The one addition to library that might be worth considering is to
provide a restart for the handler to invoke.

Best,

luke

On Wed, 20 May 2020, Juan Telleria Ruiz de Aguirre wrote:


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):

library(dplyr)
## Error: Conflicts attaching package ‘dplyr’:
##
## The following objects are masked from ‘package:stats’:
##
## filter, lag
##
## The following objects are masked from ‘package:base’:
##
## intersect, setdiff, setequal, union

So we would have to solve the conflict by writing:

library(dplyr,
   mask.ok = c("filter", "lag",
   "intersect", "setdiff", "setequal",
   "union"))

So my feature request proposals:

###
# Feature Request 1: Interactive Session
###

Would it be possible to raise an input prompt, which asks user for an
action to be taken as regards conflicts?

This would make the package loading process more dynamic when being
loaded for first time in an interactive session (Eg: R Notebook). An
example:

The first time the package is loaded:

options(conflicts.policy = "strict", conflicts.policy.ask = TRUE)

library(dplyr)

Executes iteratively the code, in order to ask the user for action
(See toy example):

opt <- readline(prompt="1: mask.ok; 2: exclude. Choose: ")

if (opt == "1"){

 txt <- sprintf(
   fmt = "conflictRules(pkg = '%s' , mask.ok = '%s')",
   "package.name",
   "variable.name"
 )

 eval(parse(text = txt))

 message(txt)

} else if(opt == "2"){

 txt <- sprintf(
   fmt = "conflictRules(pkg = '%s' , exclude = '%s')",
   "package.name",
   "variable.name"
 )

 eval(parse(text = txt))

 message(txt)

}

And afterwards, a message is printed with the selected
"conflictRules()" Configuration for the dynamic setup.

The user will only have to put the printed pre-configured
"conflictRules()" setup into his code, and when re-executing, the
input prompt asking for action will not be raised back again.

Such behaviour is similar in spirit to how 'conflicted' R package
works, which prints for example, for dplyr::filter :

Error: [conflicted] `filter` found in 2 packages.
Either pick the one you want with `::`
* dplyr::filter
* stats::filter
Or declare a preference with `conflict_prefer()`
* conflict_prefer("filter", "dplyr")
* conflict_prefer("filter", "stats")

Where the user will only have to copy "conflict_prefer("filter",
"dplyr")" and paste it into his script. The difference, is that with:
options(conflicts.policy = "strict", conflicts.policy.ask = TRUE),
such message is printed at package load.

I would put the required code within the library() function with the
following conditional:
...
if (length(conflicts)) {
  if(getOption("conflicts.policy.ask") == TRUE){
 ...
  }
}
...

###
# Feature Request 2: Source Execution
###

Another alternative, which could apply when executing the .R file from
source, would be to suggest the user a default conflictRules() setup:

options(conflicts.policy = "strict")
library(dplyr)

# Error: Conflicts attaching package ‘dplyr’:
#
# The following objects are masked from ‘package:stats’:
#
# filter, lag
#
# The following objects are masked from ‘package:base’:
#
# intersect, setdiff, setequal, union
#
# Declare preference with `conflictRules()` before loading:
# * conflictRules("dplyr", mask.ok = list(stats = TRUE, base = TRUE))
# * conflictRules("dplyr", mask.ok = list(stats = c("filter",
"lag"), base = c("intersect", "setdiff", "setequal", "union")))
# * conflictRules("dplyr", exclude = c("filter", "lag",
"intersect", "setdiff", "setequal", "union"))

In this case, the error message would have to be extended with
sensible suggested defaults.

Thanks,
Juan

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Scie

Re: [Rd] Precision of function mean,bug?

[Henrik Bengtsson]

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 you are testing
> against R's mean, you might want to consider that R uses a two-pass
> calculation[1] to reduce floating point precision error.

This one is important.

FWIW, matrixStats::mean2() provides argument refine=TRUE/FALSE to
calculate mean with and without this two-pass calculation;

> a <- c(x[idx],y[idx],z[idx]) / 3
> b <- mean(c(x[idx],y[idx],z[idx]))
> b == a
[1] FALSE
> b - a
[1] 2.220446e-16

> c <- matrixStats::mean2(c(x[idx],y[idx],z[idx]))  ## default to refine=TRUE
> b == c
[1] TRUE
> b - c
[1] 0

> d <- matrixStats::mean2(c(x[idx],y[idx],z[idx]), refine=FALSE)
> a == d
[1] TRUE
> a - d
[1] 0
> c == d
[1] FALSE
> c - d
[1] 2.220446e-16

Not surprisingly, the two-pass higher-precision version (refine=TRUE)
takes roughly twice as long as the one-pass quick version
(refine=FALSE).

/Henrik

>
> Best,
>
> Brodie.
>
> [1] https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/summary.c#L482
>
> > > 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
> > > 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
> > >
> > > For idx= 1, 2, 3, 4 the last line is equal to TRUE. For 5, 6 and many
> > > others the difference is small but still.
> > > Is that expected or is it a bug?
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [External] Feature Request: User Prompt + Message First Execution when "Managing Search Path Conflicts"

[Abby Spurdle]

> 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.

There are some possible exceptions:
(1) The global option for width.
(2) Output that would normally appear in a separate window.
(3) Maybe others...

But only as non-defaults, with consent from the user.
Also, while exception (2) may have an intuitive appeal, it's risky business...

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [External] Feature Request: User Prompt + Message First Execution when "Managing Search Path Conflicts"

[luke-tierney]

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, 20 May 2020, Abby Spurdle wrote:


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.

There are some possible exceptions:
(1) The global option for width.
(2) Output that would normally appear in a separate window.
(3) Maybe others...

But only as non-defaults, with consent from the user.
Also, while exception (2) may have an intuitive appeal, it's risky business...



--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [External] Feature Request: User Prompt + Message First Execution when "Managing Search Path Conflicts"

[Abby Spurdle]

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 any names, and not distinguishing between
singular/plural), introduce bugs and other problems, by altering R's
behavior.

Also, if they absolutely must change things, perhaps the first thing
they should change is the error messages:

I'm sorry, this program didn't work.
It could be R's fault, but probably is the IDE's fault.
Please do NOT post a message on R-help saying:
Why did R crash?
Without first running your code via a terminal.

> I would prefer is
> such things were optional and off by default, but other way not.

That's good to hear.

> If an IDE does this and you don't approve then you don't have to use
> it.

Yes.
And please let statistics and data science students know that.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel