Re: [Rd] xerbla called from BLAS routine (PR#8100)

[ripley]

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

--27464147-1060265079-1125299740=:28726
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Please check out

http://www.netlib.org/blas/index.html

file=09xerbla.f
for=09error handler for the Level 2 and 3 BLAS routines.
,=09(Auxiliary Routine)

and the refefence code which says

*  XERBLA  is an error handler for the LAPACK routines.
*  It is called by an LAPACK routine if an input parameter has an
*  invalid value.  A message is printed and execution stops.

So, XERBLA is an LAPACK handler, intended to be called from LAPACK=20
routines -- the level 2 and level 3 BLAS routines are considered to be
part of LAPACK in the reference implementation.

On Mon, 29 Aug 2005, Prof Brian Ripley wrote:

> I don't believe your message actually came from R's XERBLA.  Note that th=
e=20
> name is not quoted and that the name of the routine is not 6 characters l=
ong.
>
> Here is a genuine example from R:
>
> Error in La.svd(x, nu, nv) : LAPACK routine 'DGEBRD' gave error code -10
>
> There is no R 2.2.0, BTW.  If referring to R-devel, please do so with an =
SVN=20
> revision.
>
> On Sun, 28 Aug 2005 [EMAIL PROTECTED] wrote:
>
>> Full_Name: G=F6ran Brostr=F6m
>> Version: R-2.1.1, 2.2.0
>> OS: Debian unstable
>> Submission from: (NULL) (213.65.9.59)
>>=20
>>=20
>> Some BLAS routines call xerbla for error messages, which results in a=20
>> message
>> like
>> "LAPACK routine DGER gave error code -9".
>>=20
>> Suggested solution: In
>>=20
>> void F77_NAME(xerbla)(char *srname, int *info)
>> {
>>   /* srname is not null-terminated.  It should be 6 characters. */
>>char buf[7];
>>strncpy(buf, srname, 6);
>>buf[6] =3D '\0';
>>error(_("LAPACK routine '%6s' gave error code %d"), buf, -(*info));
>> }
>>=20
>> change 'LAPACK' to 'The' (or 'The BLAS/LAPACK').
>>=20
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>=20
>>=20
>
> --=20
> Brian D. Ripley,  [EMAIL PROTECTED]
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel:  +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax:  +44 1865 272595

--=20
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595
--27464147-1060265079-1125299740=:28726--

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

Re: [Rd] xerbla called from BLAS routine (PR#8100)

[ripley]

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

--27464147-1510948051-1125298763=:26166
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

I don't believe your message actually came from R's XERBLA.  Note that the=
=20
name is not quoted and that the name of the routine is not 6 characters=20
long.

Here is a genuine example from R:

Error in La.svd(x, nu, nv) : LAPACK routine 'DGEBRD' gave error code -10

There is no R 2.2.0, BTW.  If referring to R-devel, please do so with an=20
SVN revision.

On Sun, 28 Aug 2005 [EMAIL PROTECTED] wrote:

> Full_Name: G=F6ran Brostr=F6m
> Version: R-2.1.1, 2.2.0
> OS: Debian unstable
> Submission from: (NULL) (213.65.9.59)
>
>
> Some BLAS routines call xerbla for error messages, which results in a mes=
sage
> like
> "LAPACK routine DGER gave error code -9".
>
> Suggested solution: In
>
> void F77_NAME(xerbla)(char *srname, int *info)
> {
>   /* srname is not null-terminated.  It should be 6 characters. */
>char buf[7];
>strncpy(buf, srname, 6);
>buf[6] =3D '\0';
>error(_("LAPACK routine '%6s' gave error code %d"), buf, -(*info));
> }
>
> change 'LAPACK' to 'The' (or 'The BLAS/LAPACK').
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

--=20
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595
--27464147-1510948051-1125298763=:26166--

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

[Rd] Fwd: segfault

[stefano iacus]

This segfaults on OS X (10.4) on both X11 and quartz devices.
Seems a problem with lattice but I cannot test on other platforms
stefano


Begin forwarded message:

> From: "G. Sawitzki" <[EMAIL PROTECTED]>
> Date: 28 agosto 2005 14:11:18 GMT+02:00
> To: [EMAIL PROTECTED]
>
>
> Dear Stefano,
>
>  this small exaple leads to a crash of R. I did not try it on  
> versions other than the Mac version. So I am sending it to you  
> directly. If it is a littice problem, could you pass it to Deepayan  
> Sarkar? Thank you.
>
>   g.
>
> ==
> #pbinom
> library(grid)
> library(lattice)
>
> n<-20
> psteps<-50
> binomtable<- function (n,psteps){
> x<-(0:(10*n))/10
> p<- (0:psteps)/psteps
> dd<-expand.grid(x=x,p=p)
> dd$F<- pbinom(dd$x,n,dd$p)
> dd$x0<-trunc(dd$x)
> dd
> }
>
> bt<-binomtable(n=5,psteps=100)
> bt[bt$x-bt$x0>=0.9,]$F<-NA
> wireframe(bt$F~bt$x*bt$p,bt,groups=bt$x0,shade=TRUE) # leads to R  
> crash
> #wireframe(bt$F~bt$x*bt$p,bt,shade=TRUE) #ok
>

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

Re: [Rd] Fwd: segfault

[Prof Brian Ripley]

It does not crash for me on either Windows or Linux, but it does take a 
long time and the plot is a mess, so there does seem to be a 
lattice-related problem (maybe a usage one).

However, I think the crash is a Mac (presumably quartz()) problem.

On Mon, 29 Aug 2005, stefano iacus wrote:

> This segfaults on OS X (10.4) on both X11 and quartz devices.
> Seems a problem with lattice but I cannot test on other platforms
> stefano
>
>
> Begin forwarded message:
>
>> From: "G. Sawitzki" <[EMAIL PROTECTED]>
>> Date: 28 agosto 2005 14:11:18 GMT+02:00
>> To: [EMAIL PROTECTED]
>>
>>
>> Dear Stefano,
>>
>>  this small exaple leads to a crash of R. I did not try it on
>> versions other than the Mac version. So I am sending it to you
>> directly. If it is a littice problem, could you pass it to Deepayan
>> Sarkar? Thank you.
>>
>>   g.
>>
>> ==
>> #pbinom
>> library(grid)
>> library(lattice)
>>
>> n<-20
>> psteps<-50
>> binomtable<- function (n,psteps){
>> x<-(0:(10*n))/10
>> p<- (0:psteps)/psteps
>> dd<-expand.grid(x=x,p=p)
>> dd$F<- pbinom(dd$x,n,dd$p)
>> dd$x0<-trunc(dd$x)
>> dd
>> }
>>
>> bt<-binomtable(n=5,psteps=100)
>> bt[bt$x-bt$x0>=0.9,]$F<-NA
>> wireframe(bt$F~bt$x*bt$p,bt,groups=bt$x0,shade=TRUE) # leads to R
>> crash
>> #wireframe(bt$F~bt$x*bt$p,bt,shade=TRUE) #ok

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

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

Re: [Rd] xerbla called from BLAS routine (PR#8100)

[Göran Broström]

On Mon, Aug 29, 2005 at 10:06:00AM +0200, [EMAIL PROTECTED] 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.
> 
> --27464147-1510948051-1125298763=:26166
> Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
> Content-Transfer-Encoding: QUOTED-PRINTABLE
> 
> I don't believe your message actually came from R's XERBLA.  Note that the=
> =20
> name is not quoted and that the name of the routine is not 6 characters=20
> long.

Actually, it did. I didn't quote the message exactly (as I said). Now,
I took the liberty to make my own suggested change in R-devel_2005-08-28 
and rebuilt, and you may guess what error message I got.;) 

Error in coxreg.fit(X, Y, rs, strats, offset, init, max.survs, method,  :
The BLAS/LAPACK routine 'DSYR  ' gave error code -7


BTW, the original BLAS xerbla (from the netlib page you referred to)
gives the message:

 WRITE( *, FMT =  )SRNAME, INFO
 FORMAT( ' ** On entry to ', A6, ' parameter number ', I2, ' had ',
 $  'an illegal value' )

which I think is even better than my original suggestion. 
(Why was it changed?)

Göran 

> 
> Here is a genuine example from R:
> 
> Error in La.svd(x, nu, nv) : LAPACK routine 'DGEBRD' gave error code -10
> 
> There is no R 2.2.0, BTW.  If referring to R-devel, please do so with an=20
> SVN revision.
> 
> On Sun, 28 Aug 2005 [EMAIL PROTECTED] wrote:
> 
> > Full_Name: G=F6ran Brostr=F6m
> > Version: R-2.1.1, 2.2.0
> > OS: Debian unstable
> > Submission from: (NULL) (213.65.9.59)
> >
> >
> > Some BLAS routines call xerbla for error messages, which results in a mes=
> sage
> > like
> > "LAPACK routine DGER gave error code -9".
> >
> > Suggested solution: In
> >
> > void F77_NAME(xerbla)(char *srname, int *info)
> > {
> >   /* srname is not null-terminated.  It should be 6 characters. */
> >char buf[7];
> >strncpy(buf, srname, 6);
> >buf[6] =3D '\0';
> >error(_("LAPACK routine '%6s' gave error code %d"), buf, -(*info));
> > }
> >
> > change 'LAPACK' to 'The' (or 'The BLAS/LAPACK').
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
> 
> --=20
> Brian D. Ripley,  [EMAIL PROTECTED]
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel:  +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax:  +44 1865 272595
> --27464147-1510948051-1125298763=:26166--
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Göran Broströmtel: +46 90 786 5223
Professor and Head
Department of Statistics  fax: +46 90 786 6614
Umeå University   http://www.stat.umu.se/~goran.brostrom/
SE-90187 Umeå, Sweden e-mail: [EMAIL PROTECTED]

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

Re: [Rd] xerbla called from BLAS routine (PR#8100)

[Prof Brian Ripley]

On Mon, 29 Aug 2005, Göran Broström wrote:


On Mon, Aug 29, 2005 at 10:06:00AM +0200, [EMAIL PROTECTED] 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.

--27464147-1510948051-1125298763=:26166
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

I don't believe your message actually came from R's XERBLA.  Note that the=
=20
name is not quoted and that the name of the routine is not 6 characters=20
long.


Actually, it did.


You seem to be agreeing that it did not (which is the truth).


I didn't quote the message exactly (as I said).


You didn't say, and the posting guide does ask you to do so exactly.

Now, I took the liberty to make my own suggested change in 
R-devel_2005-08-28 and rebuilt, and you may guess what error message I 
got.;)


Error in coxreg.fit(X, Y, rs, strats, offset, init, max.survs, method,  :
   The BLAS/LAPACK routine 'DSYR  ' gave error code -7


BTW, the original BLAS xerbla (from the netlib page you referred to)
gives the message:

WRITE( *, FMT =  )SRNAME, INFO
 FORMAT( ' ** On entry to ', A6, ' parameter number ', I2, ' had ',
$  'an illegal value' )

which I think is even better than my original suggestion.
(Why was it changed?)


Probably because R is not a Fortran program and so needs to make clear 
what these refer to, and because LAPACK does have other error values that 
invalid parameter values.




Göran



Here is a genuine example from R:

Error in La.svd(x, nu, nv) : LAPACK routine 'DGEBRD' gave error code -10

There is no R 2.2.0, BTW.  If referring to R-devel, please do so with an=20
SVN revision.

On Sun, 28 Aug 2005 [EMAIL PROTECTED] wrote:


Full_Name: G=F6ran Brostr=F6m
Version: R-2.1.1, 2.2.0
OS: Debian unstable
Submission from: (NULL) (213.65.9.59)


Some BLAS routines call xerbla for error messages, which results in a mes=

sage

like
"LAPACK routine DGER gave error code -9".

Suggested solution: In

void F77_NAME(xerbla)(char *srname, int *info)
{
  /* srname is not null-terminated.  It should be 6 characters. */
   char buf[7];
   strncpy(buf, srname, 6);
   buf[6] =3D '\0';
   error(_("LAPACK routine '%6s' gave error code %d"), buf, -(*info));
}

change 'LAPACK' to 'The' (or 'The BLAS/LAPACK').

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




--=20
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595
--27464147-1510948051-1125298763=:26166--

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


--
Göran Broströmtel: +46 90 786 5223
Professor and Head
Department of Statistics  fax: +46 90 786 6614
Umeå University   http://www.stat.umu.se/~goran.brostrom/
SE-90187 Umeå, Sweden e-mail: [EMAIL PROTECTED]




--
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] robustness of install.packages/update.packages (was Re: bug in L-BFGS-B? (PR#8099))

[Prof Brian Ripley]

On Sun, 28 Aug 2005, Prof Brian Ripley wrote:

>> After redirecting R 2.1.1 on my laptop to use
>>http://cran.au.r-project.org/
>> for the CRAN repository, the install.packages() command ran without
>> problems.  I issued the command `library(MASS)' and tried out the
>> example from fitdistr on that machine (same strange result for second
>> command and warning messages were issued).  So I said
>> update.packages()  and that command failed when it wanted to update
>> the MASS package.  So I detach()'ed MASS and re-ran update.packages()
>> and again it failed.  So I exited R 2.1.1 and restarted it again
>> (probably I should have unloaded the namespace of MASS??) and then the
>> update.packages command worked.
>
> Yes, and that *is* in the rw-FAQ.
>
>> However, update.packages() wanted to update quite a few packages
>> besides MASS (the other packages in the VR bundle, nlme, lattice &c).
>> Once it failed on MASS, it terminated with an error and did not update
>> any of the other packages.  Would it be possible to robustify
>> update.packages behaviour such that it would continue in such
>> situations with updating the remaining packages?
>
> Not a good idea. Better to follow the FAQ.  At that point the dependencies
> have been worked out and will not be re-computed if a package installation
> fails.

I checked, and I am unable to reproduce this.  I get

> library(MASS)
> install.packages(c("MASS", "tree"))
trying URL 
'http://cran.at.r-project.org/bin/windows/contrib/2.2/tree_1.0-19.zip'
Content type 'application/zip' length 144676 bytes
opened URL
downloaded 141Kb

package 'tree' successfully unpacked and MD5 sums checked

The downloaded packages are in
 C:\Documents and Settings\ripley\Local 
Settings\Temp\Rtmp13777\downloaded_packages
updating HTML package descriptions
Warning message:
package MASS is in use and will not be installed

which seems perfectly reasonable.



-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

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

[Rd] RServe initialization problem

[joelarrais]

I want to use the R functionalities in my Java program. I found the Rserve
that appear to suite my requirements but I'm facing some configuration
problems.

I' following the web page tutorial
(http://stats.math.uni-augsburg.de/Rserve/doc.shtml) but I face the above
problem:

 

C:\Program Files\R\rw2010\bin>R CMD RSERVE

Can't open perl script "C:\PROGRA~1\R\rw2010/bin/RSERVE": No such file or
directory

 

Thanks in advance,

 

Joel Arrais,

[EMAIL PROTECTED]  

 


[[alternative HTML version deleted]]

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

[Rd] FW: RServe initialization problem

[joelarrais]

I want to use the R functionalities in my Java program. I found the Rserve
that appear to suite my requirements but I'm facing some configuration
problems.
I' following the web page tutorial
(http://stats.math.uni-augsburg.de/Rserve/doc.shtml) but I face the above
problem:

C:\Program Files\R\rw2010\bin>R CMD RSERVE
Can't open perl script "C:\PROGRA~1\R\rw2010/bin/RSERVE": No such file or
directory

Thanks in advance,

Joel Arrais,
[EMAIL PROTECTED]

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

Re: [Rd] xerbla called from BLAS routine (PR#8100)

[Göran Broström]

On Mon, Aug 29, 2005 at 10:27:24AM +0100, Prof Brian Ripley wrote:
> On Mon, 29 Aug 2005, Göran Broström wrote:
[...]
> >
> >BTW, the original BLAS xerbla (from the netlib page you referred to)
> >gives the message:
> >
> >WRITE( *, FMT =  )SRNAME, INFO
> > FORMAT( ' ** On entry to ', A6, ' parameter number ', I2, ' had ',
> >$  'an illegal value' )
> >
> >which I think is even better than my original suggestion.
> >(Why was it changed?)
> 
> Probably because R is not a Fortran program and so needs to make clear 
> what these refer to, and because LAPACK does have other error values that 
> invalid parameter values.

LAPACK/BLAS routines call xerbla "if an input parameter has an 
invalid value" (exact quote from  XERBLA at Netlib). Other types of errors 
are not printed (by xerbla), but it is up to the user to check the return 
value of the argument 'INFO'. See
http://www.netlib.org/lapack/lug/node119.html.

So we can safely give the more informative, original, error messages, 
together with mentioning LAPACK and eventually BLAS, whatever you prefer.
This would "make clear what these refer to". Given that other BLAS/LAPACK 
routines than xerbla aren't changed in R, of course.

Göran

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

Re: [Rd] robustness of install.packages/update.packages (was Re: bug in L-BFGS-B? (PR#8099))

[Berwin A Turlach]

G'day Brian,

> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> writes:

BDR> We've never encountered this lying mirror problem.
Indeed, that mirror is a worry, I guess that is the reason why it is
not on the official mirror list.

We had the problem with install.packages/update.packages under linux
too: source packages that supposedly should have been on the mirror
were not and the commands just terminated with an error message instead
of installing all those packages that could be found.  

Unfortunately, the way we are charged for internet traffic, it is much
cheaper for us to use mirror.aarnet.edu.au than any other mirror.  I
remember that last year around this time (give or take a some months)
when a new R version was released (2.0.0?) it took actually quite some
time before the sources appeared on the mirror, the directory
structure was mirrored, but not the files.  That was when I decided to
(temporarily) change mirrors.

BDR> Perhaps you (or another user of the unreliable mirror) could
BDR> contribute suitable fixes.
I will look into this when I find some time.

Cheers,

Berwin

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

Re: [Rd] xerbla called from BLAS routine (PR#8100)

[Prof Brian Ripley]

On Mon, 29 Aug 2005, Göran Broström wrote:


On Mon, Aug 29, 2005 at 10:27:24AM +0100, Prof Brian Ripley wrote:

On Mon, 29 Aug 2005, Göran Broström wrote:

[...]


BTW, the original BLAS xerbla (from the netlib page you referred to)
gives the message:

   WRITE( *, FMT =  )SRNAME, INFO
 FORMAT( ' ** On entry to ', A6, ' parameter number ', I2, ' had ',
   $  'an illegal value' )

which I think is even better than my original suggestion.
(Why was it changed?)


Probably because R is not a Fortran program and so needs to make clear
what these refer to, and because LAPACK does have other error values that
invalid parameter values.


LAPACK/BLAS routines call xerbla "if an input parameter has an
invalid value" (exact quote from  XERBLA at Netlib). Other types of errors
are not printed (by xerbla), but it is up to the user to check the return
value of the argument 'INFO'. See
http://www.netlib.org/lapack/lug/node119.html.


Maybe, that is not actually true for real-life LAPACK implementations, as 
I did say.



So we can safely give the more informative, original, error messages,
together with mentioning LAPACK and eventually BLAS, whatever you prefer.
This would "make clear what these refer to". Given that other BLAS/LAPACK
routines than xerbla aren't changed in R, of course.


Irrelevant as R is often compiled against other ones implementations.

--
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] FW: RServe initialization problem

[Prof Brian Ripley]

On Mon, 29 Aug 2005, joelarrais wrote:

>
> I want to use the R functionalities in my Java program. I found the Rserve
> that appear to suite my requirements but I'm facing some configuration
> problems.
> I' following the web page tutorial
> (http://stats.math.uni-augsburg.de/Rserve/doc.shtml) but I face the above
> problem:
>
> C:\Program Files\R\rw2010\bin>R CMD RSERVE
> Can't open perl script "C:\PROGRA~1\R\rw2010/bin/RSERVE": No such file or
> directory

Right.  RServe is not part of R: you need to install it.

BTW, as the posting guide says, the first thing to so is to update your R:
2.1.0 is not current.

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

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

Re: [Rd] robustness of install.packages/update.packages (was Re: bug in L-BFGS-B? (PR#8099))

[Berwin A Turlach]

G'day Brian,

> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> writes:

>>> However, update.packages() wanted to update quite a few
>>> packages besides MASS (the other packages in the VR bundle,
>>> nlme, lattice &c).  Once it failed on MASS, it terminated with
>>> an error and did not update any of the other packages.  Would
>>> it be possible to robustify update.packages behaviour such
>>> that it would continue in such situations with updating the
>>> remaining packages?
>>  Not a good idea. Better to follow the FAQ.  At that point the
>> dependencies have been worked out and will not be re-computed
>> if a package installation fails.

BDR> I checked, and I am unable to reproduce this.  I get
O.k., I tried to reproduce the behaviour.  So I installed the binary
distribution of R 2.1.1 in another directory on my laptop once more
(and then deleted the copy that I actually wanted to keep; shouldn't
do such things at this time of the day).

So below I attach what is, I believe a faithful reproduction of what I
tried to do yesterday.  Except that I did not run the file that
installs all the contributed packages that I like to have installed.

But it seems that now VR_7.2-17.zip has vanished from
mirror.aarnet.edu.au and you can see how on the first occassion the
download stops with an error.  I believe that in this case it could
have continued to download the other files.

Once I changed the mirror, the other behaviour that I mentioned
becomes apparent.  But I take your point that because of package
dependencies it might actually be not wise to continue with updating
further packages once the update of a package has failed.  But then,
shouldn't in that case (by the same argument) all the updates that
have been done already be undone again?

Cheers,

Berwin

++ Transcript of R session 

R : Copyright 2005, The R Foundation for Statistical Computing
Version 2.1.1  (2005-06-20), ISBN 3-900051-07-0

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for a HTML browser interface to help.
Type 'q()' to quit R.

> library(MASS)
> update.packages()
boot :
 Version 1.2-22 installed in C:/PROGRA~1/R/rw2011/library 
 Version 1.2-23 available at http://mirror.aarnet.edu.au/pub/CRAN
Update (y/N/c)?  y
VR :
 Version 7.2-16 installed in C:/PROGRA~1/R/rw2011/library 
 Version 7.2-17 available at http://mirror.aarnet.edu.au/pub/CRAN
Update (y/N/c)?  y
cluster :
 Version 1.10.0 installed in C:/PROGRA~1/R/rw2011/library 
 Version 1.10.1 available at http://mirror.aarnet.edu.au/pub/CRAN
Update (y/N/c)?  y
foreign :
 Version 0.8-8 installed in C:/PROGRA~1/R/rw2011/library 
 Version 0.8-9 available at http://mirror.aarnet.edu.au/pub/CRAN
Update (y/N/c)?  y
lattice :
 Version 0.11-8 installed in C:/PROGRA~1/R/rw2011/library 
 Version 0.12-3 available at http://mirror.aarnet.edu.au/pub/CRAN
Update (y/N/c)?  y
mgcv :
 Version 1.3-1 installed in C:/PROGRA~1/R/rw2011/library 
 Version 1.3-4 available at http://mirror.aarnet.edu.au/pub/CRAN
Update (y/N/c)?  y
nlme :
 Version 3.1-60 installed in C:/PROGRA~1/R/rw2011/library 
 Version 3.1-62 available at http://mirror.aarnet.edu.au/pub/CRAN
Update (y/N/c)?  y
trying URL 
'http://mirror.aarnet.edu.au/pub/CRAN/bin/windows/contrib/2.1/boot_1.2-23.zip'
Content type 'application/zip' length 767814 bytes
opened URL
downloaded 749Kb

trying URL 
'http://mirror.aarnet.edu.au/pub/CRAN/bin/windows/contrib/2.1/VR_7.2-17.zip'
Error in download.file(url, destfile, method, mode = "wb") : 
cannot open URL 
'http://mirror.aarnet.edu.au/pub/CRAN/bin/windows/contrib/2.1/VR_7.2-17.zip'
In addition: Warning message:
cannot open: HTTP status was '404 Not Found' 
> options(repos=c(CRAN="http://cran.au.r-project.org/";))
> options()$repos
   CRAN 
"http://cran.au.r-project.org/"; 
> update.packages()
boot :
 Version 1.2-22 installed in C:/PROGRA~1/R/rw2011/library 
 Version 1.2-23 available at http://cran.au.r-project.org
Update (y/N/c)?  y
VR :
 Version 7.2-16 installed in C:/PROGRA~1/R/rw2011/library 
 Version 7.2-19 available at http://cran.au.r-project.org
Update (y/N/c)?  y
cluster :
 Version 1.10.0 installed in C:/PROGRA~1/R/rw2011/library 
 Version 1.10.1 available at http://cran.au.r-project.org
Update (y/N/c)?  y
foreign :
 Version 0.8-8 installed in C:/PROGRA~1/R/rw2011/library 
 Version 0.8-10 available at http://cran.au.r-project.org
Update (y/N/c)?  y
lattice :
 Version 0.11-8 installed in C:/PROGRA~1/R/rw2011/library 
 Version 0.12-5 available at htt

[Rd] BLAS and ATLAS

[Göran Broström]

On Mon, Aug 29, 2005 at 11:48:23AM +0100, Prof Brian Ripley wrote:
> On Mon, 29 Aug 2005, Göran Broström wrote:

> >LAPACK/BLAS routines call xerbla "if an input parameter has an
> >invalid value" (exact quote from  XERBLA at Netlib). Other types of errors
> >are not printed (by xerbla), but it is up to the user to check the return
> >value of the argument 'INFO'. See
> >http://www.netlib.org/lapack/lug/node119.html.
> 
> Maybe, that is not actually true for real-life LAPACK implementations, as 
> I did say.
> 
> >So we can safely give the more informative, original, error messages,
> >together with mentioning LAPACK and eventually BLAS, whatever you prefer.
> >This would "make clear what these refer to". Given that other BLAS/LAPACK
> >routines than xerbla aren't changed in R, of course.
> 
> Irrelevant as R is often compiled against other ones implementations.

That confuses me. My R installation (R-devel of yesterday) is compiled
against ATLAS BLAS (from Debian-unstable). Why, then, is xerbla from  R  
sources used anyway? 

Göran

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

Re: [Rd] RServe initialization problem

[Simon Urbanek]

Joel,

On Aug 29, 2005, at 5:57 AM, joelarrais wrote:

> I want to use the R functionalities in my Java program. I found the  
> Rserve
> that appear to suite my requirements but I'm facing some configuration
> problems.
>
> I' following the web page tutorial
> (http://stats.math.uni-augsburg.de/Rserve/doc.shtml) but I face the  
> above
> problem:
>
> C:\Program Files\R\rw2010\bin>R CMD RSERVE
>
> Can't open perl script "C:\PROGRA~1\R\rw2010/bin/RSERVE": No such  
> file or
> directory

You are using Windows, not unix, so should be just running Rserve.exe  
- please see the documentation, it specifically distinguishes Windows  
from unix. You may also consider reading the release notes for the  
Windows version of Rserve that discuss the differences.

Cheers,
Simon

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

Re: [Rd] BLAS and ATLAS

[Prof Brian Ripley]

On Mon, 29 Aug 2005, Göran Broström wrote:


On Mon, Aug 29, 2005 at 11:48:23AM +0100, Prof Brian Ripley wrote:

On Mon, 29 Aug 2005, Göran Broström wrote:



LAPACK/BLAS routines call xerbla "if an input parameter has an
invalid value" (exact quote from  XERBLA at Netlib). Other types of errors
are not printed (by xerbla), but it is up to the user to check the return
value of the argument 'INFO'. See
http://www.netlib.org/lapack/lug/node119.html.


Maybe, that is not actually true for real-life LAPACK implementations, as
I did say.


So we can safely give the more informative, original, error messages,
together with mentioning LAPACK and eventually BLAS, whatever you prefer.
This would "make clear what these refer to". Given that other BLAS/LAPACK
routines than xerbla aren't changed in R, of course.


Irrelevant as R is often compiled against other ones implementations.


That confuses me. My R installation (R-devel of yesterday) is compiled
against ATLAS BLAS (from Debian-unstable). Why, then, is xerbla from  R
sources used anyway?


Because it is the only one seen: ATLAS does not provide it.  There is no 
guarantee that ATLAS or libsunperf or vecLib ... only use xerbla in the 
meaning in that page.


--
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] FW: RServe initialization problem

[Simon Urbanek]

On Aug 29, 2005, at 6:04 AM, joelarrais wrote:

> I want to use the R functionalities in my Java program. I found the  
> Rserve
> that appear to suite my requirements but I'm facing some configuration
> problems.
> I' following the web page tutorial
> (http://stats.math.uni-augsburg.de/Rserve/doc.shtml) but I face the  
> above
> problem:
>
> C:\Program Files\R\rw2010\bin>R CMD RSERVE
> Can't open perl script "C:\PROGRA~1\R\rw2010/bin/RSERVE": No such  
> file or
> directory

I'm not quite sure why this e-mail was also sent to the R-devel,  
please see the posting guide!

Also a closer look at the documentation you mention would reveal that  
it strictly distinguishes between unix and Windows systems - on the  
latter you have to run the Rserve.exe application instead of using R  
CMD xxx.

Cheers,
Simon

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

Re: [Rd] Additional Books on R for Web Site Listing

[Friedrich . Leisch]

> On Sun, 28 Aug 2005 17:30:24 -0500,
> Marc Schwartz (MS) wrote:

  > Hi all,
  > I noted that the books below are not included on the R web site
  > Documentation section under "Books". I thought that I would provide
  > these and have created some bib entries consistent with the style used
  > on the site. The abstract sections were copied from the publisher
  > sites.

Thanks a lot, I have added them to the list (will go live later
today).

Best,
Fritz

-- 
---
Friedrich Leisch 
Institut für Statistik Tel: (+43 1) 58801 10715
Technische Universität WienFax: (+43 1) 58801 10798
Wiedner Hauptstraße 8-10/1071
A-1040 Wien, Austria http://www.ci.tuwien.ac.at/~leisch

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

[Rd] Compile warning in unique.c

[Harris, Michael (NIH/NCI) [E]]

Hello, 

 

I am getting a compile warning when building R from source.  I am building
on a AMD64 Opteron system  with  gcc (GCC) 3.3.3 (SuSE Linux)

 

The warning is: 

 

unique.c: In function `cshash':

unique.c:1146: warning: cast from pointer to integer of different size

 

 

 

Thanks, 

 

Michael

 

 

 




[[alternative HTML version deleted]]

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

Re: [Rd] Compile warning in unique.c

[Prof Brian Ripley]

On Mon, 29 Aug 2005, Harris, Michael (NIH/NCI) [E] wrote:

> I am getting a compile warning when building R from source.  I am building
> on a AMD64 Opteron system  with  gcc (GCC) 3.3.3 (SuSE Linux)
>
> The warning is:
>
>unique.c: In function `cshash':
>
> unique.c:1146: warning: cast from pointer to integer of different size

Have you bothered to read the code?  The comment there should explain this 
to you.

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

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

Re: [Rd] Compile warning in unique.c

[Thomas Lumley]

On Mon, 29 Aug 2005, Harris, Michael (NIH/NCI) [E] wrote:
>
> I am getting a compile warning when building R from source.  I am building
> on a AMD64 Opteron system  with  gcc (GCC) 3.3.3 (SuSE Linux)
>
> The warning is:
>
>unique.c: In function `cshash':
>
> unique.c:1146: warning: cast from pointer to integer of different size
>

The comment immediately above this suggests that it is deliberate

  /* Use hashing to improve object.size. Here we want equal CHARSXPs,
 not equal contents.  This only uses the bottom 32 bits of the pointer,
 but for now that's almost certainly OK */

The warning is presumably because casting this int back to a pointer would 
fail (and is a common 32 to 64bit conversion error), but that's not what 
is happening here.

-thomas

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

Re: [Rd] BLAS and ATLAS

[Göran Broström]

On Mon, Aug 29, 2005 at 02:43:28PM +0100, Prof Brian Ripley wrote:
> On Mon, 29 Aug 2005, Göran Broström wrote:
> 
> >On Mon, Aug 29, 2005 at 11:48:23AM +0100, Prof Brian Ripley wrote:
> >>On Mon, 29 Aug 2005, Göran Broström wrote:
> >
> >>>LAPACK/BLAS routines call xerbla "if an input parameter has an
> >>>invalid value" (exact quote from  XERBLA at Netlib). Other types of 
> >>>errors
> >>>are not printed (by xerbla), but it is up to the user to check the return
> >>>value of the argument 'INFO'. See
> >>>http://www.netlib.org/lapack/lug/node119.html.
> >>
> >>Maybe, that is not actually true for real-life LAPACK implementations, as
> >>I did say.
> >>
> >>>So we can safely give the more informative, original, error messages,
> >>>together with mentioning LAPACK and eventually BLAS, whatever you prefer.
> >>>This would "make clear what these refer to". Given that other BLAS/LAPACK
> >>>routines than xerbla aren't changed in R, of course.
> >>
> >>Irrelevant as R is often compiled against other ones implementations.
> >
> >That confuses me. My R installation (R-devel of yesterday) is compiled
> >against ATLAS BLAS (from Debian-unstable). Why, then, is xerbla from  R
> >sources used anyway?
> 
> Because it is the only one seen: ATLAS does not provide it.  There is no 
> guarantee that ATLAS or libsunperf or vecLib ... only use xerbla in the 
> meaning in that page.

Well, the ATLAS sources contain 'xerbla.f'. So what does 'does not provide 
it' mean? Not included in the build process?

Göran

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

[Rd] floating point control on windows

[Chris Paulse]

Hi,

I'm sure that this question has come up many times before.  When I load an R
extension dll I've built with the Microsoft compiler, I get the warning:

 

Warning message:

DLL attempted to change FPU control word from 8001f to 9001f

 

So, what I did to try to fix the problem (to my knowledge, Microsoft will
not support compile time switching of floating point control until version
8.0 of their compiler - see: http://blogs.msdn.com/ericflee) was to place
the following statement inside R_init_mylib:

 

 

_controlfp(_MCW_PC, _PC_64); // use extended precision for operations in x87
FPU

 

This didn't fix my problem.  I ended up sprinkling these liberally
throughout my code, but that didn't help.  One thing I do like about the
Microsoft compiler is the debugging facility.  But, I'll definitely switch
to gcc if this is necessary to get rid of the problem.

 

Thanks,

Chris Paulse

 

 


[[alternative HTML version deleted]]

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

[Rd] Rserve seem to be working but it doesn't

[Joel Arrais]

I'm trying to use the Rserve server in my Windows system.

 

When i try to run the RServe i get the following message:

 

C:\ ..\rserve

Rserve: Ok, ready to answer queries.

 

However when i try to test the connection using the telnet command (telnet
localhost 6311 ) it doesn't seem to be working. Just get the following
message:

 

Rsrv0102QAP1

 

--

 

 

Thanks in advance,

 

Joel Arrais,

[EMAIL PROTECTED]


[[alternative HTML version deleted]]

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

Re: [Rd] Fwd: segfault

[Deepayan Sarkar]

On Monday 29 August 2005 03:35, Prof Brian Ripley wrote:
> It does not crash for me on either Windows or Linux, but it does take a
> long time and the plot is a mess, so there does seem to be a
> lattice-related problem (maybe a usage one).

It is improper (or at least unanticipated) usage. The example cited does not 
crash X11 on GNU/Linux for me, but the following does:

wireframe(F ~ x * p, bt, groups = factor(p), shade=TRUE) 

This involves some C code in lattice, which could well be the culprit. I'll 
clarify the documentation, but I'm not sure how easy it would be to catch the 
bug.

Deepayan

> However, I think the crash is a Mac (presumably quartz()) problem.
>
> On Mon, 29 Aug 2005, stefano iacus wrote:
> > This segfaults on OS X (10.4) on both X11 and quartz devices.
> > Seems a problem with lattice but I cannot test on other platforms
> > stefano
> >
> > Begin forwarded message:
> >> From: "G. Sawitzki" <[EMAIL PROTECTED]>
> >> Date: 28 agosto 2005 14:11:18 GMT+02:00
> >> To: [EMAIL PROTECTED]
> >>
> >>
> >> Dear Stefano,
> >>
> >>  this small exaple leads to a crash of R. I did not try it on
> >> versions other than the Mac version. So I am sending it to you
> >> directly. If it is a littice problem, could you pass it to Deepayan
> >> Sarkar? Thank you.
> >>
> >>   g.
> >>
> >> ==
> >> #pbinom
> >> library(grid)
> >> library(lattice)
> >>
> >> n<-20
> >> psteps<-50
> >> binomtable<- function (n,psteps){
> >> x<-(0:(10*n))/10
> >> p<- (0:psteps)/psteps
> >> dd<-expand.grid(x=x,p=p)
> >> dd$F<- pbinom(dd$x,n,dd$p)
> >> dd$x0<-trunc(dd$x)
> >> dd
> >> }
> >>
> >> bt<-binomtable(n=5,psteps=100)
> >> bt[bt$x-bt$x0>=0.9,]$F<-NA
> >> wireframe(bt$F~bt$x*bt$p,bt,groups=bt$x0,shade=TRUE) # leads to R
> >> crash
> >> #wireframe(bt$F~bt$x*bt$p,bt,shade=TRUE) #ok

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

Re: [Rd] floating point control on windows

[Prof Brian Ripley]

We recommend calling Rwin_fpset() which is exported by R.dll and is known
to do the trick.  As it contains

 _controlfp(_PC_64, _MCW_PC);

it may be that the args you used are incorrect (and I am not on Windows 
to check the docs, but note that is the form used in the URL you cite).

On Mon, 29 Aug 2005, Chris Paulse wrote:

> Hi,
>
> I'm sure that this question has come up many times before.  When I load an R
> extension dll I've built with the Microsoft compiler, I get the warning:

> Warning message:
>
> DLL attempted to change FPU control word from 8001f to 9001f
>
> So, what I did to try to fix the problem (to my knowledge, Microsoft will
> not support compile time switching of floating point control until version
> 8.0 of their compiler - see: http://blogs.msdn.com/ericflee) was to place
> the following statement inside R_init_mylib:

> _controlfp(_MCW_PC, _PC_64); // use extended precision for operations in x87
> FPU
>
> This didn't fix my problem.  I ended up sprinkling these liberally
> throughout my code, but that didn't help.  One thing I do like about the
> Microsoft compiler is the debugging facility.  But, I'll definitely switch
> to gcc if this is necessary to get rid of the problem.

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

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

Re: [Rd] floating point control on windows

[Chris Paulse]

Thanks for the guidance.

Using the following code fixed my problem:

#ifdef _WIN32
BOOL APIENTRY DllMain( HANDLE hModule, 
   DWORD  ul_reason_for_call, 
   LPVOID lpReserved
 )
{
if (ul_reason_for_call == DLL_PROCESS_ATTACH)
{
Rwin_fpset();
}

return TRUE;
}
#endif

-Original Message-
From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 29, 2005 10:53 AM
To: Chris Paulse
Cc: r-devel@r-project.org
Subject: Re: [Rd] floating point control on windows

We recommend calling Rwin_fpset() which is exported by R.dll and is known
to do the trick.  As it contains

 _controlfp(_PC_64, _MCW_PC);

it may be that the args you used are incorrect (and I am not on Windows 
to check the docs, but note that is the form used in the URL you cite).

On Mon, 29 Aug 2005, Chris Paulse wrote:

> Hi,
>
> I'm sure that this question has come up many times before.  When I load an
R
> extension dll I've built with the Microsoft compiler, I get the warning:

> Warning message:
>
> DLL attempted to change FPU control word from 8001f to 9001f
>
> So, what I did to try to fix the problem (to my knowledge, Microsoft will
> not support compile time switching of floating point control until version
> 8.0 of their compiler - see: http://blogs.msdn.com/ericflee) was to place
> the following statement inside R_init_mylib:

> _controlfp(_MCW_PC, _PC_64); // use extended precision for operations in
x87
> FPU
>
> This didn't fix my problem.  I ended up sprinkling these liberally
> throughout my code, but that didn't help.  One thing I do like about the
> Microsoft compiler is the debugging facility.  But, I'll definitely switch
> to gcc if this is necessary to get rid of the problem.

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

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

[Rd] Problems setting and adding POSIX dates (PR#8103)

[Robert . McGehee]

> tm <- ISOdate(2005, 08, 29, hour =3D 12, tz =3D "EDT")
> tm
[1] "2005-08-29 11:00:00 EDT"
## Firstly, notice that the hour is 11, but was set to 12.

> tm + 0
[1] "2005-08-29 11:00:00 EDT"
> tm + 3600  ## Add an hour
[1] "2005-08-29 12:00:00 EDT"

> tm + c(0, 1) * 3600  ## Repeat
[1] "2005-08-29 07:00:00 Eastern Daylight Time"
[2] "2005-08-29 08:00:00 Eastern Daylight Time"

Oddly, the first two results differ from the second two by 4 hours.

> version
 _ =20
platform i386-pc-mingw32
arch i386  =20
os   mingw32   =20
system   i386, mingw32 =20
status =20
major2 =20
minor1.1   =20
year 2005  =20
month06=20
day  20=20
language R=20



Robert McGehee
Quantitative Analyst
Geode Capital Management, LLC
53 State Street, 5th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]



This e-mail, and any attachments hereto, are intended for us...{{dropped}}

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

[Rd] Question about SET_LENGTH

[James Bullard]

Hello all, thanks for all the help on the other issues. This one should
be relatively straightforward. I have a vector of integers which I
allocate to be the maximal size possible (meaning I'll never see more
than cel.GetNumOutliers, but most likely I'll see less) therefore, I
want to resize the vector, one solution would be to allocate a new
vector then to copy into the new vector. That is what I was going to do
until I saw the SET_LENGTH macro. Does this macro effectively take care
of the memory? Is this an acceptable use of the macro? The code works,
but I dont want any lurking memory problems.


PROTECT(outliers = NEW_INTEGER(cel.GetNumOutliers()));

 if (i_readOutliers != 0) {
 if (noutlier == 0) {
outliers = R_NilValue;
  }
  else if (noutlier < cel.GetNumOutliers()) {
SET_LENGTH(outliers, noutlier);
  }
 }


Thanks as always!

jim

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

Re: [Rd] efficiency of sample() with prob.

[Prof Brian Ripley]

Peter Windridge and I investigated this further.  It seems the 
distribution used for your tests is maximally favourable to your proposal 
(not uncommon in papers, but not very honest).  There are examples in 
which the existing method is substantially faster than Walker's (when each 
set of prob is used only a few times and there are many sets) and only a 
few areas in which there are large gains to be had.  For example, with 
binomial(N=1, p=0.25) Walker's method is not twice as fast, and 10 
million samples only take a second or two.  (Tabulating them takes quite a 
bit longer.)  OTOH, with a distribution concentrated on 5 out of 1 
points, the existing method is twice as fast.

Changing how this is done will break the reproducibility of past programs, 
and we don't really want to introduce yet more options.  So it seems only 
worth doing when there are substantial speed gains.  I am still tuning 
this, but it seems that it is worthwhile if the number of probs >= 0.1/N 
is more than 200 or so.  The advantage of Walker's method is that its 
speed is more-or-less independent of probs (unless they are actually all 
identical!), but equally that can be a disadvantage.


On Thu, 23 Jun 2005, Bo Peng wrote:

>> We suggest that you take up your own suggestion, research this area and
>> offer the R project the results of your research for consideration as your
>> contribution.
>
> I implemented Walker's alias method and re-compiled R. Here is what
> I did:

[...]

>
>> b=sample(seq(1,100), prob=seq(1,100), replace=TRUE, size=100)
>> table(b)/100*sum(seq(1,100))
>
> 4. run the following code in current R 2.1.0 and updated R.
>
> for(prob in seq(1,4)){
>  for(sample in seq(1,4)){
>x = seq(1:(10^prob))   # short to long x
>p = abs(rnorm(length(x)))  # prob vector
>times = 10^(6-prob)   # run shorter cases more times
>Rprof(paste("sample_", prob, "_", sample, ".prof", sep=''))
>for(t in seq(1,times)){
>  sample(x, prob=p, size=10^sample, replace=TRUE )
>}
>Rprof(NULL)
>  }
> }
>
> Basically, I tried to test the performance of sample(replace=TRUE, prob=..)
> with different length of x and size.
>
> 5. process the profiles and here is the result.
> p: length of prob and x
> size: size of sample
> cell: execution time of old/updated sample()
>
>  size\p10  10^210^3   10^4
>  10   2.4/1.6  0.32/0.22   0.20/0.08  0.24/0.06
>  10^2 3.1/2.6  0.48/0.28   0.28/0.06  0.30/0.06
>  10^3 11.8/11.11.84/1.14   0.94/0.18  0.96/0.08
>  10^4 96.8/96.615.34/9.68  7.54/1.06  7.48/0.16
>  run: 1100010010 times
>
> We can see that the alias method is quicker than the linear search
> method in all cases. The performance difference is greatest (>50 times)
> when the original algorithm need to search in a long prob vector.
>
> I have not thoroughly tested the new function. I will do so if you
> (the developers) think that this has the potential to be incorporated
> into R.
>
> Thanks.
>
> Bo Peng
> Department of Statistics
> Rice University
>
>

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

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

Re: [Rd] floating point control on windows

[dhinds]

Chris Paulse <[EMAIL PROTECTED]> wrote:
> Hi,

> I'm sure that this question has come up many times before.  When I load an R
> extension dll I've built with the Microsoft compiler, I get the warning:

> Warning message:

> DLL attempted to change FPU control word from 8001f to 9001f

I think maybe most parsimonious/simple fix for this problem is to add
"fp10.obj" to the link line for your code.  This file is provided by
Microsoft to flip the precision of the run time library to 80 bits.
The linker should find it automatically.

http://msdn.microsoft.com/library/en-us/vclib/html/_crt_floating.2d.point_support.asp

-- David Hinds

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

Re: [Rd] Question about SET_LENGTH

[Prof Brian Ripley]

SET_LENGTH is in Rdefines.h (you did not say).  It is a wrapper for

x = lengthgets(x, n)

and that will do what you want.  HOWEVER, you have changed x and the 
object it points to, so you do need to worry about re-protection.
So, I think that macro is rather dangerous (and it is not the only danger 
lurking in Rdefines.h, which provides no valid way to assign elements of 
character strings or lists any more).

Look and see how lengthgets is used in the R sources.

On Mon, 29 Aug 2005, James Bullard wrote:

> Hello all, thanks for all the help on the other issues. This one should
> be relatively straightforward. I have a vector of integers which I
> allocate to be the maximal size possible (meaning I'll never see more
> than cel.GetNumOutliers, but most likely I'll see less) therefore, I
> want to resize the vector, one solution would be to allocate a new
> vector then to copy into the new vector. That is what I was going to do
> until I saw the SET_LENGTH macro. Does this macro effectively take care
> of the memory? Is this an acceptable use of the macro? The code works,
> but I dont want any lurking memory problems.
>
>
> PROTECT(outliers = NEW_INTEGER(cel.GetNumOutliers()));
>
> if (i_readOutliers != 0) {
> if (noutlier == 0) {
>outliers = R_NilValue;
>  }
>  else if (noutlier < cel.GetNumOutliers()) {
>SET_LENGTH(outliers, noutlier);
>  }
> }

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

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

[Rd] test for readline installation fails if installation location non-standard (PR#8104)

[rbug05]

Full_Name: D Kreil
Version: 2.1.1
OS: HP-UX B.11.23 U ia64 0029870451 unlimited-user license
Submission from: (NULL) (62.178.15.60)


When the dependency readline is installed in a non-standard location the
installation procedure fails.
If using a non-standard installation location like

  --prefix=/bi/common --exec-prefix=/bi/arch

the configure script default include and library paths should adapt accordingly.
They don't (/usr/local defaults remain).

Workaround:

  CPPFLAGS=-I/bi/common/include LDFLAGS=-L/bi/arch/lib ./configure

This should not be necessary, I think.

Best regards,

D Kreil.

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

Re: [Rd] test for readline installation fails if installation location non-standard (PR#8104)

[Peter Dalgaard]

[EMAIL PROTECTED] writes:

> Full_Name: D Kreil
> Version: 2.1.1
> OS: HP-UX B.11.23 U ia64 0029870451 unlimited-user license
> Submission from: (NULL) (62.178.15.60)
> 
> 
> When the dependency readline is installed in a non-standard location the
> installation procedure fails.
> If using a non-standard installation location like
> 
>   --prefix=/bi/common --exec-prefix=/bi/arch
> 
> the configure script default include and library paths should adapt 
> accordingly.
> They don't (/usr/local defaults remain).
> 
> Workaround:
> 
>   CPPFLAGS=-I/bi/common/include LDFLAGS=-L/bi/arch/lib ./configure
> 
> This should not be necessary, I think.

This is inherited from GNU autotools and apparently they think it
should. It is most certainly not a bug.

Presumably, the rationale is that the install target is not
necessarily releated to your build tools and libraries. You could have
--prefix=. or --prefix=$HOME/tools or whatever. If so, there is some
danger of picking up a home-built and outdated version instead of the
system one.

-- 
   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
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

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

Re: [Rd] test for readline installation fails if installation (PR#8105)

[boku]

Dear Peter,

Fair enough. For many people who install R without root rights, however, this 
is a first stumbling block so perhaps it might be worthwhile adding it to an 
"Installation how-to" document.

I found another hicup:

ld: Unsatisfied symbol "finite" in file colors.o

Fix: replace "finite" with R_FINITE in colors.c line 269.

Do you want this separately submitted via Jitterbug?

With best regards,

David.


---
Dr David Philip Kreil   
Research Fellow, Darwin College,  | WWTF Vienna Science Chair of
University of Cambridge   | Bioinformatics, Dept of Biotechnology,
++44 1223 764107, fax 7092 810040 | c/o IAM / BOKU, A-1190 Muthgasse 18
www.inference.phy.cam.ac.uk/dpk20 | ++43 1 360066830

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

Re: [Rd] test for readline installation fails if installation location non-standard (PR#8104)

[David Kreil]

Dear Peter,

Fair enough. For many people who install R without root rights, however, this 
is a first stumbling block so perhaps it might be worthwhile adding it to an 
"Installation how-to" document.

I found another hicup:

ld: Unsatisfied symbol "finite" in file colors.o

Fix: replace "finite" with R_FINITE in colors.c line 269.

Do you want this separately submitted via Jitterbug?

With best regards,

David.


---
Dr David Philip Kreil   
Research Fellow, Darwin College,  | WWTF Vienna Science Chair of
University of Cambridge   | Bioinformatics, Dept of Biotechnology,
++44 1223 764107, fax 7092 810040 | c/o IAM / BOKU, A-1190 Muthgasse 18
www.inference.phy.cam.ac.uk/dpk20 | ++43 1 360066830

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

[Rd] Core dump during lazy loading of "survival" at installation time (PR#8106)

[rbug05]

Full_Name: D Kreil
Version: 2.1.1
OS: HP-UX B.11.23 U ia64 0029870451 unlimited-user license
Submission from: (NULL) (62.178.15.60)


I sadly get a core-dump during installation, when it tries to lazyload package
survival. Any idea what to do about this?

Best regards,
D.


...
include   -fPIC  -g -O2 -c survindex2.c -o survindex2.o
gcc -I/bi/common/src/R-2.1.1/include  -I/bi/common/include
-I/usr/local/
include   -fPIC  -g -O2 -c survindex3.c -o survindex3.o
gcc -I/bi/common/src/R-2.1.1/include  -I/bi/common/include
-I/usr/local/
include   -fPIC  -g -O2 -c survreg2.c -o survreg2.o
gcc -I/bi/common/src/R-2.1.1/include  -I/bi/common/include
-I/usr/local/
include   -fPIC  -g -O2 -c survreg3.c -o survreg3.o
gcc -I/bi/common/src/R-2.1.1/include  -I/bi/common/include
-I/usr/local/
include   -fPIC  -g -O2 -c survreg4.c -o survreg4.o
gcc -I/bi/common/src/R-2.1.1/include  -I/bi/common/include
-I/usr/local/
include   -fPIC  -g -O2 -c survreg5.c -o survreg5.o
gcc -shared -fPIC -Wl,-Bsymbolic -L/bi/arch/lib -L/usr/local/lib -o
surv
ival.sl agexact.o agfit2.o agfit3.o agfit5.o agfit_null.o agmart.o agmart2.o
ags
core.o agsurv1.o agsurv2.o agsurv3.o char_date.o chinv2.o chinv3.o cholesky2.o
c
holesky3.o chsolve2.o chsolve3.o cox_Rcallback.o coxdetail.o coxfit2.o
coxfit5.o
 coxmart.o coxph_wtest.o coxscho.o coxscore.o dmatrix.o doloop.o pyears1.o
pyear
s2.o pyears3.o pystep.o surv_callback.o survdiff2.o survfit2.o survfit3.o
survin
dex2.o survindex3.o survreg2.o survreg3.o survreg4.o survreg5.o   
** R
** data
**  moving datasets to lazyload DB
** inst
** preparing package for lazy loading
/bi/common/src/R-2.1.1/bin/INSTALL[325]: 3667 Memory fault(coredump)
ERROR: lazy loading failed for package 'survival'
** Removing '/bi/common/src/R-2.1.1/library/survival'
*** Error exit code 1

Stop.



My configuration is:

CPPFLAGS="-I/bi/common/include -I/usr/local/include" \
LDFLAGS="-L/bi/arch/lib -L/usr/local/lib" ./configure \
--prefix=/bi/common --exec-prefix=/bi/arch \
--disable-mbcs 2>&1

(it won't compile at all without --disable-mbcs)

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

Re: [Rd] test for readline installation fails if installation location (PR#8107)

[rpeng]

This is the kind of thing that goes in the 'config.site' file 
(which I believe is in fact documented).  The '--prefix' switch 
indicates where things should be installed.

-roger

[EMAIL PROTECTED] wrote:
> Full_Name: D Kreil
> Version: 2.1.1
> OS: HP-UX B.11.23 U ia64 0029870451 unlimited-user license
> Submission from: (NULL) (62.178.15.60)
> 
> 
> When the dependency readline is installed in a non-standard location the
> installation procedure fails.
> If using a non-standard installation location like
> 
>   --prefix=/bi/common --exec-prefix=/bi/arch
> 
> the configure script default include and library paths should adapt 
> accordingly.
> They don't (/usr/local defaults remain).
> 
> Workaround:
> 
>   CPPFLAGS=-I/bi/common/include LDFLAGS=-L/bi/arch/lib ./configure
> 
> This should not be necessary, I think.
> 
> Best regards,
> 
> D Kreil.
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 

-- 
Roger D. Peng
http://www.biostat.jhsph.edu/~rpeng/

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

[Rd] "finite" vs "R_FINITE" in colors.c (PR#8108)

[rbug05]

Full_Name: D Kreil
Version: 2.1.1
OS: HP-UX B.11.23 U ia64 0029870451 unlimited-user license
Submission from: (NULL) (62.178.15.60)


During compiliation, I get:

ld: Unsatisfied symbol "finite" in file colors.o

Fix: replace "finite" with R_FINITE in colors.c line 269.

I have, this time, searched through the R-admin.html, but not found a mention.
This is all a bit hard for me as I'm installing R as non-admin on a bare-bones
ia64 hpux system with no web browser, and a weird mix of libraries.
Nevertheless, the above seems to me like an innocent typo?

Best regards,

David.

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

Re: [Rd] efficiency of sample() with prob.

[Bo Peng]

> It seems the distribution used for your tests is maximally favourable to 
> your proposal (not uncommon in papers, but not very honest).  

I did not have time to do a thorough test. I was simply reporting what
I had done so any implied dishonesty is unfair to me.

> Changing how this is done will break the reproducibility of past programs,
> and we don't really want to introduce yet more options.  So it seems only
> worth doing when there are substantial speed gains. 

I agree that Walker's method may be slow at some cases but there is
nothing to brag about R's current method either. The bottom line is: a
bisection method will be uniformly better than the linear search
method that R uses right now. This does not qualify as 'substantial
speed gain' though.

Cheers,
Bo

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

Re: [Rd] wchar and wstring. (followup question)

[James Bullard]

Thanks for all of the help with my previous posts. This question might
expose much of my ignorance when it comes to R's memory managment and
the responsibilities of the programmer, but I thought I had better ask
rather than continue in my ignorance.

I use the following code to create a multi-byte string in R from my wide
character string in C.

int str_length;
char* cstr;
   
str_length = cel.GetAlg().size();
cstr = Calloc(str_length, char);
wcstombs(cstr, cel.GetAlg().c_str(), str_length);
SET_STRING_ELT(names, i, mkChar("Algorithm"));
SET_VECTOR_ELT(vals, i++, mkString(cstr));
Free(cstr);

My first question is: do I need the Free? I looked at some of the
examples in main/character.c, but I could not decide whether or not I
needed it. I imagined (I could not find the source for this function)
that mkString made a copy so I thought I would clean up my copy, but if
this is not the case then I would assume the Free would be wrong.

My second question is: It was pointed out to me that it would be more
natural to use this code:

SET_STRING_ELT(vals, i++, mkChar(header.GetHeader().c_str()));

instead of:

SET_VECTOR_ELT(vals, i++, mkString(header.GetHeader().c_str()));

However, the first line creates the following list element in R:



Whereas, I want it to create as the list element:

"Percentile"

Which the second example does correctly. I had previously posted about
this problem and I believe that I was advised to use the second syntax,
but maybe there is a different problem in my code. I am trying to
construct a named list in R where my first line SET_STRING_ELT sets the
name of the list element and the second sets the value where the value
can be an INTEGER, STRING or whatever.

My third question is simply, why is wcrtomb preferred, the example i
based my code of of in main/character.c used  wcstombs.


Thanks again for all of the help.

jim


Prof Brian Ripley wrote:

> On Fri, 26 Aug 2005, James Bullard wrote:
>
>> Hello all, I am writing an R interface to some C++ files which make use
>> of std::wstring classes for internationalization. Previously (when I
>> wanted to make R strings from C++ std::strings), I would do something
>> like this to construct a string in R from the results of the parse.
>>
>> SET_VECTOR_ELT(vals, i++, mkString(header.GetHeader().c_str()));
>
>
> That creates a list of one-element character vectors.  It would be more
> usual to do
>
>   SET_STRING_ELT(vals, i++, mkChar(header.GetHeader().c_str()));
>
>> However, now the call header.GetHeader().c_str() returns a pointer to
>> an array of wchar_t's. I was going to use wcstombs() to convert the
>> wchar_t* to char*, but I wanted to see if there was a similar
>> function in R for the mkString function which I had initially used
>> which deals with wchar_ts as opposed to chars.
>
>
> No (nor an analogue of mkChar).  R uses MBCS and not wchar_t
> internally (and Unix-alike systems do externally).  There is no
> wchar_t internal R type (a much-debated design decision at the time).
>
>> Also, since I have no experience with the wctombs() function I wanted
>> to ask if anyone knew if this will handle the internationilzation
>> issues from within R.
>
>
> Did you mean wcstombs or wctomb (if the latter, wcrtomb is preferred)?
> There are tens of examples in the R sources for you to consult.
>
> Note that not all R platforms support wchar_t, hence this code is
> surrounded by #ifdef SUPPORT_MBCS macros (exported in Rconfig.h for
> package writers).
>

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

Re: [Rd] "finite" vs "R_FINITE" in colors.c (PR#8108)

[ripley]

Thanks, but it is already changed in the R-devel sources.

On Mon, 29 Aug 2005 [EMAIL PROTECTED] wrote:

> Full_Name: D Kreil
> Version: 2.1.1
> OS: HP-UX B.11.23 U ia64 0029870451 unlimited-user license
> Submission from: (NULL) (62.178.15.60)
>
>
> During compiliation, I get:
>
> ld: Unsatisfied symbol "finite" in file colors.o
>
> Fix: replace "finite" with R_FINITE in colors.c line 269.
>
> I have, this time, searched through the R-admin.html, but not found a mention.
> This is all a bit hard for me as I'm installing R as non-admin on a bare-bones
> ia64 hpux system with no web browser, and a weird mix of libraries.
> Nevertheless, the above seems to me like an innocent typo?

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

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

Re: [Rd] wchar and wstring. (followup question)

[Prof Brian Ripley]

On Mon, 29 Aug 2005, James Bullard wrote:

> Thanks for all of the help with my previous posts. This question might
> expose much of my ignorance when it comes to R's memory managment and
> the responsibilities of the programmer, but I thought I had better ask
> rather than continue in my ignorance.
>
> I use the following code to create a multi-byte string in R from my wide
> character string in C.
>
> int str_length;
> char* cstr;
>
> str_length = cel.GetAlg().size();
> cstr = Calloc(str_length, char);
> wcstombs(cstr, cel.GetAlg().c_str(), str_length);
> SET_STRING_ELT(names, i, mkChar("Algorithm"));
> SET_VECTOR_ELT(vals, i++, mkString(cstr));
> Free(cstr);
>
> My first question is: do I need the Free? I looked at some of the
> examples in main/character.c, but I could not decide whether or not I
> needed it. I imagined (I could not find the source for this function)
> that mkString made a copy so I thought I would clean up my copy, but if
> this is not the case then I would assume the Free would be wrong.

Yes, nkString copies the information (via mkChar) and the Free is needed.
The source is in gram.c.

Whenever you call Calloc you need to call Free or you will have a memory 
leak.

> My second question is: It was pointed out to me that it would be more
> natural to use this code:
>
> SET_STRING_ELT(vals, i++, mkChar(header.GetHeader().c_str()));
>
> instead of:
>
> SET_VECTOR_ELT(vals, i++, mkString(header.GetHeader().c_str()));
>
> However, the first line creates the following list element in R:

Nope, it creates an element of a character vector.  The point was that it 
was more natural to use character vectors than lists of single-element 
character vectors.

> 
>
> Whereas, I want it to create as the list element:
>
> "Percentile"
>
> Which the second example does correctly. I had previously posted about
> this problem and I believe that I was advised to use the second syntax,
> but maybe there is a different problem in my code. I am trying to
> construct a named list in R where my first line SET_STRING_ELT sets the
> name of the list element and the second sets the value where the value
> can be an INTEGER, STRING or whatever.

Well, we STRING etc are macros not types, but if you want a list of mixed 
types for use at R-level, SET_VECTOR_ELT is fine.

> My third question is simply, why is wcrtomb preferred, the example i
> based my code of of in main/character.c used  wcstombs.

preferred to wctomb.  Please re-read what I wrote, and the relevant man 
pages.


>
> Thanks again for all of the help.
>
> jim
>
>
> Prof Brian Ripley wrote:
>
>> On Fri, 26 Aug 2005, James Bullard wrote:
>>
>>> Hello all, I am writing an R interface to some C++ files which make use
>>> of std::wstring classes for internationalization. Previously (when I
>>> wanted to make R strings from C++ std::strings), I would do something
>>> like this to construct a string in R from the results of the parse.
>>>
>>> SET_VECTOR_ELT(vals, i++, mkString(header.GetHeader().c_str()));
>>
>>
>> That creates a list of one-element character vectors.  It would be more
>> usual to do
>>
>>   SET_STRING_ELT(vals, i++, mkChar(header.GetHeader().c_str()));
>>
>>> However, now the call header.GetHeader().c_str() returns a pointer to
>>> an array of wchar_t's. I was going to use wcstombs() to convert the
>>> wchar_t* to char*, but I wanted to see if there was a similar
>>> function in R for the mkString function which I had initially used
>>> which deals with wchar_ts as opposed to chars.
>>
>>
>> No (nor an analogue of mkChar).  R uses MBCS and not wchar_t
>> internally (and Unix-alike systems do externally).  There is no
>> wchar_t internal R type (a much-debated design decision at the time).
>>
>>> Also, since I have no experience with the wctombs() function I wanted
>>> to ask if anyone knew if this will handle the internationilzation
>>> issues from within R.
>>
>>
>> Did you mean wcstombs or wctomb (if the latter, wcrtomb is preferred)?
>> There are tens of examples in the R sources for you to consult.
>>
>> Note that not all R platforms support wchar_t, hence this code is
>> surrounded by #ifdef SUPPORT_MBCS macros (exported in Rconfig.h for
>> package writers).
>>
>
>

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

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