[Rd] bug in barplot.default (graphics) (PR#11585)

[c . beale]

There seems to be a minor bug in barplot.default when used with log scale w=
here one or more values is NA:

dat <- matrix(1:25, 5)
dat[2,3] <- NA
barplot(dat, beside =3D T)   #Plots and appropriate barplot with gaps for m=
issing data
barplot(dat, beside =3D T, log =3D "y")
#Error in if (min(height + offset) <=3D 0) stop("log scale error: at least =
one 'height + offset' value <=3D 0") :
#  missing value where TRUE/FALSE needed

This is easily corrected by adding na.rm =3D TRUE to this logical test and =
to the calculation of rectbase where min() is used, as per code below

Best wishes,

Colin

sessionInfo()
R version 2.7.0 (2008-04-22)=20
i386-pc-mingw32=20

locale:
LC_COLLATE=3DEnglish_United Kingdom.1252;LC_CTYPE=3DEnglish_United Kingdom.=
1252;LC_MONETARY=3DEnglish_United Kingdom.1252;LC_NUMERIC=3DC;LC_TIME=3DEng=
lish_United Kingdom.1252

attached base packages:
[1] stats graphics  grDevices datasets  tcltk utils methods=20=
=20
[8] base=20=20=20=20=20

other attached packages:
[1] debug_1.1.0mvbutils_1.1.1 svSocket_0.9-5 svIO_0.9-5 R2HTML_1.58=
=20=20=20
[6] svMisc_0.9-5   svIDE_0.9-5=20=20=20

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


barplot.default <- function (height, width =3D 1, space =3D NULL, names.arg=
 =3D NULL,
legend.text =3D NULL, beside =3D FALSE, horiz =3D FALSE, density =3D NU=
LL,
angle =3D 45, col =3D NULL, border =3D par("fg"), main =3D NULL,
sub =3D NULL, xlab =3D NULL, ylab =3D NULL, xlim =3D NULL, ylim =3D NUL=
L,
xpd =3D TRUE, log =3D "", axes =3D TRUE, axisnames =3D TRUE, cex.axis =
=3D par("cex.axis"),
cex.names =3D par("cex.axis"), inside =3D TRUE, plot =3D TRUE,
axis.lty =3D 0, offset =3D 0, add =3D FALSE, ...)
{
if (!missing(inside))
.NotYetUsed("inside", error =3D FALSE)
if (is.null(space))
space <- if (is.matrix(height) && beside)
c(0, 1)
else 0.2
space <- space * mean(width)
if (plot && axisnames && is.null(names.arg))
names.arg <- if (is.matrix(height))
colnames(height)
else names(height)
if (is.vector(height) || (is.array(height) && (length(dim(height)) =3D=
=3D
1))) {
height <- cbind(height)
beside <- TRUE
if (is.null(col))
col <- "grey"
}
else if (is.matrix(height)) {
if (is.null(col))
col <- grey.colors(nrow(height))
}
else stop("'height' must be a vector or a matrix")
if (is.logical(legend.text))
legend.text <- if (legend.text && is.matrix(height))
rownames(height)
stopifnot(is.character(log))
logx <- logy <- FALSE
if (log !=3D "") {
logx <- length(grep("x", log)) > 0L
logy <- length(grep("y", log)) > 0L
}
if ((logx || logy) && !is.null(density))
stop("Cannot use shading lines in bars when log scale is used")
NR <- nrow(height)
NC <- ncol(height)
if (beside) {
if (length(space) =3D=3D 2)
space <- rep.int(c(space[2], rep.int(space[1], NR -
1)), NC)
width <- rep(width, length.out =3D NR)
}
else {
width <- rep(width, length.out =3D NC)
}
offset <- rep(as.vector(offset), length.out =3D length(width))
delta <- width/2
w.r <- cumsum(space + width)
w.m <- w.r - delta
w.l <- w.m - delta
log.dat <- (logx && horiz) || (logy && !horiz)
if (log.dat) {
if (min(height + offset, na.rm =3D T) <=3D 0)
stop("log scale error: at least one 'height + offset' value <=
=3D 0")
if (logx && !is.null(xlim) && min(xlim) <=3D 0)
stop("log scale error: 'xlim' <=3D 0")
if (logy && !is.null(ylim) && min(ylim) <=3D 0)
stop("log scale error: 'ylim' <=3D 0")
rectbase <- if (logy && !horiz && !is.null(ylim))
ylim[1]
else if (logx && horiz && !is.null(xlim))
xlim[1]
else 0.9 * min(height, na.rm =3D T)
}
else rectbase <- 0
if (!beside)
height <- rbind(rectbase, apply(height, 2, cumsum))
rAdj <- offset + (if (log.dat)
0.9 * height
else -0.01 * height)
delta <- width/2
w.r <- cumsum(space + width)
w.m <- w.r - delta
w.l <- w.m - delta
if (horiz) {
if (is.null(xlim))
xlim <- range(rAdj, height + offset, na.rm =3D TRUE)
if (is.null(ylim))
ylim <- c(min(w.l), max(w.r))
}
else {
if (is.null(xlim))
xlim <- c(min(w.l), max(w.r))
if (is.null(ylim))
ylim <- range(rAdj, height + offset, na.rm =3D TRUE)
}
if (beside)
w.m <- matrix(w.m, ncol =3D NC)
if (plot) {
opar <- if (horiz)
par(xaxs =3D "i", xpd =3D xpd)
else par(yaxs =3D "i", xpd =3D xpd)
on.exit(par(opar))
if (!add) {
plot.new()
plot.window(xlim, ylim, log =3D log, ...)
}
xyrect <- function(x1, y1, x2, y2, horizon

[Rd] prevent `R CMD INSTALL' from reading `.Rprofile'

[Joerg van den Hoff]

I tripped over the following problem:

due  to  (my?) unresolved problems with cairo graphics under
MacOS (graphic window blocks unrecoverably)  I  modified  my
`.Rprofile'  to  issue `X11(type =  "Xlib")`   on each R
startup (as a workaround to automatic opening of  a  `cairo'
device when issuing a plotting command).

I  now  noted  that  `R  CMD  INSTALL'   obviously processes
.Rprofile since the graphics window pops  up  every  time  I
install a package.

I want to avoid this, but options, notably

--no-site-file 
--no-init-file

are ignored when using `R CMD' (yes: as stated in the help).

question:   could   this  behaviour  be  changed,  at  least
concerning the above mentioned options? or is there  another
way to avoid processing/sourcing of .Rprofile?

regards, 

joerg


ps: R 2.7.0, Mac OS 10.4.11. (PPC)

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

Re: [Rd] prevent `R CMD INSTALL' from reading `.Rprofile'

[Simon Urbanek]

On Jun 5, 2008, at 7:41 AM, Joerg van den Hoff wrote:


I tripped over the following problem:

due  to  (my?) unresolved problems with cairo graphics under
MacOS (graphic window blocks unrecoverably)  I  modified  my
`.Rprofile'  to  issue `X11(type =  "Xlib")`   on each R
startup (as a workaround to automatic opening of  a  `cairo'
device when issuing a plotting command).



That is not a good work-around (you are always forcing a device to  
open). You should consider using

grDevices::X11.options(type="Xlib")
instead.

Cheers,
Simon




I  now  noted  that  `R  CMD  INSTALL'   obviously processes
.Rprofile since the graphics window pops  up  every  time  I
install a package.

I want to avoid this, but options, notably

--no-site-file
--no-init-file

are ignored when using `R CMD' (yes: as stated in the help).

question:   could   this  behaviour  be  changed,  at  least
concerning the above mentioned options? or is there  another
way to avoid processing/sourcing of .Rprofile?

regards,

joerg


ps: R 2.7.0, Mac OS 10.4.11. (PPC)

__
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] RFC: Add 'postinstall' hook to R CMD INSTALL ?

[Dirk Eddelbuettel]

I have been mulling over an idea I had meant to flesh out with a prototype
but haven't gotten around to.   So here it goes in the abstract without
working code:


What:  Extend 'R CMD INSTALL' to also work on sources that are not strictly
   CRAN packages

Why:  'R CMD INSTALL' is very good and very successful for CRAN packages. It
  has solved most issues related to configure, make, ... etc by relying
  on pre-computed and stored values.

  CRAN is also very good as a mirror network to distribute content that
  is easy to obtain by useRs.
   
  So there are cases where I'd like to use CRAN / R CMD INSTALL to work
  on non-package code. Two case are

i)  littler which is easy to 'configure; make; make install' but 
would want to live in $PREFIX/bin -- and I need to copy it there

ii) RCpp which is a library / glue code making live easier for C++
code to interface with R; also easy to configure but I'd then
libRcpp.{so,a} to be in $PREFIX/bin -- and I need to copy it
there

How:  Similar to 'cleanup' we could have a script 'postinstall' in the
  top-level directory, and if present, R would execute it.


As I'm the one with the itch, I'd be happy to work on code towards
implementing this -- but before I go overboard with it, I'd love to hear
comments, suggestions, questions, ...  It is worthwhile? Is it feasible?
What did I overlook?

Thanks, Dirk

-- 
Three out of two people have difficulties with fractions.

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

Re: [Rd] prevent `R CMD INSTALL' from reading `.Rprofile'

[Joerg van den Hoff]

On Thu, Jun 05, 2008 at 08:57:58AM -0400, Simon Urbanek wrote:
> 
> On Jun 5, 2008, at 7:41 AM, Joerg van den Hoff wrote:
> 
> >I tripped over the following problem:
> >
> >due  to  (my?) unresolved problems with cairo graphics under
> >MacOS (graphic window blocks unrecoverably)  I  modified  my
> >`.Rprofile'  to  issue `X11(type =  "Xlib")`   on each R
> >startup (as a workaround to automatic opening of  a  `cairo'
> >device when issuing a plotting command).
> >
> 
> That is not a good work-around (you are always forcing a device to  
> open). You should consider using

yes, I know...

> grDevices::X11.options(type="Xlib")
> instead.

did'nt  know  this  function. this is of course much better.
thanks a lot!

as  an  aside: after pestering the r-mac list two times with
my cairo problem (blocking) I won't do it a third time  ;-).
nevertheless  I'd  like  to  ask  directly:  is  this  issue
recognized as "real" (at least  1-2  people  apart  from  me
reported  it)?   is their any idea it what direction I could
search for the reason (concering configuration of  R  and/or
my machine)?

regards,

joerg


> 
> Cheers,
> Simon
> 
> 
> 
> >I  now  noted  that  `R  CMD  INSTALL'   obviously processes
> >.Rprofile since the graphics window pops  up  every  time  I
> >install a package.
> >
> >I want to avoid this, but options, notably
> >
> >--no-site-file
> >--no-init-file
> >
> >are ignored when using `R CMD' (yes: as stated in the help).
> >
> >question:   could   this  behaviour  be  changed,  at  least
> >concerning the above mentioned options? or is there  another
> >way to avoid processing/sourcing of .Rprofile?
> >
> >regards,
> >
> >joerg
> >
> >
> >ps: R 2.7.0, Mac OS 10.4.11. (PPC)
> >
> >__
> >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] qf with infinite df

[Simone Giannerini]

Dear all,

I found the following behaviour

> rf(5,Inf,Inf)
[1] 1 1 1 1 1

but

> qf(0.1,Inf,Inf)
[1] NaN
Warning messages:
1: In qf(0.1, Inf, Inf) : value out of range in 'lgamma'
2: In qf(p, df1, df2, lower.tail, log.p) : NaNs produced


incidentally,


> pf(1.01,Inf,Inf)
[1] 1
> pf(1.0001,Inf,Inf)
[1] 0.5

Is this the expected behaviour?

Thanks

Simone

> R.version
   _
platform   i386-pc-mingw32
arch   i386
os mingw32
system i386, mingw32
status Patched
major  2
minor  7.0
year   2008
month  04
day22
svn rev45451
language   R
version.string R version 2.7.0 Patched (2008-04-22 r45451)

platform   x86_64-unknown-linux-gnu
arch   x86_64
os linux-gnu
system x86_64, linux-gnu
status Patched
major  2
minor  6.1
year   2008
month  01
day17
svn rev44036
language   R
version.string R version 2.6.1 Patched (2008-01-17 r44036)

__

Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/
__

[[alternative HTML version deleted]]

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

Re: [Rd] qf with infinite df

[Prof Brian Ripley]

On Thu, 5 Jun 2008, Simone Giannerini wrote:


Dear all,

I found the following behaviour


rf(5,Inf,Inf)

[1] 1 1 1 1 1

but


qf(0.1,Inf,Inf)

[1] NaN
Warning messages:
1: In qf(0.1, Inf, Inf) : value out of range in 'lgamma'
2: In qf(p, df1, df2, lower.tail, log.p) : NaNs produced


Could do better here.


incidentally,



pf(1.01,Inf,Inf)

[1] 1

pf(1.0001,Inf,Inf)

[1] 0.5

Is this the expected behaviour?


I think so. 1.0001 is the same as 1 in computer arithmetic, 
and pf(1, m, n) = 0.5 for all large m, n.




Thanks

Simone


R.version

  _
platform   i386-pc-mingw32
arch   i386
os mingw32
system i386, mingw32
status Patched
major  2
minor  7.0
year   2008
month  04
day22
svn rev45451
language   R
version.string R version 2.7.0 Patched (2008-04-22 r45451)

platform   x86_64-unknown-linux-gnu
arch   x86_64
os linux-gnu
system x86_64, linux-gnu
status Patched
major  2
minor  6.1
year   2008
month  01
day17
svn rev44036
language   R
version.string R version 2.6.1 Patched (2008-01-17 r44036)

__

Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/
__

[[alternative HTML version deleted]]

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



--
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] qf with infinite df

[Martin Maechler]

Thank you, Simone,

> "SG" == Simone Giannerini <[EMAIL PROTECTED]>
> on Thu, 5 Jun 2008 16:49:25 +0200 writes:

SG> Dear all, I found the following behaviour

>> rf(5,Inf,Inf)
SG> [1] 1 1 1 1 1

SG> but

>> qf(0.1,Inf,Inf)
SG> [1] NaN Warning messages: 1: In qf(0.1, Inf, Inf) :
SG> value out of range in 'lgamma' 2: In qf(p, df1, df2,
SG> lower.tail, log.p) : NaNs produced


SG> incidentally,


>> pf(1.01,Inf,Inf)
SG> [1] 1
>> pf(1.0001,Inf,Inf)
SG> [1] 0.5

SG> Is this the expected behaviour?
   
What is   "this"?

rf() and pf() are.

qf() may still be "expected" if you think a bit how it
might be computed.

OTOH, we could clearly do better there.
Notably, qf()'s behavior is really not good enough, for the case
of large df1 and/or df2.

I'll have a look but won't promise much for now.

Martin Maechler, ETH Zurich


SG> Thanks

SG> Simone

>> R.version
SG>_ platform i386-pc-mingw32 arch i386 os
SG> mingw32 system i386, mingw32 status Patched major 2
SG> minor 7.0 year 2008 month 04 day 22 svn rev 45451
SG> language R version.string R version 2.7.0 Patched
SG> (2008-04-22 r45451)

SG> platform x86_64-unknown-linux-gnu arch x86_64 os
SG> linux-gnu system x86_64, linux-gnu status Patched major
SG> 2 minor 6.1 year 2008 month 01 day 17 svn rev 44036
SG> language R version.string R version 2.6.1 Patched
SG> (2008-01-17 r44036)

SG> __

SG> Simone Giannerini Dipartimento di Scienze Statistiche
SG> "Paolo Fortunati" Universita' di Bologna Via delle belle
SG> arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098262 Fax:
SG> +39 051 232153 http://www2.stat.unibo.it/giannerini/
SG> __

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

[Rd] R-code embedded in VBE -- Type mismatch errors

[pietro . parodi]

Hello,

I am trying to embed R-code inside VB for Excel (probably a perverse 
endeavour anyway) and I am running into difficulties, especially when 
passing vectors back and forth between the two environments.

(1) I am using the RExcel package.

(2) An example of error that I often get and that I can't seem to be able 
to work myself around of is the following VB message:

-- Run-time error '13' - Type mismatch

(3) Detailed example shown below (just added for completeness... I hope 
it's not necessary to look at it in detail!). 

(4) I have looked at the obvious aspects (eg consistent size of vectors) 
but to no avail

I was wondering whether there is a strategy/good programming practice to 
avoid these type mismatch errors, or if at least there is a good debugging 
tool/method to go about correcting them -- the main problem with the R/VB 
embedding is that it is quite difficult to understand whether the error 
depends on VB, on my R code, or on the interface of the two environments!

Thanks in advance for any suggestions you might have

Peter


--- VB Code -

Dim Link_Ratio() As Double

[...]

No_of_Years = 
Application.WorksheetFunction.Count(Worksheets("InputTriangle").Range("C15:IV15"))
ReDim Triangle(No_of_Years, No_of_Years)
ReDim Link_Ratio(No_of_Years)

[...]

' Calling some R functions
Call rinterface.RunRFile(Functions_String)

' Input
For ID_Col = 1 To No_of_Years
Link_Ratio(ID_Col) = Worksheets("Projection").Cells(Start_Row, 
Start_Col + ID_Col - 1).Value
Use(ID_Col) = Worksheets("Projection").Cells(Start_Row + 1, Start_Col 
+ ID_Col - 1).Value
Next ID_Col


Call rinterface.PutArrayFromVBA("link_ratio", Link_Ratio)

Call rinterface.RRun("fitted_lr <- link_fit_vec(link_ratio)")

Fitted_LR = rinterface.GetArrayToVBA("fitted_lr")

 END OF VB code 
---

At this point the code execution stops, signalling the type mismatch 
error.

The related R code is this:

--R code 


link_fit_vec <- function(lr,use_flags=rep(1,length(lr)),max_settle_time = 
15, no_of_months=12, method="Exp"){

output = 
link_fit_exp(lr,use_flags=rep(1,length(lr)),max_settle_time = 15, 
no_of_months=12)[[4]]
output

}
link_fit_exp <- function(lr,use_flags=rep(1,length(lr)),max_settle_time = 
15, no_of_months=12){

# lr = link ratios, INCLUDING the tail factor
# use_flags = 'used' flag, eg x = (1,0,1,1,0,1,1,1)
#   default value is use_flags = (1,1,...1) with as 
many 1's as no of years

if (length(lr) != length(use_flags))
message("Error: Used flag vector must have the 
same length as link ratio vector")
 
# Remove rightmost element (tail factor)
lr = lr[-length(lr)]
use_flags = use_flags[-length(lr)]

use_flags[lr<=1] = 0
z = lr*use_flags
w = c(1:length(lr))
w = w*use_flags
 
z_prime = z[z!=0]
w_prime = w[w!=0]

y = log(z_prime-1)

# Least-squares regression calculations
lm_output = lm(y ~ w_prime) 
 
# Curve parameters
intercept = summary(lm_output)$coefficients[1]
se_intercept = summary(lm_output)$coefficients[3]
slope = summary(lm_output)$coefficients[2]
se_slope = summary(lm_output)$coefficients[4]
a = exp(intercept)
se_a = a*se_intercept
b = slope
R2 = summary(lm_output)[9]
 
# For a complete output:
# type summary(lm_output)

param_vec = as.numeric(c(a,se_a,b,se_slope,R2))

# Fitted curve
xx = c(1:length(lr))
yy = intercept+slope*xx

fitted_model = exp(yy)+1

# Add a tail factor if max_settle_time > no_of_years

if (max_settle_time > no_of_years){
xx_ext = c(no_of_years:max_settle_time)
yy_ext = intercept + slope*xx_ext
}
 
# the reason for a double if is that the else condition 
doesn't seem to work... I'm sure it's just me
if (max_settle_time <= no_of_years) yy_ext = 0

tail_factor=prod(exp(yy_ext)+1)

# Complete model -- link ratios + tail
fitted_vec = c(fitted_model,tail_factor)
 
# What happens if the no of months available is less than 
12?
percent_shift = (12-no_of_months)/12
xx_shifted = xx - percent_shift
yy_shifted = intercept+slope*xx_shifted
shifted_model = exp(yy_shifted)+1
yy

Re: [Rd] qf with infinite df

[Simone Giannerini]

many thanks for all the clarifications and for the declaration of intents
for fixing qf().
For the sake of completeness I stumbled upon the behaviour of qf when
preparing statistical tables with R to be put online for my students. I
remained a bit surprised in seeing how much the results vary across
textbooks at least for the F.

Kind regards

Simone


On Thu, Jun 5, 2008 at 5:13 PM, Prof Brian Ripley <[EMAIL PROTECTED]>
wrote:

> On Thu, 5 Jun 2008, Simone Giannerini wrote:
>
>  Dear all,
>>
>> I found the following behaviour
>>
>>  rf(5,Inf,Inf)
>>>
>> [1] 1 1 1 1 1
>>
>> but
>>
>>  qf(0.1,Inf,Inf)
>>>
>> [1] NaN
>> Warning messages:
>> 1: In qf(0.1, Inf, Inf) : value out of range in 'lgamma'
>> 2: In qf(p, df1, df2, lower.tail, log.p) : NaNs produced
>>
>
> Could do better here.
>
>  incidentally,
>>
>>
>>  pf(1.01,Inf,Inf)
>>>
>> [1] 1
>>
>>> pf(1.0001,Inf,Inf)
>>>
>> [1] 0.5
>>
>> Is this the expected behaviour?
>>
>
> I think so. 1.0001 is the same as 1 in computer arithmetic, and
> pf(1, m, n) = 0.5 for all large m, n.
>
>
>> Thanks
>>
>> Simone
>>
>>  R.version
>>>
>>  _
>> platform   i386-pc-mingw32
>> arch   i386
>> os mingw32
>> system i386, mingw32
>> status Patched
>> major  2
>> minor  7.0
>> year   2008
>> month  04
>> day22
>> svn rev45451
>> language   R
>> version.string R version 2.7.0 Patched (2008-04-22 r45451)
>>
>> platform   x86_64-unknown-linux-gnu
>> arch   x86_64
>> os linux-gnu
>> system x86_64, linux-gnu
>> status Patched
>> major  2
>> minor  6.1
>> year   2008
>> month  01
>> day17
>> svn rev44036
>> language   R
>> version.string R version 2.6.1 Patched (2008-01-17 r44036)
>>
>> __
>>
>> Simone Giannerini
>> Dipartimento di Scienze Statistiche "Paolo Fortunati"
>> Universita' di Bologna
>> Via delle belle arti 41 - 40126 Bologna, ITALY
>> Tel: +39 051 2098262 Fax: +39 051 232153
>> http://www2.stat.unibo.it/giannerini/
>> __
>>
>>[[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
> --
> 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
>



-- 
__

Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126 Bologna, ITALY
Tel: +39 051 2098262 Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/
__

[[alternative HTML version deleted]]

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