Re: [Rd] print(...,digits=2) behavior

[Petr Savicky]

On Mon, Feb 07, 2011 at 09:56:18AM +0100, Martin Maechler wrote:
> > Ben Bolker 
> > on Sat, 5 Feb 2011 15:58:09 -0500 writes:
> 
> >   A bug was recently posted to the R bug database (which
> > probably would better have been posted as a query here) as
> > to why this happens:
> 
> >> print(7.921,digits=2)
> > [1] 8
> >> print(7.92,digits=2)
> > [1] 7.9
> 
[...]

> I had started to delve into this after you've posted the bug
> report. It is clearly a bug(let),
> caused by code that has been in  R  from its very
> beginning, at least in the first source code I've seen in 1994.
> 
> The problem is not related to digits=2,
> but using such a low number of digits shows it more
> dramatically, e.g., also
> 
>  > print(5.9994, digits=4)
>  [1] 5.999
>  > print(5.9994001, digits=4)
>  [1] 6
> 
> Interestingly, the problem seems *not* to be present for
> digits = 1 (only).
> 
> I haven't found time to mathematically "analyze" it for
> determining a correct solution though.
> Note that fixing this bug(let) will probably (very slightly)
> change a huge number of R outputs .. so there is a caveat,
> but nonetheless, we must approach it.
> 
> The responsible code is the C function  scientific()
> in src/main/format.c 

I inspected the source of scientific() and formatReal() (2.13.0, revision
2011-02-08 r54284). Let me point out an example of the difference between
the output of print() and rounding to "digits" significant digits, which
is slightly different from the previous ones, since also the exponent
changes. Namely,

  print(9.991, digits=3)
  [1] 10

while rounding to 3 digits yields 9.99. The reason is in scientific(),
where the situation that rounding increases the exponent is tested using

/* make sure that alpha is in [1,10) AFTER rounding */

if (10.0 - alpha < eps*alpha) {
alpha /= 10.0;
kp += 1;
}

Here, eps is determined in formatReal() as

double eps = pow(10.0, -(double)R_print.digits);

so we have eps = 10^-digits. The above condition on alpha is equivalent to

  alpha > 10.0/(1 + 10^-digits)

For digits=3, this is

  alpha > 9.99000999000999

This bound may be verified as follows

  print(9.9900099900, digits=3)
  [1] 9.99

  print(9.9900099901, digits=3)
  [1] 10

The existing algorithm for choosing the number of digits is designed to
predict the format suitable for all numbers in a vector before the actual
call of sprintf() or snprintf(). For speed, this algorithm should use
the standard double precision, so it is necessarily inaccurate for precision
15 and more and there may be some rare such cases also for smaller
precisions. For smaller precisions, say below 7, the algorithm can be made
more precise. This would change the output in rare cases and mainly for
printing single numbers. If a vector is printed, then the format is typically
not determined by the problematic numbers.

Changing the default behavior may be undesirable for backward compatibility
reasons. If this is the case, then a possible solution is to make the
documentation more precise on this and include pointers to possible
solutions. The functions sprintf(), formatC() and signif() may be used. In
particular, if signif() is used to round the numbers before printing, then we
get the correct output

  print(signif(7.921, digits=2))  
  [1] 7.9

  print(signif(9.9900099901, digits=3))
  [1] 9.99

The current ?print.default contains

  digits: a non-null value for ‘digits’ specifies the minimum number of
  significant digits to be printed in values.

The word "minimum" here means that all numbers in the vector will have
at least the chosen number of digits, but some may have more. I suggest
to add "See 'options' for more detail.".

The current ?options contains

‘digits’: controls the number of digits to print when printing
  numeric values.  It is a suggestion only.

I suggest to extend this to

   It is a suggestion only and the actual number of printed digits
   may be smaller, if the relative error of the output number is
   less than 10^-digits. Use 'signif(, digits)' before printing to get
   the exact number of the printed significant digits.

I appreciate to know the opinion of R developers on this.

Petr Savicky.

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

[Rd] subassignment does not always duplicate object from active binding

[Michael Lawrence]

Hi guys,

I think there might be an issue with the NAMED value on the object returned
by an active binding. For example, with the latest R devel,

env <- new.env(parent=emptyenv())

makeBinding <- function(data) {
  force(data)
  function(new) {
if (missing(new))
  data
else {
  print(data)
  print(new)
  data <<- new
}
  }
}

makeActiveBinding("a", makeBinding(1), env)

env$a <- 2
# [1] 1
# [2] 2
env$a[1] <- 3
# [1] 3
# [1] 3

## but everything is alright if we add another name
b <- env$a
env$a[1] <- 4
# [1] 3
# [1] 4

This naive hack seems to have fixed the above case:

--- src/main/envir.c(revision 54284)
+++ src/main/envir.c(working copy)
@@ -142,6 +142,9 @@
 SEXP expr = LCONS(fun, R_NilValue);
 PROTECT(expr);
 expr = eval(expr, R_GlobalEnv);
+if (NAMED(expr) == 1) {
+  SET_NAMED(expr, 2);
+}
 UNPROTECT(1);
 return expr;
 }

Thanks,
Michael

[[alternative HTML version deleted]]

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

Re: [Rd] using rasterImage within image

[Ben Bolker]

On 11-02-08 10:03 PM, Simon Urbanek wrote:
> Ben,
> 
> did you actually look at the result of your function with useRaster=TRUE ? ;) 
> [Hint: don't use an image that is symmetric]
> 
> Apart from that nice bug there are more issues as well, try
> image(matrix(1:4,2),col=1:3)
> The underlying issue is that as.raster() is not quite what you would hope. 
> Unfortunately I'm not aware of an easy fix (that doesn't involve going
back to RGB decomposition).
> 
> In general, I think it's a nice option, but I don't think you'll get away 
> with only a few lines...
> 
> Cheers,
> Simon
> 
> 
> 
> On Feb 8, 2011, at 8:49 PM, Ben Bolker wrote:
> 
>>
>>  Has anyone yet tried incorporating rasterImage into the base image()
>> function?  It seems to make a *huge* difference, with
>> a very small number of added/changed lines of code.  (Of course I have
>> barely tested it at all.)
>>  Is there any reason this *shouldn't* go into the next release?
>>
>>> source("image.R")
>>> z <- matrix(runif(1e6),nrow=1000)
>>> image(z)
>>> image(z,useRaster=TRUE)
>>
>>  (Patch against SVN 54284 attached; people can contact me if it doesn't
>> go through and they want it.)
>>
>>  Ben Bolker
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

  Trying again. Rotated counterclockwise within R (although this *could*
be coded in C if speed were important?)
  Some brute-force testing suggests it is *slightly* slower for small
images (7 vs 8 seconds for 1000 reps) and still much faster (and
produces much smaller images, which don't suffer from antialiasing junk
in my PDF viewer) for large images.
Index: R/image.R
===
--- R/image.R   (revision 54297)
+++ R/image.R   (working copy)
@@ -24,7 +24,8 @@
   ylim = range(y),
   col = heat.colors(12), add = FALSE,
   xaxs = "i", yaxs = "i", xlab, ylab,
-   breaks, oldstyle=FALSE, ...)
+   breaks, oldstyle=FALSE, 
+   useRaster=FALSE, ...)
 {
 if (missing(z)) {
if (!missing(x)) {
@@ -97,5 +98,21 @@
 if (length(y) <= 1) y <- par("usr")[3:4]
 if (length(x) != nrow(z)+1 || length(y) != ncol(z)+1)
 stop("dimensions of z are not length(x)(-1) times length(y)(-1)")
-.Internal(image(as.double(x), as.double(y), as.integer(zi), col))
+if (useRaster) {
+  if (is.numeric(col)) {
+p <- palette()
+pl <- length(p)
+col <- p[((col-1) %% pl)+1]
+  }
+  zc <- col[zi+1]
+  dim(zc) <- dim(z)
+  ##Rotate a square matrix 90 degrees COUNTERclockwise.
+  ## inspired by
+  ## 

+  zc <- t(zc)[ncol(zc):1,]
+  rasterImage(as.raster(zc),
+  xlim[1],ylim[1],xlim[2],ylim[2],interpolate=FALSE)
+} else {
+  .Internal(image(as.double(x), as.double(y), as.integer(zi), col))
+}
 }

require(grDevices) # for colours

## read modified image.R file, from wherever, if necessary
## source("~/R/r-devel/R/src/library/graphics/R/image.R")

tmpf <- function(ifun=image) {
  ifun(matrix(1:25,5),col=1:25)
  x <- y <- seq(-4*pi, 4*pi, len=27)
  r <- sqrt(outer(x^2, y^2, "+"))
  ifun(z = z <- cos(r^2)*exp(-r/6), col=gray((0:32)/32))
  ifun(z, axes = FALSE, main = "Math can be beautiful ...",
xlab = expression(cos(r^2) * e^{-r/6}))
  contour(z, add = TRUE, drawlabels = FALSE)
  
  ## Volcano data visualized as matrix. Need to transpose and flip
  ## matrix horizontally.
  ifun(t(volcano)[ncol(volcano):1,])

  ## A prettier display of the volcano
  x <- 10*(1:nrow(volcano))
  y <- 10*(1:ncol(volcano))
  ifun(x, y, volcano, col = terrain.colors(100), axes = FALSE)
  contour(x, y, volcano, levels = seq(90, 200, by = 5),
  add = TRUE, col = "peru")
  axis(1, at = seq(100, 800, by = 100))
  axis(2, at = seq(100, 600, by = 100))
  box()
  title(main = "Maunga Whau Volcano", font.main = 4)
}

pdf("image1.pdf")
tmpf()
dev.off()

pdf("image2.pdf")
tmpf(ifun=function(...) image(...,useRaster=TRUE))
dev.off()

st1 <- system.time(replicate(1000,image(matrix(1:25,5),col=1:25)))
st2 <- system.time(replicate(1000,image(matrix(1:25,5),col=1:25,
useRaster=TRUE)))
## 21.3 (standard) vs 22.9 (raster) seconds

st3 <- system.time(replicate(1000,image(matrix(1:1,100
st4 <- system.time(replicate(1000,image(matrix(1:1,100),
useRaster=TRUE)))
## 149 (standard) vs 31 (raster) seconds
#  File src/library/graphics/R/image.R
#  Part of the R package, http://www.R-project.org
#
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.
#
#  This 

Re: [Rd] dependencies on system packages

[Allen S. Rout]

Simon Urbanek  writes:
> On Feb 4, 2011, at 1:24 PM, Dirk Eddelbuettel wrote:

[...]

>> We need to address this: With 2600+ packages and continued growth,
>> manually wading through README is not good enough.  We should do
>> better.  Resources (time, money, servers, ...) would help.  Maybe one
>> day someone with more time can fold this into a proper sub-project of
>> a larger grant application.  It would be worth, and I would try to
>> help, time permitting.


I'm one of the people who made stabs at this in the past.  I had a
fairly complete Gentoo process in place, but then the sickness passed.

More recently, I've been peripherally involved with an effort to
translate CRAN to redhat-land.

When we talked about this most intensely last (waaay back in 2006), I
had a detailed submission for an "Extended depends string", a strictly
formatted field to accompany or supplant the existing system depends.

I also supplied suggested code to translate a string in this format to a
simple depstring, which would neatly plug into the existing depstring
infrastructure already in place.  


http://article.gmane.org/gmane.comp.lang.r.devel/9179


So, for an example extended depstring

src <- "libgd (>= 1.9.0) (gentoo gd >= 2.0) (debian >= 1.9.2)"

extdepstring2depstring(src)

yields "libgd (>= 1.9.0)"

and

extdepstring2depstring(src,systype="debian")

yields "libgd (>= 1.9.2)"

and 

extdepstring2depstring(src,systype="unknown")

yields the default. 



I think this would be preferable to a growing taxonomy of 

Depends-[system]: 




- Allen S. Rout

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

Re: [Rd] using rasterImage within image

[Simon Urbanek]

Ben,

I have committed something analogous to R-devel (your rotation code was not 
unlike mine, I replicated the color handling from R internals to be consistent, 
I fixed the drawing limits and added a check for x/y conformance). Note that 
useRaster can only be used when x, y form a regular grid. Although I tried a 
lot of corner cases (requiring quite a few fixes), I'm sure I did not test all 
of them, so volunteers please give it a go and compare it with non-raster 
output.

The only thing I'm not quite happy about is the argument name: useRaster. 
Personally, I hate camel case in R (it has crept in more recently making it 
horribly inconsistent) so please feel free to suggest a better name ;).

Thanks,
Simon


On Feb 9, 2011, at 10:06 AM, Ben Bolker wrote:

> On 11-02-08 10:03 PM, Simon Urbanek wrote:
>> Ben,
>> 
>> did you actually look at the result of your function with useRaster=TRUE ? 
>> ;) [Hint: don't use an image that is symmetric]
>> 
>> Apart from that nice bug there are more issues as well, try
>> image(matrix(1:4,2),col=1:3)
>> The underlying issue is that as.raster() is not quite what you would hope. 
>> Unfortunately I'm not aware of an easy fix (that doesn't involve going
> back to RGB decomposition).
>> 
>> In general, I think it's a nice option, but I don't think you'll get away 
>> with only a few lines...
>> 
>> Cheers,
>> Simon
>> 
>> 
>> 
>> On Feb 8, 2011, at 8:49 PM, Ben Bolker wrote:
>> 
>>> 
>>> Has anyone yet tried incorporating rasterImage into the base image()
>>> function?  It seems to make a *huge* difference, with
>>> a very small number of added/changed lines of code.  (Of course I have
>>> barely tested it at all.)
>>> Is there any reason this *shouldn't* go into the next release?
>>> 
 source("image.R")
 z <- matrix(runif(1e6),nrow=1000)
 image(z)
 image(z,useRaster=TRUE)
>>> 
>>> (Patch against SVN 54284 attached; people can contact me if it doesn't
>>> go through and they want it.)
>>> 
>>> Ben Bolker
>>> 
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
>  Trying again. Rotated counterclockwise within R (although this *could*
> be coded in C if speed were important?)
>  Some brute-force testing suggests it is *slightly* slower for small
> images (7 vs 8 seconds for 1000 reps) and still much faster (and
> produces much smaller images, which don't suffer from antialiasing junk
> in my PDF viewer) for large images.
> 

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

Re: [Rd] using rasterImage within image

[Henrik Bengtsson]

On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek
 wrote:
> Ben,
>
> I have committed something analogous to R-devel (your rotation code was not 
> unlike mine, I replicated the color handling from R internals to be 
> consistent, I fixed the drawing limits and added a check for x/y 
> conformance). Note that useRaster can only be used when x, y form a regular 
> grid. Although I tried a lot of corner cases (requiring quite a few fixes), 
> I'm sure I did not test all of them, so volunteers please give it a go and 
> compare it with non-raster output.
>
> The only thing I'm not quite happy about is the argument name: useRaster. 
> Personally, I hate camel case in R (it has crept in more recently making it 
> horribly inconsistent) so please feel free to suggest a better name ;).

It.is.spelled.camelCase.

What about style=c("image", "raster")?  This allows for future extensions too.

/H

>
> Thanks,
> Simon
>
>
> On Feb 9, 2011, at 10:06 AM, Ben Bolker wrote:
>
>> On 11-02-08 10:03 PM, Simon Urbanek wrote:
>>> Ben,
>>>
>>> did you actually look at the result of your function with useRaster=TRUE ? 
>>> ;) [Hint: don't use an image that is symmetric]
>>>
>>> Apart from that nice bug there are more issues as well, try
>>> image(matrix(1:4,2),col=1:3)
>>> The underlying issue is that as.raster() is not quite what you would hope.
>>> Unfortunately I'm not aware of an easy fix (that doesn't involve going
>> back to RGB decomposition).
>>>
>>> In general, I think it's a nice option, but I don't think you'll get away 
>>> with only a few lines...
>>>
>>> Cheers,
>>> Simon
>>>
>>>
>>>
>>> On Feb 8, 2011, at 8:49 PM, Ben Bolker wrote:
>>>

 Has anyone yet tried incorporating rasterImage into the base image()
 function?  It seems to make a *huge* difference, with
 a very small number of added/changed lines of code.  (Of course I have
 barely tested it at all.)
 Is there any reason this *shouldn't* go into the next release?

> source("image.R")
> z <- matrix(runif(1e6),nrow=1000)
> image(z)
> image(z,useRaster=TRUE)

 (Patch against SVN 54284 attached; people can contact me if it doesn't
 go through and they want it.)

 Ben Bolker

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>  Trying again. Rotated counterclockwise within R (although this *could*
>> be coded in C if speed were important?)
>>  Some brute-force testing suggests it is *slightly* slower for small
>> images (7 vs 8 seconds for 1000 reps) and still much faster (and
>> produces much smaller images, which don't suffer from antialiasing junk
>> in my PDF viewer) for large images.
>> 
>
> __
> 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

Re: [Rd] using rasterImage within image

[Simon Urbanek]

On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote:

> On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek
>  wrote:
>> Ben,
>> 
>> I have committed something analogous to R-devel (your rotation code was not 
>> unlike mine, I replicated the color handling from R internals to be 
>> consistent, I fixed the drawing limits and added a check for x/y 
>> conformance). Note that useRaster can only be used when x, y form a regular 
>> grid. Although I tried a lot of corner cases (requiring quite a few fixes), 
>> I'm sure I did not test all of them, so volunteers please give it a go and 
>> compare it with non-raster output.
>> 
>> The only thing I'm not quite happy about is the argument name: useRaster. 
>> Personally, I hate camel case in R (it has crept in more recently making it 
>> horribly inconsistent) so please feel free to suggest a better name ;).
> 
> It.is.spelled.camelCase.
> 

Fortunately not in English ;)


> What about style=c("image", "raster")?  This allows for future extensions too.
> 

Hmm.. it's not really a "style" - the output doesn't change (ideally) - it's 
more of a back-end specification .. also we already have oldstyle argument in 
image() adding to the confusion ...

Thanks,
Simon


>> 
>> Thanks,
>> Simon
>> 
>> 
>> On Feb 9, 2011, at 10:06 AM, Ben Bolker wrote:
>> 
>>> On 11-02-08 10:03 PM, Simon Urbanek wrote:
 Ben,
 
 did you actually look at the result of your function with useRaster=TRUE ? 
 ;) [Hint: don't use an image that is symmetric]
 
 Apart from that nice bug there are more issues as well, try
 image(matrix(1:4,2),col=1:3)
 The underlying issue is that as.raster() is not quite what you would hope.
 Unfortunately I'm not aware of an easy fix (that doesn't involve going
>>> back to RGB decomposition).
 
 In general, I think it's a nice option, but I don't think you'll get away 
 with only a few lines...
 
 Cheers,
 Simon
 
 
 
 On Feb 8, 2011, at 8:49 PM, Ben Bolker wrote:
 
> 
> Has anyone yet tried incorporating rasterImage into the base image()
> function?  It seems to make a *huge* difference, with
> a very small number of added/changed lines of code.  (Of course I have
> barely tested it at all.)
> Is there any reason this *shouldn't* go into the next release?
> 
>> source("image.R")
>> z <- matrix(runif(1e6),nrow=1000)
>> image(z)
>> image(z,useRaster=TRUE)
> 
> (Patch against SVN 54284 attached; people can contact me if it doesn't
> go through and they want it.)
> 
> Ben Bolker
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> 
>>>  Trying again. Rotated counterclockwise within R (although this *could*
>>> be coded in C if speed were important?)
>>>  Some brute-force testing suggests it is *slightly* slower for small
>>> images (7 vs 8 seconds for 1000 reps) and still much faster (and
>>> produces much smaller images, which don't suffer from antialiasing junk
>>> in my PDF viewer) for large images.
>>> 
>> 
>> __
>> 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

Re: [Rd] using rasterImage within image

[Henrik Bengtsson]

On Wed, Feb 9, 2011 at 11:53 AM, Simon Urbanek
 wrote:
>
> On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote:
>
>> On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek
>>  wrote:
>>> Ben,
>>>
>>> I have committed something analogous to R-devel (your rotation code was not 
>>> unlike mine, I replicated the color handling from R internals to be 
>>> consistent, I fixed the drawing limits and added a check for x/y 
>>> conformance). Note that useRaster can only be used when x, y form a regular 
>>> grid. Although I tried a lot of corner cases (requiring quite a few fixes), 
>>> I'm sure I did not test all of them, so volunteers please give it a go and 
>>> compare it with non-raster output.
>>>
>>> The only thing I'm not quite happy about is the argument name: useRaster. 
>>> Personally, I hate camel case in R (it has crept in more recently making it 
>>> horribly inconsistent) so please feel free to suggest a better name ;).
>>
>> It.is.spelled.camelCase.
>>
>
> Fortunately not in English ;)
>
>
>> What about style=c("image", "raster")?  This allows for future extensions 
>> too.
>>
>
> Hmm.. it's not really a "style" - the output doesn't change (ideally) - it's 
> more of a back-end specification .. also we already have oldstyle argument in 
> image() adding to the confusion ...

flavor=c("image", "raster")
renderer=c("image", "raster")
backend=c("image", "raster")
...

?

/H

>
> Thanks,
> Simon
>
>
>>>
>>> Thanks,
>>> Simon
>>>
>>>
>>> On Feb 9, 2011, at 10:06 AM, Ben Bolker wrote:
>>>
 On 11-02-08 10:03 PM, Simon Urbanek wrote:
> Ben,
>
> did you actually look at the result of your function with useRaster=TRUE 
> ? ;) [Hint: don't use an image that is symmetric]
>
> Apart from that nice bug there are more issues as well, try
> image(matrix(1:4,2),col=1:3)
> The underlying issue is that as.raster() is not quite what you would hope.
> Unfortunately I'm not aware of an easy fix (that doesn't involve going
 back to RGB decomposition).
>
> In general, I think it's a nice option, but I don't think you'll get away 
> with only a few lines...
>
> Cheers,
> Simon
>
>
>
> On Feb 8, 2011, at 8:49 PM, Ben Bolker wrote:
>
>>
>> Has anyone yet tried incorporating rasterImage into the base image()
>> function?  It seems to make a *huge* difference, with
>> a very small number of added/changed lines of code.  (Of course I have
>> barely tested it at all.)
>> Is there any reason this *shouldn't* go into the next release?
>>
>>> source("image.R")
>>> z <- matrix(runif(1e6),nrow=1000)
>>> image(z)
>>> image(z,useRaster=TRUE)
>>
>> (Patch against SVN 54284 attached; people can contact me if it doesn't
>> go through and they want it.)
>>
>> Ben Bolker
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

  Trying again. Rotated counterclockwise within R (although this *could*
 be coded in C if speed were important?)
  Some brute-force testing suggests it is *slightly* slower for small
 images (7 vs 8 seconds for 1000 reps) and still much faster (and
 produces much smaller images, which don't suffer from antialiasing junk
 in my PDF viewer) for large images.
 
>>>
>>> __
>>> 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

Re: [Rd] using rasterImage within image

[Ben Bolker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11-02-09 03:09 PM, Henrik Bengtsson wrote:
> On Wed, Feb 9, 2011 at 11:53 AM, Simon Urbanek 
>  wrote:
>> 
>> On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote:
>> 
>>> On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek 
>>>  wrote:
 Ben,
 
 I have committed something analogous to R-devel (your rotation
 code was not unlike mine, I replicated the color handling from
 R internals to be consistent, I fixed the drawing limits and
 added a check for x/y conformance). Note that useRaster can
 only be used when x, y form a regular grid. Although I tried a
 lot of corner cases (requiring quite a few fixes), I'm sure I
 did not test all of them, so volunteers please give it a go and
 compare it with non-raster output.
 
 The only thing I'm not quite happy about is the argument name:
 useRaster. Personally, I hate camel case in R (it has crept in
 more recently making it horribly inconsistent) so please feel
 free to suggest a better name ;).
>>> 
>>> It.is.spelled.camelCase.
>>> 
>> 
>> Fortunately not in English ;)
>> 
>> 
>>> What about style=c("image", "raster")?  This allows for future
>>> extensions too.
>>> 
>> 
>> Hmm.. it's not really a "style" - the output doesn't change
>> (ideally) - it's more of a back-end specification .. also we
>> already have oldstyle argument in image() adding to the confusion
>> ...
> 
> flavor=c("image", "raster") renderer=c("image", "raster") 
> backend=c("image", "raster") ...

  Thanks Simon! (Any reports on the SDI Windows raster rendering issue,
or do we need a warning/workaround there?)

  I like "backend", or possibly "method"

  One minor consideration: if "raster" eventually becomes the default
(as I hope it will), there would need to be some internal logic that
drops back to "image" if the user specifies uneven spacing and doesn't
explicitly specify the 'backend/method' parameter ...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1TFVcACgkQc5UpGjwzenOa6ACfVnJq67cG0czATeyti7AxgUbw
ZWwAniA7JuYCv4clq8e6jwWQuMvw/r+m
=/da6
-END PGP SIGNATURE-

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

Re: [Rd] using rasterImage within image

[Michael Sumner]

Regarding the SDI problem, I'll check that as soon as the next
snapshot build of 2.13.0 is available from CRAN (probably a few days
from now, unless I can manage to compile it myself).

Cheers, Mike.

On Thu, Feb 10, 2011 at 9:29 AM, Ben Bolker  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11-02-09 03:09 PM, Henrik Bengtsson wrote:
>> On Wed, Feb 9, 2011 at 11:53 AM, Simon Urbanek
>>  wrote:
>>>
>>> On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote:
>>>
 On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek
  wrote:
> Ben,
>
> I have committed something analogous to R-devel (your rotation
> code was not unlike mine, I replicated the color handling from
> R internals to be consistent, I fixed the drawing limits and
> added a check for x/y conformance). Note that useRaster can
> only be used when x, y form a regular grid. Although I tried a
> lot of corner cases (requiring quite a few fixes), I'm sure I
> did not test all of them, so volunteers please give it a go and
> compare it with non-raster output.
>
> The only thing I'm not quite happy about is the argument name:
> useRaster. Personally, I hate camel case in R (it has crept in
> more recently making it horribly inconsistent) so please feel
> free to suggest a better name ;).

 It.is.spelled.camelCase.

>>>
>>> Fortunately not in English ;)
>>>
>>>
 What about style=c("image", "raster")?  This allows for future
 extensions too.

>>>
>>> Hmm.. it's not really a "style" - the output doesn't change
>>> (ideally) - it's more of a back-end specification .. also we
>>> already have oldstyle argument in image() adding to the confusion
>>> ...
>>
>> flavor=c("image", "raster") renderer=c("image", "raster")
>> backend=c("image", "raster") ...
>
>  Thanks Simon! (Any reports on the SDI Windows raster rendering issue,
> or do we need a warning/workaround there?)
>
>  I like "backend", or possibly "method"
>
>  One minor consideration: if "raster" eventually becomes the default
> (as I hope it will), there would need to be some internal logic that
> drops back to "image" if the user specifies uneven spacing and doesn't
> explicitly specify the 'backend/method' parameter ...
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1TFVcACgkQc5UpGjwzenOa6ACfVnJq67cG0czATeyti7AxgUbw
> ZWwAniA7JuYCv4clq8e6jwWQuMvw/r+m
> =/da6
> -END PGP SIGNATURE-
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Michael Sumner
Institute for Marine and Antarctic Studies, University of Tasmania
Hobart, Australia
e-mail: mdsum...@gmail.com

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

[Rd] Problem installing MCMCpack on SPARC Solaris 10

[Zhang,Jun]

Hi list,
I tried to install MCMCpack to R-2.12.0, got the following error,
R CMD INSTALL MCMCpack_1.0-9.tar.gz
..
CC -m64 -library=stlport4 -I/apps/sparcv9/R-2.12.0/lib/R/include 
-DSCYTHE_COMPILE_DIRECT -DSCYTHE_DEBUG=0 -DHAVE_TRUNC -DHAVE_IEEEFP_H   
-I/opt/csw/include-KPIC  -g -c MCMCSVDreg.cc -o 
MCMCSVDreg.o
"error.h", line 598: Error: The function "abort" must have a prototype.
"distributions.h", line 550: Error: The function "trunc" must have a prototype.
"distributions.h", line 550: Error: log1p is not a member of file level.
"distributions.h", line 566: Error: The function "trunc" must have a prototype.
"distributions.h", line 566: Error: log1p is not a member of file level.
"distributions.h", line 2177: Error: sqrt is not a member of file level.
6 Error(s) detected.
make: *** [MCMCSVDreg.o] Error 2
ERROR: compilation failed for package 'MCMCpack'
* removing '/apps/sparcv9/R-2.12.0/lib/R/library/MCMCpack'

root@dqssun4 local# which cc
/opt/solstudio12.2/bin/cc
root@dqssun4 local# which R
/apps/sparcv9/R-2.12.0/bin/R

The configure script for the successful R installation is the following,
CC="cc -xc99 -m64 -xarch=sparcvis2"
CPPFLAGS="-I/opt/csw/include"
CFLAGS="-xcode=abs64 -xlibmieee -xtarget=ultra3 -xarch=sparcvis2"
F77=f95
CXX="CC -m64 -library=stlport4"
FC=$F77
FFLAGS="-m64 -xarch=sparcvis2"
FCFLAGS=$FFLAGS
LDFLAGS="-L/opt/csw/lib/sparcv9 -L/opt/solstudio12.2/prod/lib/v9"
export CC CPPFLAGS CFLAGS F77 FFLAGS CXX CXXFLAGS FC FCFLAGS LDFLAGS
./configure --prefix=/apps/sparcv9/R-2.12.0 --with-tcl-config=/opt/csw/lib/tclCo
nfig.sh --with-tk-config=/opt/csw/lib/tkConfig.sh --disable-nls

Jun Zhang

[[alternative HTML version deleted]]

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

[Rd] SurviveGotoBLAS2 for Win64 (RC release)

[Ei-ji Nakama]

Hi,

I put below Rblas.dll(GotoBLAS2 for Win64).
http://prs.ism.ac.jp/~nakama/SurviveGotoBLAS2/binary/windows/x64/
please choose the core-name of your CPU.
The recognition of the CPU of DYNAMIC_ARCH is low.

zdot[cu], zgemv came to calculate definitely.

-- 
EI-JI Nakama  
"\u4e2d\u9593\u6804\u6cbb"  

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

[Rd] Problem installing MCMCpack on SPARC Solaris 10

[Jun Zhang]

Hi list,
I tried to install MCMCpack to R-2.12.0, got the following error,
CC -m64 -library=stlport4 -I/apps/sparcv9/R-2.12.0/lib/R/include 
-DSCYTHE_COMPILE_DIRECT -DSCYTHE_DEBUG=0 -DHAVE_TRUNC -DHAVE_IEEEFP_H   
-I/opt/csw/include-KPIC  -g -c MCMCSVDreg.cc -o MCMCSVDreg.o
"error.h", line 598: Error: The function "abort" must have a prototype.
"distributions.h", line 550: Error: The function "trunc" must have a prototype.
"distributions.h", line 550: Error: log1p is not a member of file level.
"distributions.h", line 566: Error: The function "trunc" must have a prototype.
"distributions.h", line 566: Error: log1p is not a member of file level.
"distributions.h", line 2177: Error: sqrt is not a member of file level.
6 Error(s) detected.
make: *** [MCMCSVDreg.o] Error 2
ERROR: compilation failed for package 'MCMCpack'
* removing '/apps/sparcv9/R-2.12.0/lib/R/library/MCMCpack'

root@dqssun4 local# which cc
/opt/solstudio12.2/bin/cc
root@dqssun4 local# which R
/apps/sparcv9/R-2.12.0/bin/R

The configure script for the successful R installation is the following,
CC="cc -xc99 -m64 -xarch=sparcvis2"
CPPFLAGS="-I/opt/csw/include"
CFLAGS="-xcode=abs64 -xlibmieee -xtarget=ultra3 -xarch=sparcvis2"
F77=f95
CXX="CC -m64 -library=stlport4"
FC=$F77
FFLAGS="-m64 -xarch=sparcvis2"
FCFLAGS=$FFLAGS
LDFLAGS="-L/opt/csw/lib/sparcv9 -L/opt/solstudio12.2/prod/lib/v9"
export CC CPPFLAGS CFLAGS F77 FFLAGS CXX CXXFLAGS FC FCFLAGS LDFLAGS
./configure --prefix=/apps/sparcv9/R-2.12.0 --with-tcl-config=/opt/csw/lib/tclCo
nfig.sh --with-tk-config=/opt/csw/lib/tkConfig.sh --disable-nls

Jun Zhang


 

Be a PS3 game guru.


[[alternative HTML version deleted]]

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

Re: [Rd] using rasterImage within image

[baptiste auguie]

Dear all,

Back when grid.raster() was introduced, it was suggested that perhaps
grid.rect() could use grid.raster() in case of even spacing. The
response at the time was that it would be best to keep the two
functions separate at a lower level, that is grid.rect() and
grid.raster(), but perhaps a new function grid.image() could be
proposed at a higher level with the two possible backends. If this is
done in grid graphics, perhaps the same convention could be used for
base graphics: image() would be high level with the backend option,
and a new function ("tiles()", perhaps?) would implement the current
behavior of image().

In any case, it would be nice to have a unified scheme to switch
between "tiles" and raster; currently lattice (panl.levelplot.raster)
and a few other packages all do it separately.

Best wishes,

baptiste



On 9 February 2011 23:29, Ben Bolker  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11-02-09 03:09 PM, Henrik Bengtsson wrote:
>> On Wed, Feb 9, 2011 at 11:53 AM, Simon Urbanek
>>  wrote:
>>>
>>> On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote:
>>>
 On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek
  wrote:
> Ben,
>
> I have committed something analogous to R-devel (your rotation
> code was not unlike mine, I replicated the color handling from
> R internals to be consistent, I fixed the drawing limits and
> added a check for x/y conformance). Note that useRaster can
> only be used when x, y form a regular grid. Although I tried a
> lot of corner cases (requiring quite a few fixes), I'm sure I
> did not test all of them, so volunteers please give it a go and
> compare it with non-raster output.
>
> The only thing I'm not quite happy about is the argument name:
> useRaster. Personally, I hate camel case in R (it has crept in
> more recently making it horribly inconsistent) so please feel
> free to suggest a better name ;).

 It.is.spelled.camelCase.

>>>
>>> Fortunately not in English ;)
>>>
>>>
 What about style=c("image", "raster")?  This allows for future
 extensions too.

>>>
>>> Hmm.. it's not really a "style" - the output doesn't change
>>> (ideally) - it's more of a back-end specification .. also we
>>> already have oldstyle argument in image() adding to the confusion
>>> ...
>>
>> flavor=c("image", "raster") renderer=c("image", "raster")
>> backend=c("image", "raster") ...
>
>  Thanks Simon! (Any reports on the SDI Windows raster rendering issue,
> or do we need a warning/workaround there?)
>
>  I like "backend", or possibly "method"
>
>  One minor consideration: if "raster" eventually becomes the default
> (as I hope it will), there would need to be some internal logic that
> drops back to "image" if the user specifies uneven spacing and doesn't
> explicitly specify the 'backend/method' parameter ...
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1TFVcACgkQc5UpGjwzenOa6ACfVnJq67cG0czATeyti7AxgUbw
> ZWwAniA7JuYCv4clq8e6jwWQuMvw/r+m
> =/da6
> -END PGP SIGNATURE-
>
> __
> 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

Re: [Rd] using rasterImage within image

[Michael Sumner]

Hello, I'm afraid the SDI graphics issue is still a problem in 2.13.0
2011-02-09 r54308.

To reproduce, in a fresh R session (Windows in SDI mode):

## create a dummy dataset
m<- matrix(c(0.2, 0.4, 0.6, 0.8), 2, 2)

## simple helper function to open the windows() device and plot the matrix
draw.f<- function(x) {
   plot(0, xlim = c(0, 1), ylim = c(0, 1))
   rasterImage(x, 0, 0, 1, 1, interpolate = FALSE)
}

draw.f(m)

## repeat the following 2 lines five times:

dev.off()
draw.f(m)

On the fifth attempt, only the background plot appears - but the
raster is visible on resize of the windows() device.

Cheers, Mike.

sessionInfo()
R version 2.13.0 Under development (unstable) (2011-02-09 r54308)
Platform: x86_64-pc-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=English_Australia.1252  LC_CTYPE=English_Australia.1252
[3] LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252

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



On Thu, Feb 10, 2011 at 5:31 PM, baptiste auguie
 wrote:
> Dear all,
>
> Back when grid.raster() was introduced, it was suggested that perhaps
> grid.rect() could use grid.raster() in case of even spacing. The
> response at the time was that it would be best to keep the two
> functions separate at a lower level, that is grid.rect() and
> grid.raster(), but perhaps a new function grid.image() could be
> proposed at a higher level with the two possible backends. If this is
> done in grid graphics, perhaps the same convention could be used for
> base graphics: image() would be high level with the backend option,
> and a new function ("tiles()", perhaps?) would implement the current
> behavior of image().
>
> In any case, it would be nice to have a unified scheme to switch
> between "tiles" and raster; currently lattice (panl.levelplot.raster)
> and a few other packages all do it separately.
>
> Best wishes,
>
> baptiste
>
>
>
> On 9 February 2011 23:29, Ben Bolker  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 11-02-09 03:09 PM, Henrik Bengtsson wrote:
>>> On Wed, Feb 9, 2011 at 11:53 AM, Simon Urbanek
>>>  wrote:

 On Feb 9, 2011, at 2:36 PM, Henrik Bengtsson wrote:

> On Wed, Feb 9, 2011 at 11:25 AM, Simon Urbanek
>  wrote:
>> Ben,
>>
>> I have committed something analogous to R-devel (your rotation
>> code was not unlike mine, I replicated the color handling from
>> R internals to be consistent, I fixed the drawing limits and
>> added a check for x/y conformance). Note that useRaster can
>> only be used when x, y form a regular grid. Although I tried a
>> lot of corner cases (requiring quite a few fixes), I'm sure I
>> did not test all of them, so volunteers please give it a go and
>> compare it with non-raster output.
>>
>> The only thing I'm not quite happy about is the argument name:
>> useRaster. Personally, I hate camel case in R (it has crept in
>> more recently making it horribly inconsistent) so please feel
>> free to suggest a better name ;).
>
> It.is.spelled.camelCase.
>

 Fortunately not in English ;)


> What about style=c("image", "raster")?  This allows for future
> extensions too.
>

 Hmm.. it's not really a "style" - the output doesn't change
 (ideally) - it's more of a back-end specification .. also we
 already have oldstyle argument in image() adding to the confusion
 ...
>>>
>>> flavor=c("image", "raster") renderer=c("image", "raster")
>>> backend=c("image", "raster") ...
>>
>>  Thanks Simon! (Any reports on the SDI Windows raster rendering issue,
>> or do we need a warning/workaround there?)
>>
>>  I like "backend", or possibly "method"
>>
>>  One minor consideration: if "raster" eventually becomes the default
>> (as I hope it will), there would need to be some internal logic that
>> drops back to "image" if the user specifies uneven spacing and doesn't
>> explicitly specify the 'backend/method' parameter ...
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk1TFVcACgkQc5UpGjwzenOa6ACfVnJq67cG0czATeyti7AxgUbw
>> ZWwAniA7JuYCv4clq8e6jwWQuMvw/r+m
>> =/da6
>> -END PGP SIGNATURE-
>>
>> __
>> 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
>



-- 
Michael Sumner
Institute for Marine and Antarctic Studies, University of Tasmania
Hobart, Australia
e-mail: mdsum...@gmail.com

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

Re: [Rd] Problem installing MCMCpack on SPARC Solaris 10

[Prof Brian Ripley]

There are lots of problems with MCMCpack's C++: the only way (short of 
a major rewrite) that you will get it to compile on Solaris is to use 
g++ (and even that needs corrections).


The maintainers seem deaf to reports of the issues.

And please note what the posting guide says about where to send 
questions about non-R programming issues.


On Wed, 9 Feb 2011, Zhang,Jun wrote:


Hi list,
   I tried to install MCMCpack to R-2.12.0, got the following error,
R CMD INSTALL MCMCpack_1.0-9.tar.gz
..
CC -m64 -library=stlport4 -I/apps/sparcv9/R-2.12.0/lib/R/include 
-DSCYTHE_COMPILE_DIRECT -DSCYTHE_DEBUG=0 -DHAVE_TRUNC -DHAVE_IEEEFP_H   
-I/opt/csw/include-KPIC  -g -c MCMCSVDreg.cc -o 
MCMCSVDreg.o
"error.h", line 598: Error: The function "abort" must have a prototype.
"distributions.h", line 550: Error: The function "trunc" must have a prototype.
"distributions.h", line 550: Error: log1p is not a member of file level.
"distributions.h", line 566: Error: The function "trunc" must have a prototype.
"distributions.h", line 566: Error: log1p is not a member of file level.
"distributions.h", line 2177: Error: sqrt is not a member of file level.
6 Error(s) detected.
make: *** [MCMCSVDreg.o] Error 2
ERROR: compilation failed for package 'MCMCpack'
* removing '/apps/sparcv9/R-2.12.0/lib/R/library/MCMCpack'

root@dqssun4 local# which cc
/opt/solstudio12.2/bin/cc
root@dqssun4 local# which R
/apps/sparcv9/R-2.12.0/bin/R

The configure script for the successful R installation is the following,
CC="cc -xc99 -m64 -xarch=sparcvis2"
CPPFLAGS="-I/opt/csw/include"
CFLAGS="-xcode=abs64 -xlibmieee -xtarget=ultra3 -xarch=sparcvis2"
F77=f95
CXX="CC -m64 -library=stlport4"
FC=$F77
FFLAGS="-m64 -xarch=sparcvis2"
FCFLAGS=$FFLAGS
LDFLAGS="-L/opt/csw/lib/sparcv9 -L/opt/solstudio12.2/prod/lib/v9"
export CC CPPFLAGS CFLAGS F77 FFLAGS CXX CXXFLAGS FC FCFLAGS LDFLAGS
./configure --prefix=/apps/sparcv9/R-2.12.0 --with-tcl-config=/opt/csw/lib/tclCo
nfig.sh --with-tk-config=/opt/csw/lib/tkConfig.sh --disable-nls

Jun Zhang

[[alternative HTML version deleted]]

__
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