Re: [Rd] col2rgb, factors & documentation

2013-06-10 Thread Prof Brian Ripley 

On 07/06/2013 18:59, Bryan Hanson wrote:

Hello Core Folk.


This is the R-devel list.  Bug reports/enhancement suggestions should go 
to bugs.r-project.org.



Quite by accident I discovered today that col2rgb, when fed factors, acts on 
the integer representation of those factors:

td <- as.factor(rainbow(5)) # not how I discovered the issue!
td
res <- col2rgb(td)
res
# but
col2rgb("#FFFF") # this is td[1] but does not produce the same answer
res[,1]
# moreover
as.integer(td)
col2rgb(5) # the integer value of the first level
# and this is res[,1] which by the way is palette()[5], aka "cyan"

?col2rgb says:
col 
vector of any of the three kinds of R color specifications, i.e., either a color name (as listed by 
colors()), a hexadecimal string of the form "#rrggbb" or "#rrggbbaa" (see rgb), 
or a positive integer i meaning palette()[i]. Non-numeric values are coerced to character.

So in the example the factor is being taken as its integer representation, and 
finding an integer as the input value, col2rgb goes to palette().

Perhaps this is a nuance that belongs in the documentation?


It has been like that since at least R 2.0.0.  I'll rephrase the help 
and change to coercion to character.





Thanks, Bryan
***
Bryan Hanson
Professor of Chemistry & Biochemistry
DePauw University

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




--
Brian D. Ripley,  rip...@stats.ox.ac.uk
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] R CMD INSTALL and file permission settings

2013-06-10 Thread Martin Maechler 
> Dirk Eddelbuettel 
> on Sat, 8 Jun 2013 11:22:56 -0500 writes:

> Summary:   

> The directory /usr/local/lib/R/site-library can be used for site-wide
> multi-user installations of R.  

> This is even the default on Debian and Ubuntu (following a suggestion by
> Kurt and Fritz a decade ago over beers -- what could be better).  However,
> R enforces wrong permissions on directories and files there (removing
> group-write) which effectively defeats this purpose, and breaks multiuser
> installation:  if Tom, Dick and Harry are members of group 'r-users', each
> one can install in the directory, but neither can _upgrade_ a package
> installed by one of the others.  

> I would like to correct this.


> Details:   

[..]


> Proposal:

> Add a new option() [with a to-be-determined name] which, if enabled, turns
> on group-write modes for files and directories, ie "664" and "775".  

[.]

> I would be happy to write such a patch (including documentation updates) 
if
> someone from R Core can signal willigness to look at it.

"signal!"
:-)

Regards, 
Martin

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

Re: [Rd] dmvnorm

2013-06-10 Thread Simon Urbanek 

On Jun 6, 2013, at 2:06 AM, Joshua N Pritikin wrote:

> Summary:
> 
> + I am writing an R extension that needs to call dmvnorm more than 
> 10,000 times during a model fitting computation.
> 
> + My extension uses openmp for parallel execution.
> 
> + As of R 3.0, it is no longer permitted for threads to call the R 
> interpreter because there is a stack overflow check that always trips 
> because the thread's stack is different from what R is expecting.
> 

You can call the interpreter from threads, you just have to make sure your 
access is properly synchronized and you disable the stack check. This is not 
new on R 3.0, this was always the case. However this is irrelevant to what you 
are describing above, because it doesn't make any sense to serial code in 
OpenMP.


> + Therefore, I need a C version of dmvnorm.
> 

C version alone is not sufficient, if you want to use it in threads, you would 
need a thread-safe version. This means that you really need your own version, 
so I don't think adding C version of dmvnorm to R has necessarily any bearing 
to what you are trying to do.

Cheers,
Simon



> + The mvtnorm package maintainer is not interested in 
> R_RegisterCCallable.
> 
> Can a C version of dmvnorm get added to the R core?
> 
> -- 
> Joshua N. Pritikin
> Department of Psychology
> University of Virginia
> 485 McCormick Rd, Gilmer Hall Room 102
> Charlottesville, VA 22904
> http://people.virginia.edu/~jnp3bc
> 
> From: Torsten Hothorn 
> Date: June 5, 2013 9:26:03 AM EDT
> To: Joshua N Pritikin 
> Subject: Re: dmvnorm
> 
> 
> 
> On Mon, 3 Jun 2013, Joshua N Pritikin wrote:
> 
>> On Mon, Jun 03, 2013 at 03:24:54PM +0200, Torsten Hothorn wrote:
>>> On Sat, 1 Jun 2013, Joshua N Pritikin wrote:
 On Fri, May 31, 2013 at 07:22:52PM +0200, Torsten Hothorn wrote:
> - what exactly is the advantage of using C? How much time / memory can be
> saved?
 
 I bet the difference will only appear in micro-benchmarks. There is
 probably no real world impact.
 
 As I said, the main reason I wrote this is because I need to call
 dmvnorm from C.
>>> 
>>> I see -- so now that you have the C code ready, why do we need it to
>>> be part of mvtnorm?
>> 
>> I want to share. What if somebody else has the same need?
> 
> sure, but interfacing C code from other packages is always troublesome (at 
> least this is my experience). I can't see any advantage for mvtnorm, so I 
> think one should put the code somewhere else.
> 
>> 
>> Should I submit it to the R core?
>> 
> 
> I suggest that, yes. Maybe R core is keen to add the multivariate normal 
> density to R's C API. This would be the easiest way to make your code 
> accessible.
> 
> Best,
> 
> Torsten
> 
>> -- 
>> Joshua N. Pritikin
>> Department of Psychology
>> University of Virginia
>> 485 McCormick Rd, Gilmer Hall Room 102
>> Charlottesville, VA 22904
>> http://people.virginia.edu/~jnp3bc
>> 
> 
> 
> __
> 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] load/unload segfault puzzle

2013-06-10 Thread Ben Bolker 

  Dear r-devel readers,

  I have a pretty deep problem with package loading and unloading in
the development version of the lme4 package
; it's not boiled down to a properly
minimal example yet (this has been difficult), but I am posting anyway
in the hopes that someone has ideas about how to proceed farther,
since I'm nearly stumped. Apologies in advance for the long post.

   EXECUTIVE SUMMARY: after one cycle of loading, testing (e.g. by
running example(lmer)) and unloading lme4, then loading and unloading
the nlme package, re-loading and exercising lme4 becomes very
unstable, leading eventually to a segmentation fault.  More detail is
available at  .  Because it's
a segmentation fault, exactly _where_ the crash happens varies a bit
according to platform and precise incantation, but it seems I can
always get a segfault eventually.

  We had previously forgotten to write a .onUnload() function to call
library.dynam.unload() [it's not entirely clear to me why R handles
dynamic loading automatically when there is a useDynLib() in the
NAMESPACE, but not unloading: does anyone know if this is
intentional?]; before we had the appropriate unloading hook, instead
of segfaults we got errors about objects from the DLL not being found.

  The package has many complexities that might make it an especially
tough case: it uses reference classes as well as making use of the
Rcpp and RcppEigen packages ...

  I have tried running under valgrind and have seen what appear to be
memory leaks but no memory access errors. The beginning and end of the
valgrind output are appended below -- I can send the full output if
anyone wants to see it ...

  I plan to continue to try to isolate the problem by (1) minimizing
the amount of package-exercising code run between loading and
unloading; (2) trying to create a minimal version of the package. In
the meantime if anyone can think of any shortcuts or clever
diagnostics I would love to hear about it ...

  thanks
Ben Bolker


--24640-- Valgrind options:
--24640----suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp
--24640---v
--24640----leak-check=full

==24640== LEAK SUMMARY:
==24640==definitely lost: 80 bytes in 2 blocks
==24640==indirectly lost: 240 bytes in 20 blocks
==24640==  possibly lost: 56,014,306 bytes in 32,200 blocks
==24640==still reachable: 11,032,257 bytes in 993 blocks
==24640== suppressed: 0 bytes in 0 blocks
==24640== Reachable blocks (those to which a pointer was found) are
not shown.
==24640== To see them, rerun with: --leak-check=full --show-reachable=yes
==24640==
==24640== ERROR SUMMARY: 2493 errors from 2493 contexts (suppressed:
151 from 11)
--24640--
--24640-- used_suppression:151 dl-hack3-cond-1
==24640==
==24640== ERROR SUMMARY: 2493 errors from 2493 contexts (suppressed:
151 from 11)

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