On Fri, May 3, 2019 at 4:34 PM Tomas Kalibera wrote:
>
> On 5/3/19 3:04 PM, Gergely Daróczi wrote:
> > On Thu, May 2, 2019 at 7:24 PM Tomas Kalibera
> > wrote:
> >> On 5/1/19 12:25 AM, Gergely Daróczi wrote:
> >>> Dear All,
> >>>
> >>> I'm running into issues with calling mccollect on a list con
Hi Tomas,
thanks a lot for your analysis. I have created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
for this, and put you in CC (if your e-mail address
for GCC bugzilla is still current).
Regards
Thomas
__
R-devel@r-project.org maili
On 5/3/19 3:04 PM, Gergely Daróczi wrote:
On Thu, May 2, 2019 at 7:24 PM Tomas Kalibera wrote:
On 5/1/19 12:25 AM, Gergely Daróczi wrote:
Dear All,
I'm running into issues with calling mccollect on a list containing NULL
using R 3.6 (this used to work in 3.5.3):
jobs <- lapply(
list(NU
Dear All,
Since upgrading to 3.6.0, I've been getting a strange error messages
from the child process when using mcparallel/mccollect. Before filing a report
in the Bugzilla, I want to figure out whether I had been doing something wrong
all this time and R 3.6.0 has exposed it, or whether someth
On Thu, May 2, 2019 at 7:24 PM Tomas Kalibera wrote:
>
> On 5/1/19 12:25 AM, Gergely Daróczi wrote:
> > Dear All,
> >
> > I'm running into issues with calling mccollect on a list containing NULL
> > using R 3.6 (this used to work in 3.5.3):
> >
> > jobs <- lapply(
> > list(NULL, 'foobar'),
>
It looks as though this happens when calculating numerical gradients: x
is reduced by eps, and fn is called; then x is increased by eps, and fn
is called again. No check is made that x has other references after the
first call to fn.
I'll put together a patch if nobody else gets there first.
Yes, I think you are right. I was at first confused by the fact that after the
optim() call,
> environment(fn)$xx
[1] 10
> environment(fn)$ret
[1] 100.02
so not 9.999, but this could come from x being assigned the final value without
calling fn.
-pd
> On 3 May 2019, at 11:58 , Duncan Murdoch
Your results below make it look like a bug in optim(): it is not
duplicating a value when it should, so changes to x affect xx as well.
Duncan Murdoch
On 03/05/2019 4:41 a.m., Serguei Sokol wrote:
On 03/05/2019 10:31, Serguei Sokol wrote:
On 02/05/2019 21:35, Florian Gerber wrote:
Dear all,
Dear Thomas,
thank you for your input. I've debugged one of the packages and I
confirm that the breakage is related to passing of strings from C to
Fortran. Indeed, BLAS and LAPACK define a large number of subroutines
that take one or more explicit single-character strings as arguments.
Other
On 03/05/2019 10:31, Serguei Sokol wrote:
On 02/05/2019 21:35, Florian Gerber wrote:
Dear all,
when using optim() for a function that uses the parent environment, I
see the following unexpected behavior:
makeFn <- function(){
xx <- ret <- NA
fn <- function(x){
if(!is.na(xx) &
On 02/05/2019 21:35, Florian Gerber wrote:
Dear all,
when using optim() for a function that uses the parent environment, I
see the following unexpected behavior:
makeFn <- function(){
xx <- ret <- NA
fn <- function(x){
if(!is.na(xx) && x==xx){
cat("x=", xx, ", ret=
Dear all,
when using optim() for a function that uses the parent environment, I
see the following unexpected behavior:
makeFn <- function(){
xx <- ret <- NA
fn <- function(x){
if(!is.na(xx) && x==xx){
cat("x=", xx, ", ret=", ret, " (memory)", fill=TRUE, sep="")
12 matches
Mail list logo
