[Rd] Fwd: [R] size of point symbols

baptiste auguie ba208 at exeter.ac.uk
Wed May 27 19:22:30 CEST 2009


Dear Prof. Ripley and all,


Thank you very much for the pointers and the always insightful  
comments. I'd like to add a few further comments below for the sake of  
discussion,

On 26 May 2009, at 08:35, Prof Brian Ripley wrote:

> I don't know where you get your claims from.  R graphics is handled
> internally in inches, with a device-specific mapping to pixels/points
> etc (which is documented for each device on its help page).  This has
> to be done carefully, as pixels may not be square.

I saw hints of this use of inches in the code but I started off with  
the wrong assumption that symbols would be in mm (partly because  
ggplot2 suggested it would be so, partly because it's the natural unit  
I was taught to use throughout french technical education).

>
> What the meaning of pch=1:23 is in terms of coordinates is not
> documented except via the sources.

  I own Paul Murrell's R graphics book but I don't think the precise  
description of the symbols' size is presented in there. Perhaps a  
useful addition for the next edition?

> The source is function GESymbol in
> file src/main/engine.c, so for example pch = 2 is

Thank you, I failed to pinpoint this.

>
> 	case 2:	/* S triangle - point up */
> 	    xc = RADIUS * GSTR_0;
> 	    r = toDeviceHeight(TRC0 * xc, GE_INCHES, dd);
> 	    yc = toDeviceHeight(TRC2 * xc, GE_INCHES, dd);
> 	    xc = toDeviceWidth(TRC1 * xc, GE_INCHES, dd);
> 	    xx[0] = x; yy[0] = y+r;
> 	    xx[1] = x+xc; yy[1] = y-yc;
> 	    xx[2] = x-xc; yy[2] = y-yc;
> 	    gc->fill = R_TRANWHITE;
> 	    GEPolygon(3, xx, yy, gc, dd);
> 	    break;
>
> which as you see is in inches, not mm as you asserted.  The first line
> sets xc to 0.375 inches for cex=1, for example.
>
> You need to take the stroke width (as set by lty) into account when
> assessing the visual size of symbols
>

Altering the implementation is definitely way out of my league, but  
I'm glad I learned where to find this piece of information should the  
need come in the future.

> On Mon, 25 May 2009, baptiste auguie wrote:
>
>> Dear all,
>>
>>
>> Having received no answer in r-help I'm trying r-devel (hoping this  
>> is not a
>> stupid question).
>>
>> I don't understand the rationale behind the absolute sizes of the  
>> point
>> symbols, and I couldn't find it documented (I got lost in the C code
>> graphics.c and gave up).
>
> You are expected to study the sources for yourself.  That's part of
> the price of R.
>
> There is a manual, 'R Internals', that would have explained to you
> that graphics.c is part of base graphics and hence not of grid
> graphics.

R is a big project, and these implementation details can be hard to  
track down for non-programmers of my sort. That's why I was hoping for  
some hints on r-help first. In particular, it's not clear to me  
whether base graphics and grid graphics share these sort of  
"primitive" pieces of code. I'll have to read R internals.


As a last note, I'd like to share this idea I've contemplated recently  
(currently implementing it at the R level for ggplot2),

The points() symbols (well, rather the par() function, presumably)  
could gain an attribute 'type', say, with a few options:

- 'old' for backward compatibility, this choice would set the symbols  
to use to the current values in the same way that palette() provides a  
default set of colours.

- 'polygons', could provide the user with a set of regular polygons  
ordered by the number of vertices (3 to 6 and circle, for instance)  
with a consistent set of attributes (all having col and fill  
parameters). These could be complemented by starred versions of the  
polygons to make for a larger set of shapes.

Such a design could provide several benefits over the current  
situation, 1) the possible mapping between symbols and data could be  
more straight-forward (in the spirit of the ggplot2 package), 2) the  
symbol size could be made consistent either with a constant area or a  
constant circumscribing circle, thereby conforming with the idea that  
information should minimise visual artefacts in displaying the data  
(I'm not saying this is the case currently, but I feel it may not be  
optimum.).

- perhaps something else --- TeachingDemos has some interesting  
examples in the my.symbols help page.


Thanks again,

baptiste


>
>> The example below uses
>> Grid to check the size of the symbols against a square of 10mm x  
>> 10mm.
>>
>>> checkOneSymbol <- function(pch=0){
>>>  gTree(children=gList(
>>>      rectGrob(0.5, 0.5, width=unit(10, "mm"), height=unit(10,
>>> "mm"),
>>>              gp=gpar(lty=2, fill=NA, col=alpha("black", 0.5))),
>>>  pointsGrob(0.5, 0.5, size=unit(10, "mm"),pch=pch,
>>>      gp=gpar(col=alpha("red", 0.5)))
>>>  ))
>>>
>>> }
>>> all.symbols <- lapply(0:23, checkOneSymbol)
>>>
>>> pdf("symbols.pdf", height=1.2/2.54, width=24.2/2.54)
>>>
>>> vp <- viewport(width=0.5, height=0.5, name="main")
>>> pushViewport(vp)
>>>
>>> pushViewport(viewport(layout=grid.layout(1, 24,
>>>                      widths=unit(10, "mm"),
>>>                      heights=unit(10, "mm"),
>>>                      just="center")))
>>>
>>> for(ii in 0:23){
>>> pushViewport(viewport(layout.pos.col=ii+1, layout.pos.row=1))
>>> grid.draw(all.symbols[[ii+1]])
>>> upViewport(1)
>>> }
>>> dev.off()
>>
>>
>> What dictates the size of each symbol? (in other words, why is pch=21
>> a circle of radius given in inches, while pch=2 is a triangle of base
>> length specified  in mm and offset vertically?, etc.)
>>
>> I'm trying to develop a new symbol for the ggplot2 package where  
>> the size is
>> to be accurately mapped onto the data either in linear size or  
>> area. I was
>> expecting a similar idea behind the choice of base symbols. Is this
>> documented?
>>
>> Best regards,
>>
>> baptiste
>>
>> _____________________________
>>
>> Baptiste Auguié
>>
>> School of Physics
>> University of Exeter
>> Stocker Road,
>> Exeter, Devon,
>> EX4 4QL, UK
>>
>> Phone: +44 1392 264187
>>
>> http://newton.ex.ac.uk/research/emag
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> -- 
> Brian D. Ripley,                  ripley at 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, UK                Fax:  +44 1865 272595



More information about the R-devel mailing list