Skip to content

size of point symbols

3 messages · Brian Ripley, Baptiste Auguie

#
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). The example below uses
Grid to check the size of the symbols against a square of 10mm x 10mm.
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
#
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.

What the meaning of pch=1:23 is in terms of coordinates is not 
documented except via the sources.  The source is function GESymbol in 
file src/main/engine.c, so for example pch = 2 is

 	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
On Mon, 25 May 2009, baptiste auguie wrote:

            
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.

  
    
1 day later
#
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 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).
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?
Thank you, I failed to pinpoint this.
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.
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