Re: [Rd] unexpected behavior of `[<-` method for class unit.arithmetic

[baptiste auguie]

Dear Paul and others,

Thanks for the quick response.

2009/9/25 Paul Murrell :
> Hi
>
> The bit you found that says ...
>
> # Write "[<-.unit" methods too ??
>
> ... is the crucial bit.
>

When I figured that, I had already written up my email so I thought
I'd ask anyway from a naive user point of view (in this regard,
perhaps the help page of unit.c could mention what common methods are
not available). The results I got can be quite surprising at first.


> Would it be possible to add such a method?
>
> Almost certainly, it just needs someone to repeatedly bug the person who can
> make the change :)   Thanks for the suggestion for code BTW;  I'll take a
> look at that.

I'm afraid I won't be of much help here, I merely copied and pasted
the "[.unit" method with a minimal change that seemed to make it work
for illustrative purposes. I don't really understand unit.arithmetic
and unit in general.

> In the meantime, the fact that this has only come up once before, while
> surprising, suggests that people may have written code in a different style.

Either that or people have struggled to find their own workaround
every time. I've recently hacked a fake matrix of unit objects, where
perhaps a proper implementation would find other grateful users.
(Given a list of grobs, I needed to compute rowMax and colMax of their
size in a rectangular arrangement -- see example below, also as a
recent post on r-help).

>  Can you give a succinct example that demonstrates a situation where you
> want to assign to a subset of a unit (rather than, say, calculating values,
> setting some to 0, then building a unit from the values) ?
>

Though not as succinct as I'd like, I think the drawDetails method of
tableGrob[*] might present the problem:

drawDetails.table <- function(x, recording=TRUE){

# makeTableGrobs returns lists of grobs, and their width and height in
a rectangular layout
  lg <- with(x, makeTableGrobs(as.character(as.matrix(d)), rows, cols,
 nrow(d), ncol(d),
 equal.width = equal.width, equal.height = equal.height,
 gpar.content = gpar.content,
 gpar.col = gpar.col,
 gpar.row = gpar.row,
 gpar.fill = gpar.fill,
 gpar.rowfill = gpar.rowfill,
 gpar.colfill = gpar.colfill )  )

# now I need to add some horizontal and vertical padding to each cells,
# EXCEPT for the rownames and colnames if they are not to be shown
# whereby I convert everything to raw values, use normal vector indexing,
# and convert back to unit

  widthsv <- convertUnit(lg$widths + x$padding.h, "mm", valueOnly=TRUE)
  heightsv <- convertUnit(lg$heights + x$padding.v, "mm", valueOnly=TRUE)

  widthsv[1] <- widthsv[1] * as.numeric(x$show.rownames)
  widths <- unit(widthsv, "mm")

  heightsv[1] <- heightsv[1] * as.numeric(x$show.colnames)
  heights <- unit(heightsv, "mm")

# once this is done, I can create the layout
  cells = viewport(name="table.cells", layout =
grid.layout(lg$nrow+1, lg$ncol+1, width=widths, height=heights) )

# and place the elements
  pushViewport(cells)
  tg <- arrangeTableGrobs(lg$lgt, lg$lgf, lg$nrow, lg$ncol, lg$widths,
lg$heights,
  padding.h = x$padding.h, padding.v = x$padding.v,
  separator=x$separator, show.box=x$show.box,
  show.csep=x$show.csep, show.rsep=x$show.rsep)
  upViewport()
}

Of course I could make the calculation of adding padding to the cells
earlier in the chain (in makeTableGrobs) but it's not really its
place.

Best,

baptiste

[*]: http://code.google.com/p/gridextra/source/browse/trunk/R/tableGrob.r

to be run as,
either,

library(grid)
source("http://gridextra.googlecode.com/svn/trunk/R/grob-utils.r";)
source("http://gridextra.googlecode.com/svn/trunk/R/tableGrob.r";)

grid.table(head(iris))

or simply,

Install http://gridextra.googlecode.com/files/gridextra_0.3.tar.gz

library(gridextra)
example(tableGrob)

> Paul
>
>
> baptiste auguie wrote:
>>
>> Dear list,
>>
>> Consider the following,
>>
>> library(grid)
>>
>> w = unit.c(unit(1, "in"), unit(2, "in"))
>> w2 = w + unit(1, "mm")
>>
>> w[2] <- 0
>> w2[2] <- 0
>>
>> convertUnit(w, "mm")
>> #[1] 25.4mm 0mm
>> convertUnit(w2, "mm")
>> #Error in grid.Call("L_convert", x, as.integer(whatfrom),
>> as.integer(whatto),  :
>> #  INTEGER() can only be applied to a 'integer', not a 'NULL'
>>
>> The last line fails, as the naive replacement has destroyed the
>> structure of w2 instead of having assigned a value of 0 to the second
>> unit element.
>>
>> I've also tried,
>>
>> w = unit.c(unit(1, "in"), unit(2, "in"))
>> w2 = w + unit(1, "mm")
>> w2[[2]][2] <- 0
>>
>> but this time, if the structure is licit, it's the result that's not
>> as I intended:
>>
>> convertUnit(w2,"mm")
>> #[1] 26.4mm 1mm
>>
>> My limited understanding is that an object of class unit.arithmetic is
>> waiting until the last moment to actually perform its operation,
>> stored in a tree-like structure. With this premise, I can't think of a
>> good way to modify one element of a list of unit elements

[Rd] build time dependency

[Romain Francois]

Hello,

Is there such thing as a build time dependency between packages : 
package B needs package A so that it can build, but once built it lives 
without it.


For example depending on the ant package to compile java code, or depend 
on roxygen to roxygenize the code, ...


Adding roxygen to Depends works, but then the installed package does not 
depend on it and therefore loads it for nothing. Maybe I can remove 
roxygen from the Depends as part of the ./configure[.win] ...


Romain

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc
|- http://tr.im/yw8E : New R package : sos
`- http://tr.im/y8y0 : search the graph gallery from R

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

[Rd] Collision between difftime and ggplot2.

[Allen S. Rout]

It seems that there are several folks Out There with an itch to
scratch with respect to difftimes.

http://article.gmane.org/gmane.comp.lang.r.devel/19223/match=difftime

http://article.gmane.org/gmane.comp.lang.r.devel/18441/match=difftime

http://article.gmane.org/gmane.comp.lang.r.devel/10882/match=difftime

http://article.gmane.org/gmane.comp.lang.r.devel/11675/match=difftime

and I might be developing such an itch too.


What would the R devel community want out of some one, or some group,
attempting to fix some of these?  Difftime seems just functional
enough to be an attractive nuisance.



- Allen S. Rout

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

Re: [Rd] Collision between difftime and ggplot2.

[hadley wickham]

Hi Allen,

I've been working on this problem (among others) with a grad student
this summer.  You can see our work here -
http://github.com/hadley/lubridate/ - particularly in durations.r and
ops.durations.r.

Hadley

On Fri, Sep 25, 2009 at 8:45 AM, Allen S. Rout  wrote:
>
> It seems that there are several folks Out There with an itch to
> scratch with respect to difftimes.
>
> http://article.gmane.org/gmane.comp.lang.r.devel/19223/match=difftime
>
> http://article.gmane.org/gmane.comp.lang.r.devel/18441/match=difftime
>
> http://article.gmane.org/gmane.comp.lang.r.devel/10882/match=difftime
>
> http://article.gmane.org/gmane.comp.lang.r.devel/11675/match=difftime
>
> and I might be developing such an itch too.
>
>
> What would the R devel community want out of some one, or some group,
> attempting to fix some of these?  Difftime seems just functional
> enough to be an attractive nuisance.
>
>
>
> - Allen S. Rout
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
http://had.co.nz/

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

Re: [Rd] unexpected behavior of `[<-` method for class unit.arithmetic

[baptiste auguie]

Further to my previous message, I just dug this in lattice/R/layout.R :


rearrangeUnit <- function(x, pos, u)
{
lx <- length(x)
if (lx == 1)
u
else if (pos == 1)
unit.c(u, x[(pos+1):lx])
else if (pos == lx)
unit.c(x[1:(pos-1)], u)
else
unit.c(x[1:(pos-1)], u, x[(pos+1):lx])
}


w = unit.c(unit(1, "in"), unit(2, "in"))
w2 = w + unit(1, "mm")

rearrangeUnit(w2, 2, unit(0, "mm"))

Definitely a much prettier trick than mine.


Best,

baptiste




2009/9/25 baptiste auguie :
> Dear Paul and others,
>
> Thanks for the quick response.
>
> 2009/9/25 Paul Murrell :
>> Hi
>>
>> The bit you found that says ...
>>
>> # Write "[<-.unit" methods too ??
>>
>> ... is the crucial bit.
>>
>
> When I figured that, I had already written up my email so I thought
> I'd ask anyway from a naive user point of view (in this regard,
> perhaps the help page of unit.c could mention what common methods are
> not available). The results I got can be quite surprising at first.
>
>
>> Would it be possible to add such a method?
>>
>> Almost certainly, it just needs someone to repeatedly bug the person who can
>> make the change :)   Thanks for the suggestion for code BTW;  I'll take a
>> look at that.
>
> I'm afraid I won't be of much help here, I merely copied and pasted
> the "[.unit" method with a minimal change that seemed to make it work
> for illustrative purposes. I don't really understand unit.arithmetic
> and unit in general.
>
>> In the meantime, the fact that this has only come up once before, while
>> surprising, suggests that people may have written code in a different style.
>
> Either that or people have struggled to find their own workaround
> every time. I've recently hacked a fake matrix of unit objects, where
> perhaps a proper implementation would find other grateful users.
> (Given a list of grobs, I needed to compute rowMax and colMax of their
> size in a rectangular arrangement -- see example below, also as a
> recent post on r-help).
>
>>  Can you give a succinct example that demonstrates a situation where you
>> want to assign to a subset of a unit (rather than, say, calculating values,
>> setting some to 0, then building a unit from the values) ?
>>
>
> Though not as succinct as I'd like, I think the drawDetails method of
> tableGrob[*] might present the problem:
>
> drawDetails.table <- function(x, recording=TRUE){
>
> # makeTableGrobs returns lists of grobs, and their width and height in
> a rectangular layout
>  lg <- with(x, makeTableGrobs(as.character(as.matrix(d)), rows, cols,
>         nrow(d), ncol(d),
>         equal.width = equal.width, equal.height = equal.height,
>         gpar.content = gpar.content,
>         gpar.col = gpar.col,
>         gpar.row = gpar.row,
>         gpar.fill = gpar.fill,
>         gpar.rowfill = gpar.rowfill,
>         gpar.colfill = gpar.colfill )  )
>
> # now I need to add some horizontal and vertical padding to each cells,
> # EXCEPT for the rownames and colnames if they are not to be shown
> # whereby I convert everything to raw values, use normal vector indexing,
> # and convert back to unit
>
>  widthsv <- convertUnit(lg$widths + x$padding.h, "mm", valueOnly=TRUE)
>  heightsv <- convertUnit(lg$heights + x$padding.v, "mm", valueOnly=TRUE)
>
>  widthsv[1] <- widthsv[1] * as.numeric(x$show.rownames)
>  widths <- unit(widthsv, "mm")
>
>  heightsv[1] <- heightsv[1] * as.numeric(x$show.colnames)
>  heights <- unit(heightsv, "mm")
>
> # once this is done, I can create the layout
>  cells = viewport(name="table.cells", layout =
>    grid.layout(lg$nrow+1, lg$ncol+1, width=widths, height=heights) )
>
> # and place the elements
>  pushViewport(cells)
>  tg <- arrangeTableGrobs(lg$lgt, lg$lgf, lg$nrow, lg$ncol, lg$widths,
> lg$heights,
>          padding.h = x$padding.h, padding.v = x$padding.v,
>          separator=x$separator, show.box=x$show.box,
>          show.csep=x$show.csep, show.rsep=x$show.rsep)
>  upViewport()
> }
>
> Of course I could make the calculation of adding padding to the cells
> earlier in the chain (in makeTableGrobs) but it's not really its
> place.
>
> Best,
>
> baptiste
>
> [*]: http://code.google.com/p/gridextra/source/browse/trunk/R/tableGrob.r
>
> to be run as,
> either,
>
> library(grid)
> source("http://gridextra.googlecode.com/svn/trunk/R/grob-utils.r";)
> source("http://gridextra.googlecode.com/svn/trunk/R/tableGrob.r";)
>
> grid.table(head(iris))
>
> or simply,
>
> Install http://gridextra.googlecode.com/files/gridextra_0.3.tar.gz
>
> library(gridextra)
> example(tableGrob)
>
>> Paul
>>
>>
>> baptiste auguie wrote:
>>>
>>> Dear list,
>>>
>>> Consider the following,
>>>
>>> library(grid)
>>>
>>> w = unit.c(unit(1, "in"), unit(2, "in"))
>>> w2 = w + unit(1, "mm")
>>>
>>> w[2] <- 0
>>> w2[2] <- 0
>>>
>>> convertUnit(w, "mm")
>>> #[1] 25.4mm 0mm
>>> convertUnit(w2, "mm")
>>> #Error in grid.Call("L_convert", x, as.integer(whatfrom),
>>> as.integer(whatto),  :
>>> #  INTEGER() can only be applied to a 'in

[Rd] Problem with dgamma function.

[Charles Danko]

Hi, All,

I am getting some funny results trying to use R's built in
distribution functions.

In R:
> dgamma(4.775972,1.37697964405418, 0.106516604930466)
[1] 0.05585295
> dgamma(4.775972,1.37697964405418, 0.106516604930466,TRUE)  ### THIS IS JUST 
> WRONG!
[1] 0.01710129
> log(dgamma(4.775972,1.37697964405418, 0.106516604930466))
[1] -2.885033
>

In C:
dgamma(4.775972,1.37697964405418, 0.106516604930466,TRUE)
Returns: -41.046764

dgamma(4.775972,1.37697964405418, 0.106516604930466,FALSE)
Returns: 0.00

SESSION INFO:
R version 2.9.0 (2009-04-17)
x86_64-unknown-linux-gnu

Any indication of what I may be doing wrong is very much appreciated.

Thanks,
Charles


-- 
Postdoctoral Fellow
Cornell University
169 Biotechnology Building
Ithaca, NY 14853

Phone (Lab, 467 Biotech Bldg.): 607-255-4743
E-mail: dan...@gmail.com

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

Re: [Rd] Problem with dgamma function.

[Peter Dalgaard]

Charles Danko wrote:

Hi, All,

I am getting some funny results trying to use R's built in
distribution functions.

In R:

dgamma(4.775972,1.37697964405418, 0.106516604930466)

[1] 0.05585295

dgamma(4.775972,1.37697964405418, 0.106516604930466,TRUE)  ### THIS IS JUST 
WRONG!

[1] 0.01710129

log(dgamma(4.775972,1.37697964405418, 0.106516604930466))

[1] -2.885033

In C:
dgamma(4.775972,1.37697964405418, 0.106516604930466,TRUE)
Returns: -41.046764

dgamma(4.775972,1.37697964405418, 0.106516604930466,FALSE)
Returns: 0.00

SESSION INFO:
R version 2.9.0 (2009-04-17)
x86_64-unknown-linux-gnu

Any indication of what I may be doing wrong is very much appreciated.


Not reading the documentation?

> args(dgamma)
function (x, shape, rate = 1, scale = 1/rate, log = FALSE)
NULL
> dgamma(4.775972,1.37697964405418,, 0.106516604930466,TRUE)
[1] -41.04676
> dgamma(4.775972,1.37697964405418,, 0.106516604930466,FALSE)
[1] 1.491480e-18
> log(dgamma(4.775972,1.37697964405418,, 0.106516604930466,FALSE))
[1] -41.04676
> dgamma(4.775972,1.37697964405418,0.106516604930466,log=TRUE)
[1] -2.885033
>


Thanks,
Charles





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

[Rd] Wish for stripchart to handle pch %in% 21:25 with bg

[Jean lobry]

Dear R-Devel,

consider :

###
x <- round(rnorm(50))
stripchart(x,  pch = 21, col = "black", bg = "pink", method = "jitter")
points(0.5, 1, pch = 21, col = "black", bg = "pink", cex = 2)
###

Under R 2.9.0 the internal color of the single point produced by points()
was honored but not the color of the points produced by stripchart().

My wish is just that the "bg" parameter for internal point color
should not be lost by the stripchart() function.

This looks somewhat similar for the entry in NEWS for R 2.7.2 stating
that:

o   stripchart() now passes '...' to title() (as well as to
plot.default() and axis()). (Wish of PR#12202)

A simple fix that works for me is to forward the argument ... to
the function points() in graphics:::stripchart.default(), but I
know nothing about potential side effects.

Thanks for your amazing work,

Pr. Jean Lobry
--
Jean R. Lobry(lo...@biomserv.univ-lyon1.fr)
Laboratoire BBE-CNRS-UMR-5558, Univ. C. Bernard - LYON I,
43 Bd 11/11/1918, F-69622 VILLEURBANNE CEDEX, FRANCE
allo  : +33 472 43 27 56 fax: +33 472 43 13 88
http://pbil.univ-lyon1.fr/members/lobry/

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

Re: [Rd] crash with NAs in subscripted assignment of a raw vector

[Hervé Pagès]

Seth Falcon wrote:

2009/9/24 Hervé Pagès :

 > x <- charToRaw("ABCDEFGx")
 > x[c(1:3, NA, 6)] <- x[8]

  *** caught segfault ***
 address 0x8402423f, cause 'memory not mapped'


Thanks for the report.  I have a fix which I will commit after some testing.



Thanks Seth!  H.

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

Re: [Rd] R + C + Lapack toy regression example

[Douglas Bates]

On Thu, Sep 24, 2009 at 2:09 PM, Vinh Nguyen  wrote:
> On Thu, Sep 24, 2009 at 11:49 AM, Simon Urbanek
>  wrote:
>> As Doug pointed out you don't want to be using .C(). As for matrix
>> manipulations - they are usually done directly on the objects which are
>> vectors stored in column-major order.
>
> i meant .Call().   also, sorry for the poor word choice, i meant
> matrix computations, not matrix manipulations.  i guess i just want
> some recommendations for future references on what C library to use if
> i were doing something like re-implement linear regression
> (hypothetically speaking).  i assumed it would be lapack.  is this the
> recommended approach?

Yes, Lapack would be the recommended code for numerical linear
algebra.  If happens to be Fortran code but it is callable from C/C++.
 One big advantage of Lapack (besides its having been written by some
of the top people in the field and being very well tested) is that it
uses the BLAS (Basic Linear Algebra Subroutines) as levels 1, 2 and 3.

However, implementing linear models software is more subtle than just
the numerical part.  In fact, least squares calculations are (I think)
the only part of R where Linpack is used instead of  Lapack, by
default.  Most of the time the symbolic analysis of a linear model
formula done in R produces a model matrix with full column rank but
under some circumstances it doesn't.  (The easiest such case to
explain is a two-way layout with missing cells.)  The way these cases
are handled is to use a special pivoting algorithm in the
decomposition.  Neither Linpack nor Lapack provided a pivoting scheme
so early in the R project Ross modified the Linpack version of the QR
decomposition to use such a scheme.  It is still the one in use.

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

[Rd] Compatibility of external C code across platforms

[Murray Efford]

A package I have written makes considerable use of external C code.  There 
appear to be no problems building a Windows binary with the GNU C compiler, but 
now I would like to make the package available for other platforms.  A 
stringent check of the code with the gcc options '-Wall -pedantic' flags many 
nested functions and variable-length arrays that are not allowed in ISO C.  Is 
it essential that distributed C source code for R packages conforms to ISO C in 
this respect?  I'm working in Windows XP with R2.9.2 and Rtools 2.9.

[Incidentally, when I use a makevars.win file to include these gcc options in 
Rcmd build etc. the problem with variable-length arrays is not flagged; maybe 
my command-line gcc is a different version from that in Rtools]

Murray Efford
University of Otago
Dunedin, New Zealand
murray.eff...@otago.ac.nz

[[alternative HTML version deleted]]

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