Re: [Rd] Tabs in R source code

[Martin Maechler]

> "S" == Sharpie  
> on Thu, 3 Dec 2009 19:44:59 -0800 (PST) writes:

S> pengyu.ut wrote:
>> 
>> http://google-styleguide.googlecode.com/svn/trunk/google-r-style.html
>> 
>> Here is the R style, which does not recommend using tabs. Although it
>> might take some time to forbidden the use of tabs, it will eventually
>> be a good practice that benefits everyone in the future.
>> 

S> Whoa, put the kibosh on that thought. 

S> That is Google's style guide for R code written at Google by Google
S> employees.  It is by no means the style guide adopted by the R core 
team. 
S> Representing it as the "official" R style guide is just inviting a 
torrent
S> of flaming email.

Yes, indeed, thank you Sharpie.
You have given a wise and balanced answer earlier in this
thread, and that *was* close to probably most R core
members opinions.
Can we please, Peng, close this thread now?

Martin Maechler, ETH Zurich (and R-core).

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

[Rd] tm and e1071 question

[Jeszenszky Peter]

Dear Developers,

I would like to use the svm function of the e1071 package for text
classification tasks. Preprocessing can be carried out by using the
excellent tm text mining package.

TermDocumentMatrix and DocumentTermMatrix objects of the package tm
are currently implemented based on the sparse matrix data structures
provided by the slam package.

Unfortunately, the svm function of the e1071 package accepts only sparse
matrices of class Matrix provided by the Matrix package, or of class
matrix.csr as provided by the package SparseM.

In order to train an SVM with a DocumentTermMatrix object the latter
must be converted to a matrix.csr sparse matrix structure. However, none
of the publicly available packages of CRAN provides such a conversion
function. It is quite straightforward to write the conversion function,
but it would be much confortable to pass slam sparse matrix objects
directly to the svm function.

Do you plan to add slam sparse matrix support to the e1071 package?

Best regards,

Peter Jeszenszky

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

Re: [Rd] (PR#14103) read.csv confused by newline characters in header

[Prof Brian Ripley]

It's not to do with pushback per se.  The works as one might expect, 
e.g.


f <- file("test.txt", "r")
pushBack('"A1\nA2"', f)
pushBackLength(f)
scan(f, "", quote='"')

gives "A1\nA2" on a single line, then whatever was in test.txt.
Rather, the issue is

if (header) {
readLines(file, 1L)  # skip over header

and that stops at the embedded newline.  The fix is to read the header 
again the same way as before.


It seems to me that this is esoteric and the fix could tickle similar 
esoteric constructions, so I am only going to put the fix into R-devel 
and not the upcoming 2.10.1.



On Wed, 2 Dec 2009, Peter Dalgaard wrote:


g.russ...@eos-solutions.com wrote:

Full_Name: George Russell
Version: 2.10.0
OS: Microsoft Windows XP Service Pack 2
Submission from: (NULL) (217.111.3.131)


The following code (typed into R --vanilla)

testString <- '"B1\nB2"\n1\n'
con <- textConnection(testString)
tab <- read.csv(con,stringsAsFactors = FALSE)

produces a data frame with with one row and one column; the name of the column
is "B1.B2" (alright so far). However according to
print(tab[[1,1]])

the value of the entry in the first row and first column is

"B2\n1\n"

So B2 has somehow got into both the names of the data frame and its entry.
Either R is confused or I am. What is going on?


Presumably, read.table is not obeying quotes when removing what it
thinks is the header line. Another variation is this:


tab <- read.table(stdin(), head=T)

0: "B1
0: B2"
1: 1
2:

tab

 B1.B2
1   B2"
2 1


It's somehow connected to the

pushBack(c(lines, lines), file)

bits in readtable.R, but I don't quite get it.

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



--
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] (PR#14103) read.csv confused by newline characters in

[ripley]

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

--27464147-536455723-1259929222=:18586
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: 

It's not to do with pushback per se.  The works as one might expect, 
e.g.

f <- file("test.txt", "r")
pushBack('"A1\nA2"', f)
pushBackLength(f)
scan(f, "", quote='"')

gives "A1\nA2" on a single line, then whatever was in test.txt.
Rather, the issue is

 if (header) {
 readLines(file, 1L)  # skip over header

and that stops at the embedded newline.  The fix is to read the header 
again the same way as before.

It seems to me that this is esoteric and the fix could tickle similar 
esoteric constructions, so I am only going to put the fix into R-devel 
and not the upcoming 2.10.1.


On Wed, 2 Dec 2009, Peter Dalgaard wrote:

> g.russ...@eos-solutions.com wrote:
>> Full_Name: George Russell
>> Version: 2.10.0
>> OS: Microsoft Windows XP Service Pack 2
>> Submission from: (NULL) (217.111.3.131)
>>
>>
>> The following code (typed into R --vanilla)
>>
>> testString <- '"B1\nB2"\n1\n'
>> con <- textConnection(testString)
>> tab <- read.csv(con,stringsAsFactors = FALSE)
>>
>> produces a data frame with with one row and one column; the name of the 
>> column
>> is "B1.B2" (alright so far). However according to
>> print(tab[[1,1]])
>>
>> the value of the entry in the first row and first column is
>>
>> "B2\n1\n"
>>
>> So B2 has somehow got into both the names of the data frame and its entry.
>> Either R is confused or I am. What is going on?
>
> Presumably, read.table is not obeying quotes when removing what it
> thinks is the header line. Another variation is this:
>
>> tab <- read.table(stdin(), head=T)
> 0: "B1
> 0: B2"
> 1: 1
> 2:
>> tab
>  B1.B2
> 1   B2"
> 2 1
>
>
> It's somehow connected to the
>
> pushBack(c(lines, lines), file)
>
> bits in readtable.R, but I don't quite get it.
>
> --
>   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
>

-- 
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
--27464147-536455723-1259929222=:18586--

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

Re: [Rd] raster support in graphics devices

[Gabor Grothendieck]

Currently I have an application that saves the current graphics image (that
was created with classic graphics or grid graphics) to a file and then reads
the file back in using readBin:

png("my.png")
plot(1:10)
dev.off()
raw.img <- readBin("my.png", "raw", size = 1, n = 1)

(I am doing this on Windows but would like to be able to do it on any
platform.)

Does the new raster functionality give me any way to get the object raw.img
without creating the intermediate file, my.png?  If so what is the
corresponding code?


On Mon, Nov 30, 2009 at 8:17 PM, Paul Murrell wrote:

> Hi
>
> This is for developers of extension packages that provide extra *graphics
> devices* for R.
>
> In the *development* version of R, support has been added to the graphics
> engine for sending raster images (bitmaps) to a graphics device.  This
> consists mainly of two new device functions:  dev_Raster() and dev_Cap().
>
> The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6 as
> a marker of this change.
>
> This means that, at a minimum, all graphics devices should be updated to
> provide dummy implementations of these new functions that just say the
> feature is not yet implemented (see for example the PicTeX and XFig devices
> in the 'grDevices' package).
>
> A full implementation of dev_Raster() should be able to draw a raster image
> (provided as an array of 32-bit R colors) at any size, possibly (bilinear)
> interpolated (otherwise nearest-neighbour), at any orientation, and with a
> per-pixel alpha channel.  Where these are not natively supported by a
> device, the graphics engine provides some routines for scaling and rotating
> raster images (see for example the X11 device).  The dev_Cap() function
> should return a representation of a raster image captured from the current
> device.  This will only make sense for some devices (see for example the
> Cairo device in the 'grDevices' package).
>
> A little more information and a couple of small examples are provided at
> http://developer.r-project.org/Raster/raster-RFC.html
>
> Paul
> --
> Dr Paul Murrell
> Department of Statistics
> The University of Auckland
> Private Bag 92019
> Auckland
> New Zealand
> 64 9 3737599 x85392
> p...@stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Rd] raster support in graphics devices

[baptiste auguie]

Hi,

You can use grid.cap,

x11()
plot(1:10)
g = grid.cap()
dev.off()
str(g)
# chr [1:672, 1:671] "white" "white" "white" "white" "white" ...

but as far as I understand in ?grid.cap and the underlying code there
is no "capGrob" equivalent that wouldn't require opening a new device
before capturing the output.

 I hope I'm mistaken.

Best,

baptiste

2009/12/4 Gabor Grothendieck :
> Currently I have an application that saves the current graphics image (that
> was created with classic graphics or grid graphics) to a file and then reads
> the file back in using readBin:
>
> png("my.png")
> plot(1:10)
> dev.off()
> raw.img <- readBin("my.png", "raw", size = 1, n = 1)
>
> (I am doing this on Windows but would like to be able to do it on any
> platform.)
>
> Does the new raster functionality give me any way to get the object raw.img
> without creating the intermediate file, my.png?  If so what is the
> corresponding code?
>
>
> On Mon, Nov 30, 2009 at 8:17 PM, Paul Murrell wrote:
>
>> Hi
>>
>> This is for developers of extension packages that provide extra *graphics
>> devices* for R.
>>
>> In the *development* version of R, support has been added to the graphics
>> engine for sending raster images (bitmaps) to a graphics device.  This
>> consists mainly of two new device functions:  dev_Raster() and dev_Cap().
>>
>> The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6 as
>> a marker of this change.
>>
>> This means that, at a minimum, all graphics devices should be updated to
>> provide dummy implementations of these new functions that just say the
>> feature is not yet implemented (see for example the PicTeX and XFig devices
>> in the 'grDevices' package).
>>
>> A full implementation of dev_Raster() should be able to draw a raster image
>> (provided as an array of 32-bit R colors) at any size, possibly (bilinear)
>> interpolated (otherwise nearest-neighbour), at any orientation, and with a
>> per-pixel alpha channel.  Where these are not natively supported by a
>> device, the graphics engine provides some routines for scaling and rotating
>> raster images (see for example the X11 device).  The dev_Cap() function
>> should return a representation of a raster image captured from the current
>> device.  This will only make sense for some devices (see for example the
>> Cairo device in the 'grDevices' package).
>>
>> A little more information and a couple of small examples are provided at
>> http://developer.r-project.org/Raster/raster-RFC.html
>>
>> Paul
>> --
>> Dr Paul Murrell
>> Department of Statistics
>> The University of Auckland
>> Private Bag 92019
>> Auckland
>> New Zealand
>> 64 9 3737599 x85392
>> p...@stat.auckland.ac.nz
>> http://www.stat.auckland.ac.nz/~paul/
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>        [[alternative HTML version deleted]]
>
> __
> 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] raster support in graphics devices

[Gabor Grothendieck]

Thanks.

I am looking for the data to be just as if I had read in the png file (or
wmf file or whatever).  grid.cap seems to give a bitmap and then would
require some sort of processing to get the png or wmf, etc. form.  Also note
that I need it for classic graphics and not just grid graphics.

What I have right now works just as I want it _except_ I have to create a
file and then read it back in which seems a waste.

On Fri, Dec 4, 2009 at 9:06 AM, baptiste auguie <
baptiste.aug...@googlemail.com> wrote:

> Hi,
>
> You can use grid.cap,
>
> x11()
> plot(1:10)
> g = grid.cap()
> dev.off()
> str(g)
> # chr [1:672, 1:671] "white" "white" "white" "white" "white" ...
>
> but as far as I understand in ?grid.cap and the underlying code there
> is no "capGrob" equivalent that wouldn't require opening a new device
> before capturing the output.
>
>  I hope I'm mistaken.
>
> Best,
>
> baptiste
>
> 2009/12/4 Gabor Grothendieck :
> > Currently I have an application that saves the current graphics image
> (that
> > was created with classic graphics or grid graphics) to a file and then
> reads
> > the file back in using readBin:
> >
> > png("my.png")
> > plot(1:10)
> > dev.off()
> > raw.img <- readBin("my.png", "raw", size = 1, n = 1)
> >
> > (I am doing this on Windows but would like to be able to do it on any
> > platform.)
> >
> > Does the new raster functionality give me any way to get the object
> raw.img
> > without creating the intermediate file, my.png?  If so what is the
> > corresponding code?
> >
> >
> > On Mon, Nov 30, 2009 at 8:17 PM, Paul Murrell  >wrote:
> >
> >> Hi
> >>
> >> This is for developers of extension packages that provide extra
> *graphics
> >> devices* for R.
> >>
> >> In the *development* version of R, support has been added to the
> graphics
> >> engine for sending raster images (bitmaps) to a graphics device.  This
> >> consists mainly of two new device functions:  dev_Raster() and
> dev_Cap().
> >>
> >> The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6
> as
> >> a marker of this change.
> >>
> >> This means that, at a minimum, all graphics devices should be updated to
> >> provide dummy implementations of these new functions that just say the
> >> feature is not yet implemented (see for example the PicTeX and XFig
> devices
> >> in the 'grDevices' package).
> >>
> >> A full implementation of dev_Raster() should be able to draw a raster
> image
> >> (provided as an array of 32-bit R colors) at any size, possibly
> (bilinear)
> >> interpolated (otherwise nearest-neighbour), at any orientation, and with
> a
> >> per-pixel alpha channel.  Where these are not natively supported by a
> >> device, the graphics engine provides some routines for scaling and
> rotating
> >> raster images (see for example the X11 device).  The dev_Cap() function
> >> should return a representation of a raster image captured from the
> current
> >> device.  This will only make sense for some devices (see for example the
> >> Cairo device in the 'grDevices' package).
> >>
> >> A little more information and a couple of small examples are provided at
> >> http://developer.r-project.org/Raster/raster-RFC.html
> >>
> >> Paul
> >> --
> >> Dr Paul Murrell
> >> Department of Statistics
> >> The University of Auckland
> >> Private Bag 92019
> >> Auckland
> >> New Zealand
> >> 64 9 3737599 x85392
> >> p...@stat.auckland.ac.nz
> >> http://www.stat.auckland.ac.nz/~paul/
> 
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> >[[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>

[[alternative HTML version deleted]]

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

Re: [Rd] raster support in graphics devices

[Gabor Grothendieck]

Just to explain a bit more I am thinking about something like this:

con <- graphicsConnection() # I've just made this up
png(con)
plot(1:10)
dev.off()
raw.img <- readBin(con, "raw", size = 1, n = 1)


On Fri, Dec 4, 2009 at 8:28 AM, Gabor Grothendieck
wrote:

> Currently I have an application that saves the current graphics image (that
> was created with classic graphics or grid graphics) to a file and then reads
> the file back in using readBin:
>
> png("my.png")
> plot(1:10)
> dev.off()
> raw.img <- readBin("my.png", "raw", size = 1, n = 1)
>
> (I am doing this on Windows but would like to be able to do it on any
> platform.)
>
> Does the new raster functionality give me any way to get the object raw.img
> without creating the intermediate file, my.png?  If so what is the
> corresponding code?
>
>
>
> On Mon, Nov 30, 2009 at 8:17 PM, Paul Murrell wrote:
>
>> Hi
>>
>> This is for developers of extension packages that provide extra *graphics
>> devices* for R.
>>
>> In the *development* version of R, support has been added to the graphics
>> engine for sending raster images (bitmaps) to a graphics device.  This
>> consists mainly of two new device functions:  dev_Raster() and dev_Cap().
>>
>> The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6 as
>> a marker of this change.
>>
>> This means that, at a minimum, all graphics devices should be updated to
>> provide dummy implementations of these new functions that just say the
>> feature is not yet implemented (see for example the PicTeX and XFig devices
>> in the 'grDevices' package).
>>
>> A full implementation of dev_Raster() should be able to draw a raster
>> image (provided as an array of 32-bit R colors) at any size, possibly
>> (bilinear) interpolated (otherwise nearest-neighbour), at any orientation,
>> and with a per-pixel alpha channel.  Where these are not natively supported
>> by a device, the graphics engine provides some routines for scaling and
>> rotating raster images (see for example the X11 device).  The dev_Cap()
>> function should return a representation of a raster image captured from the
>> current device.  This will only make sense for some devices (see for example
>> the Cairo device in the 'grDevices' package).
>>
>> A little more information and a couple of small examples are provided at
>> http://developer.r-project.org/Raster/raster-RFC.html
>>
>> Paul
>> --
>> Dr Paul Murrell
>> Department of Statistics
>> The University of Auckland
>> Private Bag 92019
>> Auckland
>> New Zealand
>> 64 9 3737599 x85392
>> p...@stat.auckland.ac.nz
>> http://www.stat.auckland.ac.nz/~paul/
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>

[[alternative HTML version deleted]]

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

Re: [Rd] raster support in graphics devices

[hadley wickham]

> Just to explain a bit more I am thinking about something like this:
>
> con <- graphicsConnection() # I've just made this up
> png(con)
> plot(1:10)
> dev.off()
> raw.img <- readBin(con, "raw", size = 1, n = 1)

It seems to me what you actually want is for graphics devices to
support connections:

rc <- rawConnection("raw.img", "w")
png(rc)
plot(1:10)
dev.off()
close(rc)

Hadley

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

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

Re: [Rd] raster support in graphics devices

[Gabor Grothendieck]

Right.

On Fri, Dec 4, 2009 at 10:53 AM, hadley wickham  wrote:

> > Just to explain a bit more I am thinking about something like this:
> >
> > con <- graphicsConnection() # I've just made this up
> > png(con)
> > plot(1:10)
> > dev.off()
> > raw.img <- readBin(con, "raw", size = 1, n = 1)
>
> It seems to me what you actually want is for graphics devices to
> support connections:
>
> rc <- rawConnection("raw.img", "w")
> png(rc)
> plot(1:10)
> dev.off()
> close(rc)
>
> Hadley
>
> --
> http://had.co.nz/
>

[[alternative HTML version deleted]]

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

Re: [Rd] raster support in graphics devices

[Gabor Grothendieck]

Its not just the time.  Its also the nuisance of having to manage files that
I never needed in the first place.

On Fri, Dec 4, 2009 at 11:01 AM, Romain Francois  wrote:

> On 12/04/2009 03:19 PM, Gabor Grothendieck wrote:
>
>>
>> Thanks.
>>
>> I am looking for the data to be just as if I had read in the png file (or
>> wmf file or whatever).
>>
>
> Hi,
>
> You are after the binary payload of the rendered graph as a png file. So
> you are going to have to go through a png file.
>
> It would be nice to be able to render to a binary connection, like a
> rawConnection, but it seems like an expensive "nice to have"
>
>
>  grid.cap seems to give a bitmap and then would
>> require some sort of processing to get the png or wmf, etc. form.  Also
>> note
>> that I need it for classic graphics and not just grid graphics.
>>
>
> grid.cap does not seem to care, baptiste code uses traditional graphics
>
>
>  What I have right now works just as I want it _except_ I have to create a
>> file and then read it back in which seems a waste.
>>
>
> Can you measure the time it takes to do dev.off() and readBin ?
>
>
>  On Fri, Dec 4, 2009 at 9:06 AM, baptiste auguie<
>> baptiste.aug...@googlemail.com>  wrote:
>>
>>  Hi,
>>>
>>> You can use grid.cap,
>>>
>>> x11()
>>> plot(1:10)
>>> g = grid.cap()
>>> dev.off()
>>> str(g)
>>> # chr [1:672, 1:671] "white" "white" "white" "white" "white" ...
>>>
>>> but as far as I understand in ?grid.cap and the underlying code there
>>> is no "capGrob" equivalent that wouldn't require opening a new device
>>> before capturing the output.
>>>
>>>  I hope I'm mistaken.
>>>
>>> Best,
>>>
>>> baptiste
>>>
>>> 2009/12/4 Gabor Grothendieck:
>>>
 Currently I have an application that saves the current graphics image

>>> (that
>>>
 was created with classic graphics or grid graphics) to a file and then

>>> reads
>>>
 the file back in using readBin:

 png("my.png")
 plot(1:10)
 dev.off()
 raw.img<- readBin("my.png", "raw", size = 1, n = 1)

 (I am doing this on Windows but would like to be able to do it on any
 platform.)

 Does the new raster functionality give me any way to get the object

>>> raw.img
>>>
 without creating the intermediate file, my.png?  If so what is the
 corresponding code?


 On Mon, Nov 30, 2009 at 8:17 PM, Paul Murrell>>> wrote:

  Hi
>
> This is for developers of extension packages that provide extra
>
 *graphics
>>>
 devices* for R.
>
> In the *development* version of R, support has been added to the
>
 graphics
>>>
 engine for sending raster images (bitmaps) to a graphics device.  This
> consists mainly of two new device functions:  dev_Raster() and
>
 dev_Cap().
>>>

> The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6
>
 as
>>>
 a marker of this change.
>
> This means that, at a minimum, all graphics devices should be updated
> to
> provide dummy implementations of these new functions that just say the
> feature is not yet implemented (see for example the PicTeX and XFig
>
 devices
>>>
 in the 'grDevices' package).
>
> A full implementation of dev_Raster() should be able to draw a raster
>
 image
>>>
 (provided as an array of 32-bit R colors) at any size, possibly
>
 (bilinear)
>>>
 interpolated (otherwise nearest-neighbour), at any orientation, and with
>
 a
>>>
 per-pixel alpha channel.  Where these are not natively supported by a
> device, the graphics engine provides some routines for scaling and
>
 rotating
>>>
 raster images (see for example the X11 device).  The dev_Cap() function
> should return a representation of a raster image captured from the
>
 current
>>>
 device.  This will only make sense for some devices (see for example the
> Cairo device in the 'grDevices' package).
>
> A little more information and a couple of small examples are provided
> at
> http://developer.r-project.org/Raster/raster-RFC.html
>
> Paul
> --
> Dr Paul Murrell
> Department of Statistics
> The University of Auckland
> Private Bag 92019
> Auckland
> New Zealand
> 64 9 3737599 x85392
> p...@stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/
> 
>
 
>>>
>>
> --
> Romain Francois
> Professional R Enthusiast
> +33(0) 6 28 91 30 30
> http://romainfrancois.blog.free.fr
> |- http://tr.im/Gq7i : ohloh
> |- http://tr.im/FtUu : new package : highlight
> `- http://tr.im/EAD5 : LondonR slides
>
>

[[alternative HTML version deleted]]

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

Re: [Rd] raster support in graphics devices

[Romain Francois]

On 12/04/2009 03:19 PM, Gabor Grothendieck wrote:


Thanks.

I am looking for the data to be just as if I had read in the png file (or
wmf file or whatever).


Hi,

You are after the binary payload of the rendered graph as a png file. So 
you are going to have to go through a png file.


It would be nice to be able to render to a binary connection, like a 
rawConnection, but it seems like an expensive "nice to have"



grid.cap seems to give a bitmap and then would
require some sort of processing to get the png or wmf, etc. form.  Also note
that I need it for classic graphics and not just grid graphics.


grid.cap does not seem to care, baptiste code uses traditional graphics


What I have right now works just as I want it _except_ I have to create a
file and then read it back in which seems a waste.


Can you measure the time it takes to do dev.off() and readBin ?


On Fri, Dec 4, 2009 at 9:06 AM, baptiste auguie<
baptiste.aug...@googlemail.com>  wrote:


Hi,

You can use grid.cap,

x11()
plot(1:10)
g = grid.cap()
dev.off()
str(g)
# chr [1:672, 1:671] "white" "white" "white" "white" "white" ...

but as far as I understand in ?grid.cap and the underlying code there
is no "capGrob" equivalent that wouldn't require opening a new device
before capturing the output.

  I hope I'm mistaken.

Best,

baptiste

2009/12/4 Gabor Grothendieck:

Currently I have an application that saves the current graphics image

(that

was created with classic graphics or grid graphics) to a file and then

reads

the file back in using readBin:

png("my.png")
plot(1:10)
dev.off()
raw.img<- readBin("my.png", "raw", size = 1, n = 1)

(I am doing this on Windows but would like to be able to do it on any
platform.)

Does the new raster functionality give me any way to get the object

raw.img

without creating the intermediate file, my.png?  If so what is the
corresponding code?


On Mon, Nov 30, 2009 at 8:17 PM, Paul Murrell
Hi

This is for developers of extension packages that provide extra

*graphics

devices* for R.

In the *development* version of R, support has been added to the

graphics

engine for sending raster images (bitmaps) to a graphics device.  This
consists mainly of two new device functions:  dev_Raster() and

dev_Cap().


The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6

as

a marker of this change.

This means that, at a minimum, all graphics devices should be updated to
provide dummy implementations of these new functions that just say the
feature is not yet implemented (see for example the PicTeX and XFig

devices

in the 'grDevices' package).

A full implementation of dev_Raster() should be able to draw a raster

image

(provided as an array of 32-bit R colors) at any size, possibly

(bilinear)

interpolated (otherwise nearest-neighbour), at any orientation, and with

a

per-pixel alpha channel.  Where these are not natively supported by a
device, the graphics engine provides some routines for scaling and

rotating

raster images (see for example the X11 device).  The dev_Cap() function
should return a representation of a raster image captured from the

current

device.  This will only make sense for some devices (see for example the
Cairo device in the 'grDevices' package).

A little more information and a couple of small examples are provided at
http://developer.r-project.org/Raster/raster-RFC.html

Paul
--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/




--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/Gq7i : ohloh
|- http://tr.im/FtUu : new package : highlight
`- http://tr.im/EAD5 : LondonR slides

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

Re: [Rd] raster support in graphics devices

[hadley wickham]

> Its not just the time.  Its also the nuisance of having to manage files that
> I never needed in the first place.

In general, it's much easier to create output from a R object than
create an R object from output.

It's good programming practice to minimise the number of functions
with side-effects - if all input and output went through connections,
many parts of R would be much easier to program against.

Hadley

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

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

Re: [Rd] boxplot: auto sizing for ylim variable

[Uwe Ligges]

violet lock wrote:

Sorry, I though I had reposted the question-  I was trying to create a
barplot- I just solved it by looping and setting the program to graph as
subset of the data.  The size is a parameter so the user can reset it if
needed

bargraph <- function(table) {
barplot(table,  main="Title", xlim=c(0,120), horiz=TRUE, las=2)
}
...calc of j and end...
smaller_table=bigtable[j:end]
bargraph(smaller_table)



Still not reproducible, hence not helpful - we cannot see anything...

Uwe Ligges







On Wed, Dec 2, 2009 at 3:02 PM, Greg Snow  wrote:


I don't understand your question.  Are you trying to create a boxplot or
barplot (you mention both), what scaling is not happening automatically that
you would like?

Can you give a simple example of what you have tried, what results you are
seeing and what results you would like to see instead?

--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111



-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
project.org] On Behalf Of violet lock
Sent: Tuesday, December 01, 2009 12:34 PM
To: r-devel@r-project.org
Subject: [Rd] boxplot: auto sizing for ylim variable

Dear R-Devel,
I am trying to create a boxplot for a large dataset (about 1500
entries)
 and was wondering if there was away to do auto sizing for the y-axis
of a
horizontal bar plot?  I know I could use a control structure to loop
through
the data instead, but as I know SAS has something does this
automatically I
thought R might as well.

Thanks,
VL

  [[alternative HTML version deleted]]

 >

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


[[alternative HTML version deleted]]

__
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] combine UserDefinedDatabase and regular environments

[Michael Lawrence]

On Wed, Dec 2, 2009 at 11:11 PM, Romain Francois  wrote:

> On 12/03/2009 12:17 AM, Michael Lawrence wrote:
>
>>
>>
>> On Thu, Nov 19, 2009 at 10:54 AM, Romain Francois
>> mailto:romain.franc...@dbmail.com>> wrote:
>>
>>On 11/19/2009 06:14 PM, Michael Lawrence wrote:
>>
>>
>>
>>On Thu, Nov 5, 2009 at 9:58 AM, Romain Francois
>>mailto:romain.franc...@dbmail.com>
>>>>> wrote:
>>
>>Hello,
>>
>>Is it possible to have the effect of UserDefinedDatabase
>>outside of
>>"attached" environments ? Can I disguise an environment of the
>>sys.frames() as a UserDefinedDatabase ?
>>
>>This seems to suggest that it might be possible :
>>
>> > f <- function(){ e <- environment(); class(e) <-
>>"UserDefinedDatabase"; ff }
>> > f()
>>
>>
>>The UserDefinedDatabase support expects an R_ObjectTable C
>> structure
>>embedded within an externalptr as the HASHTAB of the environment.
>> So
>>it's really only possible from C.
>>
>>
>>Sure. Too bad both environments and user defined database use
>>HASHTAB with completely different meanings.
>>
>>What I would want is something like this:
>>
>>f <- function(){
>>attachLocally( getSomeUserDefinedDatabaseFromC()  )
>>HELLO
>>}
>>
>>and the variable associated with the binding "HELLO" would come
>>dynamically from the user defined database.
>>
>>
>>A more concrete example : rJava now has javaImport, that combined
>>with attach allows dynamic lookup for class names within a set of
>>imported java package paths:
>>
>>attach( javaImport( "java.util" ), name = "java:java.util" )
>>v <- new( Vector )
>>m <- new( HashMap )
>>
>>This is nice, but then as usual with attach, you forget to detach,
>>... this question is about to find a way to have this instead:
>>
>>f <- function(){
>>import( "java.util" )
>>v <- new( Vector )
>>v$add( 1 )
>>v
>>}
>>
>>where the "java.util" is no more looked up when f returns.
>>
>>
>>
>> Probably no clean way to accomplish that. But you could always use
>> with() if you can get that Java package as an environment.
>>
>
> Thanks for keeping this live. This would work if there was a way to
> enumerate classes from a java package, which is not always possible because
> of the flexibility of the java class loader mechanism. You can for example
> quite easily create a class loader that generates an infinity of classes ...
>
>
But wouldn't the environment be a user database and thus robust to such
changes? In qtbase, class objects and instance objects are user-defined
databases. R users can add methods to R extensions of C++ classes, and the
instances all are kept in sync.

Romain
>
>
>  Or use
>> environment<-() to enclose your function in it. That's actually fairly
>> Java-like, as normally the import has file scope and your classes are
>> enclosed within that file.
>>
>> Michael
>>
>
>
> --
> Romain Francois
> Professional R Enthusiast
> +33(0) 6 28 91 30 30
> http://romainfrancois.blog.free.fr
> |- http://tr.im/Gq7i : ohloh
> |- http://tr.im/FtUu : new package : highlight
> `- http://tr.im/EAD5 : LondonR slides
>
>

[[alternative HTML version deleted]]

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

[Rd] Task View for Marketing

[Charlotte Maia]

Hi

I was wondering if a task view for marketing would be a good idea

I realise that it would have some overlap with other task views.
Social science, cluster and multivariate are the most obvious ones.

There seem to be a lot of packages (quite in your face, if I may say
so) for finance and econometrics (however this is a good thing,
mostly...). However, marketing focused packages seem to be more
obscure.

I don't know how it works overseas, however in my country, of all the
mainstream business disciplines, marketing seems to use the most
statistics. Plus most of the employment opportunities I see for
statisticians in the commercial sector, are in market research, where
database marketing and market segmentation seem to be the hot topics.

I can see how R might be less attractive to marketing graduates than
graduates of finance and economics. However at the same time, I know a
lot of people who have graduated in statistics, who are interested in
marketing...


regards
-- 
Charlotte Maia
http://sites.google.com/site/maiagx/home

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

Re: [Rd] Task View for Marketing

[Achim Zeileis]

Charlotte:


I was wondering if a task view for marketing would be a good idea


Maybe, do you want to volunteer to maintain it?


I realise that it would have some overlap with other task views.
Social science, cluster and multivariate are the most obvious ones.


Yes. I'm not sure how a new "Marketing" view would fit in the mix but 
maybe you have some more precise ideas.


If you would be willing to write such a view and maintain it in the 
future, then I suggest that you put together a list of packages and some 
rough ideas for text and how the marketing view would add to the views 
named above. Send me the ideas (off-list) and then we can decide whether 
to go on or not.


Thanks for the suggestion.
Best,
Z


There seem to be a lot of packages (quite in your face, if I may say
so) for finance and econometrics (however this is a good thing,
mostly...). However, marketing focused packages seem to be more
obscure.

I don't know how it works overseas, however in my country, of all the
mainstream business disciplines, marketing seems to use the most
statistics. Plus most of the employment opportunities I see for
statisticians in the commercial sector, are in market research, where
database marketing and market segmentation seem to be the hot topics.

I can see how R might be less attractive to marketing graduates than
graduates of finance and economics. However at the same time, I know a
lot of people who have graduated in statistics, who are interested in
marketing...


regards
--
Charlotte Maia
http://sites.google.com/site/maiagx/home

__
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