Re: [Rd] Bug in nlm()

2017-03-08 Thread Martin Maechler 
   {This was sent to me, MM, only, but for completeness should
have gone back to R-devel.

Further: I now *have* added Marie B to the members'of "R bugzilla"
-- M.Maechler}


I had already read the R bug reporting guide and I'm sure it is a bug.
The bug occurs when the user provides not only the analytic gradient but also 
the analytic Hessian of the objective function. In that case, the algorithm 
does not converge due to an erroneous implementation of the modified Cholesky 
decomposition of the Hessian matrix. It is actually a bug in the C-code called 
by nlm(), therefore it is hard to show that the non-convergence of the 
algorithm is really due to this bug with only a MRE.
However, a short example (optimizing the Rosenbrock banana valley function with 
and without analytic Hessian) is:

fg <- function(x){  
  gr <- function(x1, x2) c(-400*x1*(x2 - x1*x1)-2*(1-x1), 200*(x2 - x1*x1)) 
  x1 <- x[1]; x2 <- x[2]
  res<- 100*(x2 - x1*x1)^2 + (1-x1)^2 
  attr(res, "gradient") <- gr(x1, x2)
  return(res)
} 
nlm.fg <- nlm(fg, c(-1.2, 1))

fgh <- function(x){ 
  gr <- function(x1, x2) c(-400*x1*(x2 - x1*x1) - 2*(1-x1), 200*(x2 - x1*x1)) 
  h <- function(x1, x2){
a11 <- 2 - 400*x2 + 1200*x1*x1
a21 <- -400*x1 
matrix(c(a11, a21, a21, 200), 2, 2)
  } 
  x1 <- x[1];  x2 <- x[2];  res<- 100*(x2 - x1*x1)^2 + (1-x1)^2 
  attr(res, "gradient") <- gr(x1, x2)
  attr(res, "hessian") <- h(x1, x2) 
  return(res)
}
nlm.fgh <- nlm(fgh, c(-1.2,1))

I have almost finished a more detailed bug report, which I would like to submit.

Best,
Marie Boehnstedt

> Martin Maechler 
> on Fri, 3 Mar 2017 18:15:47 +0100 writes:

> Boehnstedt, Marie 
> on Fri, 3 Mar 2017 10:23:12 + writes:

>> Dear all, I have found a bug in nlm() and would like to
>> submit a report on this.  Since nlm() is in the
>> stats-package, which is maintained by the R Core team,
>> bug reports should be submitted to R's Bugzilla. However,
>> I'm not a member of Bugzilla. Could anyone be so kind to
>> add me to R's Bugzilla members or let me know to whom I
>> should send the bug report?

> Dear Marie,

> I can do this ... but are you really sure?  There is
> https://www.r-project.org/bugs.html which you should spend
> some time reading if you haven't already.

> I think you would post a MRE (Minimal Reproducible
> Example) here {or on stackoverflow or ...} if you'd follow
> what the 'R bugs' web page (above) recommends and only
> report a bug after some feedback from "the public".

> Of course, I could be wrong.. and happy if you explain /
> tell me why.

> Best, Martin Maechler

>> Thank you in advance.

>> Kind regards, Marie B�hnstedt


>> Marie B�hnstedt, MSc Research Scientist Max Planck
>> Institute for Demographic Research Konrad-Zuse-Str. 1,
>> 18057 Rostock, Germany
>> www.demogr.mpg.de

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

Re: [Rd] Bug in nlm()

2017-03-03 Thread Martin Maechler 
> Boehnstedt, Marie 
> on Fri, 3 Mar 2017 10:23:12 + writes:

> Dear all,
> I have found a bug in nlm() and would like to submit a report on this.
> Since nlm() is in the stats-package, which is maintained by the R Core 
team, bug reports should be submitted to R's Bugzilla. However, I'm not a 
member of Bugzilla. Could anyone be so kind to add me to R's Bugzilla members 
or let me know to whom I should send the bug report?

Dear Marie,

I can do this ... but  are you really sure?  There is
 https://www.r-project.org/bugs.html
which you should spend some time reading if you haven't already.

I think you would post a MRE (Minimal Reproducible Example) here
{or on stackoverflow or ...} if you'd follow what the 'R bugs' web
page (above) recommends and only report a bug after some
feedback from "the public".

Of course, I could be wrong.. and happy if you explain / tell me why.

Best,
Martin Maechler

> Thank you in advance.

> Kind regards,
> Marie B�hnstedt


> Marie B�hnstedt, MSc
> Research Scientist
> Max Planck Institute for Demographic Research
> Konrad-Zuse-Str. 1, 18057 Rostock, Germany
> www.demogr.mpg.de




> --
> This mail has been sent through the MPI for Demographic ...{{dropped:9}}


> --
> __
> 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] Bug in nlm()

2017-03-03 Thread Boehnstedt, Marie 
Dear all,

I have found a bug in nlm() and would like to submit a report on this.
Since nlm() is in the stats-package, which is maintained by the R Core team, 
bug reports should be submitted to R's Bugzilla. However, I'm not a member of 
Bugzilla. Could anyone be so kind to add me to R's Bugzilla members or let me 
know to whom I should send the bug report?
Thank you in advance.

Kind regards,
Marie B�hnstedt


Marie B�hnstedt, MSc
Research Scientist
Max Planck Institute for Demographic Research
Konrad-Zuse-Str. 1, 18057 Rostock, Germany
www.demogr.mpg.de




--
This mail has been sent through the MPI for Demographic ...{{dropped:9}}

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

Re: [Rd] Bug in nlm, found using sem; failure in several flavors (PR#13883)

2009-08-12 Thread Peter Dalgaard 

William Dunlap wrote:


Running his example under valgrind (a memory misuse checker on Linux)
does show it using memory it should not be using in the optimization C
code
around where it is copying the gradient vector.  The 


==10916== Invalid read of size 1
==10916==at 0x400686D: memcpy (mc_replace_strmem.c:406)
==10916==by 0x8072BC1: FT_store (optimize.c:319)
==10916==by 0x8072F92: fcn (optimize.c:408)


Looks like this does the trick (you do want to protect s because 
install() may allocate):


[...@titmouse2 R]$ svn diff
Index: src/main/optimize.c
===
--- src/main/optimize.c (revision 49168)
+++ src/main/optimize.c (working copy)
@@ -378,7 +378,7 @@
if (!R_FINITE(x[i])) error(_(non-finite value supplied by 'nlm'));
REAL(s)[i] = x[i];
 }
-s = eval(state-R_fcall, state-R_env);
+s = PROTECT(eval(state-R_fcall, state-R_env));
 switch(TYPEOF(s)) {
 case INTSXP:
if (length(s) != 1) goto badvalue;
@@ -400,13 +400,14 @@
goto badvalue;
 }
 if (state-have_gradient) {
-   g = REAL(coerceVector(getAttrib(s, install(gradient)), REALSXP));
+	g = REAL(PROTECT(coerceVector(getAttrib(s, install(gradient)), 
REALSXP)));

if (state-have_hessian) {
-   h = REAL(coerceVector(getAttrib(s, install(hessian)), REALSXP));
+	h = REAL(PROTECT(coerceVector(getAttrib(s, install(hessian)), 
REALSXP)));

}
 }
 FT_store(n, *f, x, g, h, state);
-return;
+UNPROTECT(1 + state-have_gradient + state-have_hessian);
+return;

  badvalue:
 error(_(invalid function value in 'nlm' optimizer));


--
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk)  FAX: (+45) 35327907

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

Re: [Rd] Bug in nlm, found using sem; failure in several flavors (PR#13883)

2009-08-10 Thread Ben Bolker 


   A wild guess, based on some recent non-deterministic behavior in
lme4: could this be driven by a bug in optimized linear algebra libraries
(BLAS/LAPACK)?  (Unfortunately, I'm not clear on how to check the versions
of BLAS/LAPACK being used and whether they are subject to bugs,
but perhaps someone else can comment ...)

   Ben Bolker



Adam D. I. Kramer-2 wrote:
 
   This message is in MIME format.  The first part should be readable text,
   while the remaining parts are likely unreadable without MIME-aware
 tools.
 
 --1660387551-150661043-1249684349=:2997
 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
 Content-Transfer-Encoding: QUOTED-PRINTABLE
 
 Hi Jeff,
 
  =09As mentioned in my message, I *did* replicate on another platform.=20
 One platform was running linux in a VM, the other running MacOSX, on two
 different physical machines.  The problem did not replicate on a PowerPC
 box, so if it is a bug with intel chips, I think it's also appropriate to
 report here given that the problem seems to cross the OS boundary.  I do
 no=
 t
 have access to a Windows machine.
 
  =09Also, I have spent a decent amount of time running memory testers on
 the first machine's memory, to ensure that physical memory is not a
 problem...the classic memcheck program finds no trouble.
 
  =09The CSV and .ram files both came through as base-64-encoded
 attachments, which you actually quoted back to me in your response,
 below...but in case your mail client can't read those and/or you are
 interested in this bug, I have pasted them at the end of this message
 (sinc=
 e
 they're quite small).
 
  =09And thanks for the shout-out for bacon. I bought this domain name in
 undergrad many years ago, and I must say, I've never regretted it!
 
 --Adam
 
 On Fri, 7 Aug 2009, Jeff Ryan wrote:
 
 Adam,

 It seems that your attachment didn't make it through.

 That aside, my experience with strange errors like those (random type
 not implemented ones) has been that you may be looking at a memory
 problem on you machine. Given that you can't replicate on another
 platform (and the .csv file didn't come through), I would think it
 wise to start there.

 My 2c.  And I love bacon too :)

 Jeff

 On Fri, Aug 7, 2009 at 1:10 PM, a...@ilovebacon.org wrote:
 =A0This message is in MIME format. =A0The first part should be readable
 =
 text,
 =A0while the remaining parts are likely unreadable without MIME-aware
 to=
 ols.

 --1660387551-1458482416-1249639718=3D:2997
 Content-Type: TEXT/PLAIN; CHARSET=3DUS-ASCII; FORMAT=3Dflowed
 Content-ID: pine.lnx.4.64.0908071039211.2...@parser.ilovebacon.org

 Hello,

 =A0 =A0 =A0 =A0There appears to be a bug in the nlm function, which I
 di=
 scovered
 when trying to run an SEM. =A0The SEM is not bizarre; the covariance
 mat=
 rix is
 solve-able and the eigenvalues are greater than zero, and I do not
 belie=
 ve
 the sem package per se to be the problem (as nlm keeps being the part
 =
 that
 fails, though I can't replicate this with other nlm tasks). =A0I
 apologi=
 ze if
 I have put too many much information in this message; I'm not a
 programm=
 er
 by trade so I don't really know what's going on here, which hampers my
 ability to write consise bug reports.

 Here is the code I use:

 library(sem)
 ice.S - read.csv(iceS.csv) # attached
 rownames(ice.S) - ice.S[,1]
 ice.S[,1] - NULL
 ice.S - as.matrix(ice.S)
 ice.ram - specify.model(ice.ram) # attached
 ice.N - 342
 ice.sem - sem(ram=3Dice.ram, S=3Dice.S, N=3Dice.N)

 ...at this point, any number of problems could occur. I have seen the
 following.

 1) Simple lack of convergence. (might be my model's fault.)
 2) Error in nlm(if (analytic.gradient) objective.2 else objective.1,
 sta=
 rt,
 :
 =A0 type 31 is unimplemented in 'type2char'
 3) =A0*** caught segfault ***
 address 0xc019c87b, cause 'memory not mapped'

 Traceback:
 =A01: nlm(if (analytic.gradient) objective.2 else objective.1, start,
 hessian =3D TRUE, iterlim =3D maxiter, print.level =3D if (debug) 2
 else=
  0,
 typsize =3D typsize, ...)
 =A02: sem.default(ram =3D ram, S =3D S, N =3D N, param.names =3D pars,
 v=
 ar.names =3D
 vars, =A0 =A0 fixed.x =3D fixed.x, debug =3D debug, ...)
 =A03: sem(ram =3D ram, S =3D S, N =3D N, param.names =3D pars,
 var.names=
  =3D vars,
 fixed.x =3D fixed.x, debug =3D debug, ...)
 =A04: sem.mod(ram =3D ice.ram, S =3D ice.S, N =3D ice.N)
 =A05: sem(ram =3D ice.ram, S =3D ice.S, N =3D ice.N)

 Possible actions:
 1: abort (with core dump, if enabled)
 2: normal R exit
 3: exit R without saving workspace
 4: exit R saving workspace
 Selection: 1
 aborting ...
 Segmentation fault
 swiss:data$

 (no core was dumped).

 Trying with debug mode provides other interesting errors:

 ice.sem - sem(ram=3Dice.ram, S=3Dice.S, N=3Dice.N, debug=3DTRUE)

 ...gets up to some iteration (not always 15), and then R dies
 ungraceful=
 ly,
 and exits to the shell:

 iteration =3D 15
 Step:
 =A0[1] =A01.253132e-02 =A01.183343e-02 -7.651342e-03 -2.490800e-03
 =A02.=

Re: [Rd] Bug in nlm, found using sem; failure in several flavors (PR#13883)

2009-08-10 Thread Peter Dalgaard 

William Dunlap wrote:
From: r-devel-boun...@r-project.org 
[mailto:r-devel-boun...@r-project.org] On Behalf Of Ben Bolker

Sent: Monday, August 10, 2009 12:52 PM
To: r-devel@r-project.org
Subject: Re: [Rd] Bug in nlm, found using sem; failure in 
several flavors (PR#13883)




   A wild guess, based on some recent non-deterministic behavior in
lme4: could this be driven by a bug in optimized linear 
algebra libraries
(BLAS/LAPACK)?  (Unfortunately, I'm not clear on how to check 
the versions

of BLAS/LAPACK being used and whether they are subject to bugs,
but perhaps someone else can comment ...)

   Ben Bolker



Running his example under valgrind (a memory misuse checker on Linux)
does show it using memory it should not be using in the optimization C
code
around where it is copying the gradient vector.  The 


==10916== Invalid read of size 1
==10916==at 0x400686D: memcpy (mc_replace_strmem.c:406)
==10916==by 0x8072BC1: FT_store (optimize.c:319)
==10916==by 0x8072F92: fcn (optimize.c:408)

...

Mmmm... This comes from this code inside fcn()

if (state-have_gradient) {
g = REAL(coerceVector(getAttrib(s, install(gradient)),
 REALSXP));
if (state-have_hessian) {
h = REAL(coerceVector(getAttrib(s, install(hessian)),
  REALSXP));
}
}
FT_store(n, *f, x, g, h, state);

I suppose that if the function being optimized returns a value that has 
a gradient attribute, then that is being used. It is coerced to 
double; but otherwise, no questions asked.


I wonder if it would not be a good idea to at least check that 
getAttrib() returns something of the right length.




--
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk)  FAX: (+45) 35327907

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

Re: [Rd] Bug in nlm, found using sem; failure in several flavors (PR#13881)

2009-08-08 Thread Adam D. I. Kramer 

Hi Jeff,

	As mentioned in my message, I *did* replicate on another platform. 
One platform was running linux in a VM, the other running MacOSX, on two

different physical machines.  The problem did not replicate on a PowerPC
box, so if it is a bug with intel chips, I think it's also appropriate to
report here given that the problem seems to cross the OS boundary.  I do not
have access to a Windows machine.

Also, I have spent a decent amount of time running memory testers on
the first machine's memory, to ensure that physical memory is not a
problem...the classic memcheck program finds no trouble.

The CSV and .ram files both came through as base-64-encoded
attachments, which you actually quoted back to me in your response,
below...but in case your mail client can't read those and/or you are
interested in this bug, I have pasted them at the end of this message (since
they're quite small).

And thanks for the shout-out for bacon. I bought this domain name in
undergrad many years ago, and I must say, I've never regretted it!

--Adam

On Fri, 7 Aug 2009, Jeff Ryan wrote:


Adam,

It seems that your attachment didn't make it through.

That aside, my experience with strange errors like those (random type
not implemented ones) has been that you may be looking at a memory
problem on you machine. Given that you can't replicate on another
platform (and the .csv file didn't come through), I would think it
wise to start there.

My 2c.  And I love bacon too :)

Jeff

On Fri, Aug 7, 2009 at 1:10 PM, a...@ilovebacon.org wrote:

 This message is in MIME format.  The first part should be readable text,
 while the remaining parts are likely unreadable without MIME-aware tools.

--1660387551-1458482416-1249639718=:2997
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed
Content-ID: pine.lnx.4.64.0908071039211.2...@parser.ilovebacon.org

Hello,

       There appears to be a bug in the nlm function, which I discovered
when trying to run an SEM.  The SEM is not bizarre; the covariance matrix is
solve-able and the eigenvalues are greater than zero, and I do not believe
the sem package per se to be the problem (as nlm keeps being the part that
fails, though I can't replicate this with other nlm tasks).  I apologize if
I have put too many much information in this message; I'm not a programmer
by trade so I don't really know what's going on here, which hampers my
ability to write consise bug reports.

Here is the code I use:

library(sem)
ice.S - read.csv(iceS.csv) # attached
rownames(ice.S) - ice.S[,1]
ice.S[,1] - NULL
ice.S - as.matrix(ice.S)
ice.ram - specify.model(ice.ram) # attached
ice.N - 342
ice.sem - sem(ram=ice.ram, S=ice.S, N=ice.N)

...at this point, any number of problems could occur. I have seen the
following.

1) Simple lack of convergence. (might be my model's fault.)
2) Error in nlm(if (analytic.gradient) objective.2 else objective.1, start,
:
  type 31 is unimplemented in 'type2char'
3)  *** caught segfault ***
address 0xc019c87b, cause 'memory not mapped'

Traceback:
 1: nlm(if (analytic.gradient) objective.2 else objective.1, start,
hessian = TRUE, iterlim = maxiter, print.level = if (debug) 2 else 0,
typsize = typsize, ...)
 2: sem.default(ram = ram, S = S, N = N, param.names = pars, var.names =
vars,     fixed.x = fixed.x, debug = debug, ...)
 3: sem(ram = ram, S = S, N = N, param.names = pars, var.names = vars,
fixed.x = fixed.x, debug = debug, ...)
 4: sem.mod(ram = ice.ram, S = ice.S, N = ice.N)
 5: sem(ram = ice.ram, S = ice.S, N = ice.N)

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 1
aborting ...
Segmentation fault
swiss:data$

(no core was dumped).

Trying with debug mode provides other interesting errors:


ice.sem - sem(ram=ice.ram, S=ice.S, N=ice.N, debug=TRUE)


...gets up to some iteration (not always 15), and then R dies ungracefully,
and exits to the shell:

iteration = 15
Step:
 [1]  1.253132e-02  1.183343e-02 -7.651342e-03 -2.490800e-03  2.278938e-03
 [6]  3.197431e-04  6.137849e-04 -2.496882e-03 -1.065829e-03 -2.118179e-03
[11]  2.942936e-03 -1.335936e-03 -3.665618e-03  3.090566e-03  8.534956e-04
[16] -1.440421e-03 -5.230877e-04 -1.053686e-04 -9.771005e-04 -4.269216e-04
[21]  7.261694e-05 -1.039668e-03 -8.409151e-03 -3.497456e-03  2.216899e-03
[26] -4.633520e-03 -4.052130e-03 -4.746537e-03 -1.589622e-03 -2.523766e-04
Parameter:
 [1] -0.76604614 -1.19639662  0.83456888  0.72540413  0.08482452  0.56180393
 [7]  0.50615814  0.55728015  0.83796696  0.88371335 -0.70465116  0.85251098
[13] -0.18346956  0.66857787  0.57012481  0.39116561  0.91237990  0.63951482
[19]  0.26601566  0.29240836  0.44710919  0.94734056  6.52039015  0.02524762
[25] -0.01614603  2.88198219  0.03442452  3.52272237  1.44698423 -0.72964745
Function Value
[1] -15175.94
Gradient:
 [1] -2.085412e+07 -3.819717e+07  3.883989e+07  1.352594e+00 -4.283329e+00
 [6] -1.437250e+00 -6.558913e-01  

Re: [Rd] Bug in nlm, found using sem; failure in several flavors (PR#13883)

2009-08-08 Thread adik 
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1660387551-150661043-1249684349=:2997
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi Jeff,

 =09As mentioned in my message, I *did* replicate on another platform.=20
One platform was running linux in a VM, the other running MacOSX, on two
different physical machines.  The problem did not replicate on a PowerPC
box, so if it is a bug with intel chips, I think it's also appropriate to
report here given that the problem seems to cross the OS boundary.  I do no=
t
have access to a Windows machine.

 =09Also, I have spent a decent amount of time running memory testers on
the first machine's memory, to ensure that physical memory is not a
problem...the classic memcheck program finds no trouble.

 =09The CSV and .ram files both came through as base-64-encoded
attachments, which you actually quoted back to me in your response,
below...but in case your mail client can't read those and/or you are
interested in this bug, I have pasted them at the end of this message (sinc=
e
they're quite small).

 =09And thanks for the shout-out for bacon. I bought this domain name in
undergrad many years ago, and I must say, I've never regretted it!

--Adam

On Fri, 7 Aug 2009, Jeff Ryan wrote:

 Adam,

 It seems that your attachment didn't make it through.

 That aside, my experience with strange errors like those (random type
 not implemented ones) has been that you may be looking at a memory
 problem on you machine. Given that you can't replicate on another
 platform (and the .csv file didn't come through), I would think it
 wise to start there.

 My 2c.  And I love bacon too :)

 Jeff

 On Fri, Aug 7, 2009 at 1:10 PM, a...@ilovebacon.org wrote:
 =A0This message is in MIME format. =A0The first part should be readable =
text,
 =A0while the remaining parts are likely unreadable without MIME-aware to=
ols.

 --1660387551-1458482416-1249639718=3D:2997
 Content-Type: TEXT/PLAIN; CHARSET=3DUS-ASCII; FORMAT=3Dflowed
 Content-ID: pine.lnx.4.64.0908071039211.2...@parser.ilovebacon.org

 Hello,

 =A0 =A0 =A0 =A0There appears to be a bug in the nlm function, which I di=
scovered
 when trying to run an SEM. =A0The SEM is not bizarre; the covariance mat=
rix is
 solve-able and the eigenvalues are greater than zero, and I do not belie=
ve
 the sem package per se to be the problem (as nlm keeps being the part =
that
 fails, though I can't replicate this with other nlm tasks). =A0I apologi=
ze if
 I have put too many much information in this message; I'm not a programm=
er
 by trade so I don't really know what's going on here, which hampers my
 ability to write consise bug reports.

 Here is the code I use:

 library(sem)
 ice.S - read.csv(iceS.csv) # attached
 rownames(ice.S) - ice.S[,1]
 ice.S[,1] - NULL
 ice.S - as.matrix(ice.S)
 ice.ram - specify.model(ice.ram) # attached
 ice.N - 342
 ice.sem - sem(ram=3Dice.ram, S=3Dice.S, N=3Dice.N)

 ...at this point, any number of problems could occur. I have seen the
 following.

 1) Simple lack of convergence. (might be my model's fault.)
 2) Error in nlm(if (analytic.gradient) objective.2 else objective.1, sta=
rt,
 :
 =A0 type 31 is unimplemented in 'type2char'
 3) =A0*** caught segfault ***
 address 0xc019c87b, cause 'memory not mapped'

 Traceback:
 =A01: nlm(if (analytic.gradient) objective.2 else objective.1, start,
 hessian =3D TRUE, iterlim =3D maxiter, print.level =3D if (debug) 2 else=
 0,
 typsize =3D typsize, ...)
 =A02: sem.default(ram =3D ram, S =3D S, N =3D N, param.names =3D pars, v=
ar.names =3D
 vars, =A0 =A0 fixed.x =3D fixed.x, debug =3D debug, ...)
 =A03: sem(ram =3D ram, S =3D S, N =3D N, param.names =3D pars, var.names=
 =3D vars,
 fixed.x =3D fixed.x, debug =3D debug, ...)
 =A04: sem.mod(ram =3D ice.ram, S =3D ice.S, N =3D ice.N)
 =A05: sem(ram =3D ice.ram, S =3D ice.S, N =3D ice.N)

 Possible actions:
 1: abort (with core dump, if enabled)
 2: normal R exit
 3: exit R without saving workspace
 4: exit R saving workspace
 Selection: 1
 aborting ...
 Segmentation fault
 swiss:data$

 (no core was dumped).

 Trying with debug mode provides other interesting errors:

 ice.sem - sem(ram=3Dice.ram, S=3Dice.S, N=3Dice.N, debug=3DTRUE)

 ...gets up to some iteration (not always 15), and then R dies ungraceful=
ly,
 and exits to the shell:

 iteration =3D 15
 Step:
 =A0[1] =A01.253132e-02 =A01.183343e-02 -7.651342e-03 -2.490800e-03 =A02.=
278938e-03
 =A0[6] =A03.197431e-04 =A06.137849e-04 -2.496882e-03 -1.065829e-03 -2.11=
8179e-03
 [11] =A02.942936e-03 -1.335936e-03 -3.665618e-03 =A03.090566e-03 =A08.53=
4956e-04
 [16] -1.440421e-03 -5.230877e-04 -1.053686e-04 -9.771005e-04 -4.269216e-=
04
 [21] =A07.261694e-05 -1.039668e-03 -8.409151e-03 -3.497456e-03 =A02.2168=
99e-03
 [26] -4.633520e-03 -4.052130e-03 -4.746537e-03 -1.589622e-03 -2.523766e-=
04
 Parameter:
 =A0[1]

[Rd] Bug in nlm, found using sem; failure in several flavors (PR#13881)

2009-08-07 Thread adik 
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1660387551-1458482416-1249639718=:2997
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed
Content-ID: pine.lnx.4.64.0908071039211.2...@parser.ilovebacon.org

Hello,

There appears to be a bug in the nlm function, which I discovered
when trying to run an SEM.  The SEM is not bizarre; the covariance matrix is
solve-able and the eigenvalues are greater than zero, and I do not believe
the sem package per se to be the problem (as nlm keeps being the part that
fails, though I can't replicate this with other nlm tasks).  I apologize if
I have put too many much information in this message; I'm not a programmer
by trade so I don't really know what's going on here, which hampers my
ability to write consise bug reports.

Here is the code I use:

library(sem)
ice.S - read.csv(iceS.csv) # attached
rownames(ice.S) - ice.S[,1]
ice.S[,1] - NULL
ice.S - as.matrix(ice.S)
ice.ram - specify.model(ice.ram) # attached
ice.N - 342
ice.sem - sem(ram=ice.ram, S=ice.S, N=ice.N)

...at this point, any number of problems could occur. I have seen the
following.

1) Simple lack of convergence. (might be my model's fault.)
2) Error in nlm(if (analytic.gradient) objective.2 else objective.1, start,
:
   type 31 is unimplemented in 'type2char'
3)  *** caught segfault ***
address 0xc019c87b, cause 'memory not mapped'

Traceback:
  1: nlm(if (analytic.gradient) objective.2 else objective.1, start,
hessian = TRUE, iterlim = maxiter, print.level = if (debug) 2 else 0,
typsize = typsize, ...)
  2: sem.default(ram = ram, S = S, N = N, param.names = pars, var.names =
vars, fixed.x = fixed.x, debug = debug, ...)
  3: sem(ram = ram, S = S, N = N, param.names = pars, var.names = vars,
fixed.x = fixed.x, debug = debug, ...)
  4: sem.mod(ram = ice.ram, S = ice.S, N = ice.N)
  5: sem(ram = ice.ram, S = ice.S, N = ice.N)

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 1
aborting ...
Segmentation fault
swiss:data$

(no core was dumped).

Trying with debug mode provides other interesting errors:

 ice.sem - sem(ram=ice.ram, S=ice.S, N=ice.N, debug=TRUE)

...gets up to some iteration (not always 15), and then R dies ungracefully,
and exits to the shell:

iteration = 15
Step:
  [1]  1.253132e-02  1.183343e-02 -7.651342e-03 -2.490800e-03  2.278938e-03
  [6]  3.197431e-04  6.137849e-04 -2.496882e-03 -1.065829e-03 -2.118179e-03
[11]  2.942936e-03 -1.335936e-03 -3.665618e-03  3.090566e-03  8.534956e-04
[16] -1.440421e-03 -5.230877e-04 -1.053686e-04 -9.771005e-04 -4.269216e-04
[21]  7.261694e-05 -1.039668e-03 -8.409151e-03 -3.497456e-03  2.216899e-03
[26] -4.633520e-03 -4.052130e-03 -4.746537e-03 -1.589622e-03 -2.523766e-04
Parameter:
  [1] -0.76604614 -1.19639662  0.83456888  0.72540413  0.08482452  0.56180393
  [7]  0.50615814  0.55728015  0.83796696  0.88371335 -0.70465116  0.85251098
[13] -0.18346956  0.66857787  0.57012481  0.39116561  0.91237990  0.63951482
[19]  0.26601566  0.29240836  0.44710919  0.94734056  6.52039015  0.02524762
[25] -0.01614603  2.88198219  0.03442452  3.52272237  1.44698423 -0.72964745
Function Value
[1] -15175.94
Gradient:
  [1] -2.085412e+07 -3.819717e+07  3.883989e+07  1.352594e+00 -4.283329e+00
  [6] -1.437250e+00 -6.558913e-01  1.358276e+00  7.930865e+05 -1.293853e+06
[11] -5.816627e+03  5.908197e+05 -2.705742e+08 -1.194400e+07 -4.007083e+07
[16] -4.143068e+07 -6.159782e-01  1.044274e-01 -8.591048e+00 -2.083471e+00
[21] -7.548753e-01 -5.418994e-01 -2.799228e+02 -1.321739e+07 -3.517728e+07
[26] -7.106654e+02 -7.335293e+06 -7.335285e+05  3.117764e-01 -2.234989e+04

Abort trap
swiss:data$

...I have also seen convergence reached, and nlm then die with this message:

Error in nlm(if (analytic.gradient) objective.2 else objective.1, start,
:
   type 27 is unimplemented in 'type2char'

(similar to above, but now referring to type 27)

I have shown this effect (or something similar...never know how it'll fail
next) on the following platforms:

 version
_ 
platform   i386-apple-darwin9.7.0 
arch   i386 
os darwin9.7.0 
system i386, darwin9.7.0 
status 
major  2 
minor  9.1 
year   2009 
month  06 
day26 
svn rev48839 
language   R 
version.string R version 2.9.1 (2009-06-26)

 sessionInfo()
R version 2.9.1 (2009-06-26) 
i386-apple-darwin9.8.0

locale:
en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

other attached packages:
[1] sem_0.9-17

loaded via a namespace (and not attached):
[1] tcltk_2.9.1 tools_2.9.1

(I admit to having compiled this version of R myself (to link to a
hand-compiled ATLAS), though no errors were thrown in the compilation stage. 
I compiled using

Re: [Rd] Bug in nlm, found using sem; failure in several flavors (PR#13881)

2009-08-07 Thread Jeff Ryan 
Adam,

It seems that your attachment didn't make it through.

That aside, my experience with strange errors like those (random type
not implemented ones) has been that you may be looking at a memory
problem on you machine. Given that you can't replicate on another
platform (and the .csv file didn't come through), I would think it
wise to start there.

My 2c.  And I love bacon too :)

Jeff

On Fri, Aug 7, 2009 at 1:10 PM, a...@ilovebacon.org wrote:
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

 --1660387551-1458482416-1249639718=:2997
 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed
 Content-ID: pine.lnx.4.64.0908071039211.2...@parser.ilovebacon.org

 Hello,

        There appears to be a bug in the nlm function, which I discovered
 when trying to run an SEM.  The SEM is not bizarre; the covariance matrix is
 solve-able and the eigenvalues are greater than zero, and I do not believe
 the sem package per se to be the problem (as nlm keeps being the part that
 fails, though I can't replicate this with other nlm tasks).  I apologize if
 I have put too many much information in this message; I'm not a programmer
 by trade so I don't really know what's going on here, which hampers my
 ability to write consise bug reports.

 Here is the code I use:

 library(sem)
 ice.S - read.csv(iceS.csv) # attached
 rownames(ice.S) - ice.S[,1]
 ice.S[,1] - NULL
 ice.S - as.matrix(ice.S)
 ice.ram - specify.model(ice.ram) # attached
 ice.N - 342
 ice.sem - sem(ram=ice.ram, S=ice.S, N=ice.N)

 ...at this point, any number of problems could occur. I have seen the
 following.

 1) Simple lack of convergence. (might be my model's fault.)
 2) Error in nlm(if (analytic.gradient) objective.2 else objective.1, start,
 :
   type 31 is unimplemented in 'type2char'
 3)  *** caught segfault ***
 address 0xc019c87b, cause 'memory not mapped'

 Traceback:
  1: nlm(if (analytic.gradient) objective.2 else objective.1, start,
 hessian = TRUE, iterlim = maxiter, print.level = if (debug) 2 else 0,
 typsize = typsize, ...)
  2: sem.default(ram = ram, S = S, N = N, param.names = pars, var.names =
 vars,     fixed.x = fixed.x, debug = debug, ...)
  3: sem(ram = ram, S = S, N = N, param.names = pars, var.names = vars,
 fixed.x = fixed.x, debug = debug, ...)
  4: sem.mod(ram = ice.ram, S = ice.S, N = ice.N)
  5: sem(ram = ice.ram, S = ice.S, N = ice.N)

 Possible actions:
 1: abort (with core dump, if enabled)
 2: normal R exit
 3: exit R without saving workspace
 4: exit R saving workspace
 Selection: 1
 aborting ...
 Segmentation fault
 swiss:data$

 (no core was dumped).

 Trying with debug mode provides other interesting errors:

 ice.sem - sem(ram=ice.ram, S=ice.S, N=ice.N, debug=TRUE)

 ...gets up to some iteration (not always 15), and then R dies ungracefully,
 and exits to the shell:

 iteration = 15
 Step:
  [1]  1.253132e-02  1.183343e-02 -7.651342e-03 -2.490800e-03  2.278938e-03
  [6]  3.197431e-04  6.137849e-04 -2.496882e-03 -1.065829e-03 -2.118179e-03
 [11]  2.942936e-03 -1.335936e-03 -3.665618e-03  3.090566e-03  8.534956e-04
 [16] -1.440421e-03 -5.230877e-04 -1.053686e-04 -9.771005e-04 -4.269216e-04
 [21]  7.261694e-05 -1.039668e-03 -8.409151e-03 -3.497456e-03  2.216899e-03
 [26] -4.633520e-03 -4.052130e-03 -4.746537e-03 -1.589622e-03 -2.523766e-04
 Parameter:
  [1] -0.76604614 -1.19639662  0.83456888  0.72540413  0.08482452  0.56180393
  [7]  0.50615814  0.55728015  0.83796696  0.88371335 -0.70465116  0.85251098
 [13] -0.18346956  0.66857787  0.57012481  0.39116561  0.91237990  0.63951482
 [19]  0.26601566  0.29240836  0.44710919  0.94734056  6.52039015  0.02524762
 [25] -0.01614603  2.88198219  0.03442452  3.52272237  1.44698423 -0.72964745
 Function Value
 [1] -15175.94
 Gradient:
  [1] -2.085412e+07 -3.819717e+07  3.883989e+07  1.352594e+00 -4.283329e+00
  [6] -1.437250e+00 -6.558913e-01  1.358276e+00  7.930865e+05 -1.293853e+06
 [11] -5.816627e+03  5.908197e+05 -2.705742e+08 -1.194400e+07 -4.007083e+07
 [16] -4.143068e+07 -6.159782e-01  1.044274e-01 -8.591048e+00 -2.083471e+00
 [21] -7.548753e-01 -5.418994e-01 -2.799228e+02 -1.321739e+07 -3.517728e+07
 [26] -7.106654e+02 -7.335293e+06 -7.335285e+05  3.117764e-01 -2.234989e+04

 Abort trap
 swiss:data$

 ...I have also seen convergence reached, and nlm then die with this message:

 Error in nlm(if (analytic.gradient) objective.2 else objective.1, start,
 :
   type 27 is unimplemented in 'type2char'

 (similar to above, but now referring to type 27)

 I have shown this effect (or something similar...never know how it'll fail
 next) on the following platforms:

 version
                _
 platform       i386-apple-darwin9.7.0
 arch           i386
 os             darwin9.7.0
 system         i386, darwin9.7.0
 status
 major          2
 minor          9.1
 year           2009
 month          06
 day            26
 svn rev        48839
 language       R
 version.string R

Re: [Rd] Bug in nlm, found using sem; failure in several flavors (PR#13882)

2009-08-07 Thread jeff . a . ryan 
Adam,

It seems that your attachment didn't make it through.

That aside, my experience with strange errors like those (random type
not implemented ones) has been that you may be looking at a memory
problem on you machine. Given that you can't replicate on another
platform (and the .csv file didn't come through), I would think it
wise to start there.

My 2c.  And I love bacon too :)

Jeff

On Fri, Aug 7, 2009 at 1:10 PM, a...@ilovebacon.org wrote:
 =A0This message is in MIME format. =A0The first part should be readable t=
ext,
 =A0while the remaining parts are likely unreadable without MIME-aware too=
ls.

 --1660387551-1458482416-1249639718=3D:2997
 Content-Type: TEXT/PLAIN; CHARSET=3DUS-ASCII; FORMAT=3Dflowed
 Content-ID: pine.lnx.4.64.0908071039211.2...@parser.ilovebacon.org

 Hello,

 =A0 =A0 =A0 =A0There appears to be a bug in the nlm function, which I dis=
covered
 when trying to run an SEM. =A0The SEM is not bizarre; the covariance matr=
ix is
 solve-able and the eigenvalues are greater than zero, and I do not believ=
e
 the sem package per se to be the problem (as nlm keeps being the part t=
hat
 fails, though I can't replicate this with other nlm tasks). =A0I apologiz=
e if
 I have put too many much information in this message; I'm not a programme=
r
 by trade so I don't really know what's going on here, which hampers my
 ability to write consise bug reports.

 Here is the code I use:

 library(sem)
 ice.S - read.csv(iceS.csv) # attached
 rownames(ice.S) - ice.S[,1]
 ice.S[,1] - NULL
 ice.S - as.matrix(ice.S)
 ice.ram - specify.model(ice.ram) # attached
 ice.N - 342
 ice.sem - sem(ram=3Dice.ram, S=3Dice.S, N=3Dice.N)

 ...at this point, any number of problems could occur. I have seen the
 following.

 1) Simple lack of convergence. (might be my model's fault.)
 2) Error in nlm(if (analytic.gradient) objective.2 else objective.1, star=
t,
 :
 =A0 type 31 is unimplemented in 'type2char'
 3) =A0*** caught segfault ***
 address 0xc019c87b, cause 'memory not mapped'

 Traceback:
 =A01: nlm(if (analytic.gradient) objective.2 else objective.1, start,
 hessian =3D TRUE, iterlim =3D maxiter, print.level =3D if (debug) 2 else =
0,
 typsize =3D typsize, ...)
 =A02: sem.default(ram =3D ram, S =3D S, N =3D N, param.names =3D pars, va=
r.names =3D
 vars, =A0 =A0 fixed.x =3D fixed.x, debug =3D debug, ...)
 =A03: sem(ram =3D ram, S =3D S, N =3D N, param.names =3D pars, var.names =
=3D vars,
 fixed.x =3D fixed.x, debug =3D debug, ...)
 =A04: sem.mod(ram =3D ice.ram, S =3D ice.S, N =3D ice.N)
 =A05: sem(ram =3D ice.ram, S =3D ice.S, N =3D ice.N)

 Possible actions:
 1: abort (with core dump, if enabled)
 2: normal R exit
 3: exit R without saving workspace
 4: exit R saving workspace
 Selection: 1
 aborting ...
 Segmentation fault
 swiss:data$

 (no core was dumped).

 Trying with debug mode provides other interesting errors:

 ice.sem - sem(ram=3Dice.ram, S=3Dice.S, N=3Dice.N, debug=3DTRUE)

 ...gets up to some iteration (not always 15), and then R dies ungracefull=
y,
 and exits to the shell:

 iteration =3D 15
 Step:
 =A0[1] =A01.253132e-02 =A01.183343e-02 -7.651342e-03 -2.490800e-03 =A02.2=
78938e-03
 =A0[6] =A03.197431e-04 =A06.137849e-04 -2.496882e-03 -1.065829e-03 -2.118=
179e-03
 [11] =A02.942936e-03 -1.335936e-03 -3.665618e-03 =A03.090566e-03 =A08.534=
956e-04
 [16] -1.440421e-03 -5.230877e-04 -1.053686e-04 -9.771005e-04 -4.269216e-0=
4
 [21] =A07.261694e-05 -1.039668e-03 -8.409151e-03 -3.497456e-03 =A02.21689=
9e-03
 [26] -4.633520e-03 -4.052130e-03 -4.746537e-03 -1.589622e-03 -2.523766e-0=
4
 Parameter:
 =A0[1] -0.76604614 -1.19639662 =A00.83456888 =A00.72540413 =A00.08482452 =
=A00.56180393
 =A0[7] =A00.50615814 =A00.55728015 =A00.83796696 =A00.88371335 -0.7046511=
6 =A00.85251098
 [13] -0.18346956 =A00.66857787 =A00.57012481 =A00.39116561 =A00.91237990 =
=A00.63951482
 [19] =A00.26601566 =A00.29240836 =A00.44710919 =A00.94734056 =A06.5203901=
5 =A00.02524762
 [25] -0.01614603 =A02.88198219 =A00.03442452 =A03.52272237 =A01.44698423 =
-0.72964745
 Function Value
 [1] -15175.94
 Gradient:
 =A0[1] -2.085412e+07 -3.819717e+07 =A03.883989e+07 =A01.352594e+00 -4.283=
329e+00
 =A0[6] -1.437250e+00 -6.558913e-01 =A01.358276e+00 =A07.930865e+05 -1.293=
853e+06
 [11] -5.816627e+03 =A05.908197e+05 -2.705742e+08 -1.194400e+07 -4.007083e=
+07
 [16] -4.143068e+07 -6.159782e-01 =A01.044274e-01 -8.591048e+00 -2.083471e=
+00
 [21] -7.548753e-01 -5.418994e-01 -2.799228e+02 -1.321739e+07 -3.517728e+0=
7
 [26] -7.106654e+02 -7.335293e+06 -7.335285e+05 =A03.117764e-01 -2.234989e=
+04

 Abort trap
 swiss:data$

 ...I have also seen convergence reached, and nlm then die with this messa=
ge:

 Error in nlm(if (analytic.gradient) objective.2 else objective.1, start,
 :
 =A0 type 27 is unimplemented in 'type2char'

 (similar to above, but now referring to type 27)

 I have shown this effect (or something similar...never know how it'll fai=
l
 next) on the following platforms:

 version
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_

Re: [Rd] bug from nlm function (PR#9711)

2007-05-29 Thread Ben Bolker 
 bla at udec.cl writes:

 
 Full_Name: bernardo moises lagos alvarez
 Version: 2.4.0 
 OS:  Windows XP professional
 Submission from: (NULL) (152.74.219.16)
 
  nlm(fllwfuncHnew,p=c(1,20),x=xdat)
 
 Erro en log(b) : el argumento b está ausente, sin default
 
 __
 R-devel at r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
 

  This is not a bug.  fllwfuncHnew's first argument
should be a VECTOR with elements a and b (rather than
passing a and b as separate arguments.  From ?nlm:

 f: the function to be minimized.  [...]
  This should be a function of a vector of the
  length of 'p' followed by any other arguments specified by
  the '...' argument.

   Please try a little harder to make sure that
a bug is a bug before reporting it as such ...

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

[Rd] bug from nlm function (PR#9711)

2007-05-26 Thread bla 
Full_Name: bernardo moises lagos alvarez
Version: 2.4.0 
OS:  Windows XP professional
Submission from: (NULL) (152.74.219.16)


I need obtained the MLE of weibull parameters using the nlm with exact gradient
an 
hessian. I am doing. bug report :Erro en log(b) : el argumento b está ausente,
sin default

1.Construction to objectiv functin with n=1 data

fllwform-formula(~log(a)-log(b)-(a-1)*(log(x)-log(b))- (x^a)/(b^a))

 fllwfuncH -deriv(fllwform,c(a,b),function(a,b,x){})

 fllwfuncH
function (a, b, x) 

{

.expr2 - log(b)

.expr4 - a - 1

.expr5 - log(x)

.expr6 - .expr5 - .expr2

.expr9 - x^a

.expr10 - b^a

.expr19 - .expr10^2

.expr23 - 1/b

.value - log(a) - .expr2 - .expr4 * .expr6 - .expr9/.expr10

.grad - array(0, c(length(.value), 2), list(NULL, c(a, 

b)))

.grad[, a] - 1/a - .expr6 - (.expr9 * .expr5/.expr10 - 

.expr9 * (.expr10 * .expr2)/.expr19)

.grad[, b] - -(.expr23 - .expr4 * .expr23 - .expr9 * (b^.expr4 * 

a)/.expr19)

attr(.value, gradient) - .grad

.value

}

2. change the x argument on fllwfuncH function to data with n1 (on fnlmw file)


fllwfuncHnew -

function (a, b, x) 

{

.n-length(x)

.expr2 - log(b)

.expr4 - a - 1

.expr5 - log(x)

.expr6 - .expr5 - .expr2

.expr9 - x^a

.expr10 - b^a

.expr19 - .expr10^2

.expr23 - 1/b

.value - .n*(log(a) - .expr2) - .expr4 *sum(.expr6) - sum(.expr9)/.expr10

.grad - array(0, c(length(.value), 2), list(NULL, c(a, 

b)))

.grad[, a] - .n/a - sum(.expr6) - (sum(.expr9 * .expr5)/.expr10 - 

sum(.expr9) * (.expr10 * .expr2)/.expr19)

.grad[, b] - -(.n*.expr23 - .n*.expr4 * .expr23 - sum(.expr9) * (b^.expr4
* 

a)/.expr19)

attr(.value, gradient) - .grad

.value

}

 set.seed(99)

 xdat -rweibull(42,shape=1,scale=20)
 sum(dweibull(xdat,1,20,log=T))

[1] -174.6415


3. Use the fllwfuncHnew function on nlm:

 source(fnlmw)

 fllwfuncHnew(1,20,xdat)

[1] -174.6415

attr(,gradient)

a b

[1,] 30.88661 0.3410358

 nlm(fllwfuncHnew,p=c(1,20),x=xdat)

Erro en log(b) : el argumento b está ausente, sin default

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