Re: [R] format integer numbers with leading 0

[Lasse Kliemann]

Marc Girondot via R-help  writes:

> I would like format integer number as characters with leading 0 for a 
> fixed width, for example:
>
> 1 shoud be "01"
> 2 shoud be "02"
> 20 should be "20"

formatC(x, width=2, flag="0")


signature.asc
Description: PGP signature
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] delta and sd parameters for power.t.test [solved]

[Lasse Kliemann]

Lasse Kliemann <la...@lassekliemann.de> writes:

> What is the rationale behind having both the delta and sd parameters for
> the power.t.test function? For the relevant noncentrality parameter, we
> only need the ratio delta/sd. If my effect size is given as Cohen's d,
> then I only got that ratio and not sd.
>
> As far as I see, in such a case, I can specify delta=d and leave sd at
> its default value 1.

Looking at the code in src/library/stats/R/power.R has clarified this
for me. The only spots were a given value of sd is actually used is (1)
in the computation of the ncp, where we have sqrt(n/tsample) * delta/sd,
so only the ratio delta/sd counts; (2) when delta is to be computed,
then sd is used for the interval given to uniroot, namely sd * c(1e-7,
1e+7), which I guess is a heuristic to cover all the plausible
values. So, yes, Cohen's d can be passed as delta=d when sd=1 is
maintained. Maybe a comment on this in the documentation would be
helpful. (For example, the pwr package
https://CRAN.R-project.org/package=pwr already mentions Cohen's d, but
that package is non-standard and unfortunately not even contained in the
Debian repositories. So it can make sense to stick with the standard
power.t.test as far as possible.)


signature.asc
Description: PGP signature
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] delta and sd parameters for power.t.test

[Lasse Kliemann]

What is the rationale behind having both the delta and sd parameters for
the power.t.test function? For the relevant noncentrality parameter, we
only need the ratio delta/sd. If my effect size is given as Cohen's d,
then I only got that ratio and not sd.

As far as I see, in such a case, I can specify delta=d and leave sd at
its default value 1. Is this correct or am I missing something?

Thanks.


signature.asc
Description: PGP signature
__
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] Best way to compute a sum

[Lasse Kliemann]

   a - 0 ; for(i in (1:2)) a - a + 1/i
   b - 0 ; for(i in (2:1)) b - b + 1/i
   c - sum(1/(1:2))
   d - sum(1/(2:1))
   order(c(a,b,c,d))
  [1] 1 2 4 3
   bc
  [1] TRUE
   c==d
  [1] FALSE

I'd expected b being the largest, since we sum up the smallest 
numbers first. Instead, c is the largest, which is sum() applied 
to the vector ordered with largest numbers first.

Can anyone shed some light on this?

What is the best way in R to compute a sum while avoiding 
cancellation effects?

By the way, sum() in the above example is much faster than the 
loops, so it would be nice if we could utilize it.


pgpXN7eiBarAS.pgp
Description: PGP signature
__
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] Distance between axis and label adjusted automatically?

[Lasse Kliemann]

Is there a way to have the distance between label and axis 
adjusted automatically? This is interesting in particular for the 
y-axis, when it is not known in beforehand how many digits the 
numbers will have. It may happen then, that numbers and label 
overlap.

All examples that I found work by estimating the required 
distance manually in beforehand and then providing large enough 
margins, or positioning the label far enough away from the axis.

I have a series of plots, that should be done automatically. They 
have different magnitudes in y-direction. So there is no 
universal estimation that looks good in all cases -- of course I 
can provide a safety margin, but it looks stupid when there is 
too much space between label and axis.

I tried to use the relative positioning mechanism of frames, 
roughly like this:

  fb - packGrob(fg,yaxisGrob(vp=dataRegion),side=left)
  fg - packGrob(fg,textGrob(y axis label,rot=90),side=left)

But it appears that the true size of the axis is not respected; 
numbers on the axis and the label still may overlap.

Can anyone provide a simple example how to do this right? I would 
favor a solution using the 'grid' package.

Thank you
Lasse


pgpIwIkCd2SxC.pgp
Description: PGP signature
__
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

[R] PDF too large, PNG bad quality

[Lasse Kliemann]

I wish to save a scatter plot comprising approx. 2 million points
in order to include it in a LaTeX document.

Using 'pdf(...)' produces a file of size about 20 MB, which is 
useless.

Using 'cairo_pdf(...)' produces a smaller file, around 3 MB. This 
is still too large. Not only that the document will be too large, 
but also PDF viewers choke on this. Moreover, Cairo has problems 
with text: by default text looks ugly, like scaled bitmaps. After 
hours of trying different settings, I discovered that choosing a 
different font family can help, e.g.: 'par(family=Mono)'. This 
gives good-looking text. Yet, the problem with the file size 
remains.

There exists the hint to produdc EPS instead and then convert to 
PDF using 'epstopdf'. The resulting PDF files are slightly 
smaller, but still too large, and PDF viewers still don't like 
it.

So I gave PNG a try. PNG files are much smaller and PDF viewers 
have no trouble with them. However, fonts look ugly. The same 
trick that worked for Cairo PDF has no effect for PNG. When I 
view the PNGs with a dedicated viewer like 'qiv', even the fonts 
look good. But not when included in LaTeX; I simply use 
'\includegraphics{...}' and run the document through 'pdflatex'.

I tried both, creating PNG with 'png(...)' and converting from 
PDF to PNG using 'convert' from ImageMagick.

So my questions are:

- Is there a way to produce sufficiently lean PDFs directly in R, 
  even when the plot comprises several million points?

- How to produce a PNG that still looks nice when included in a 
  LaTeX PDF document?

Any hints will be greatly appreciated.

Thank you
Lasse


pgpIsY96C949s.pgp
Description: PGP signature
__
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.

Re: [R] PDF too large, PNG bad quality

[Lasse Kliemann]

* Message by -Greg Snow- from Thu 2009-10-22:
 
 If you want to go the pdf route, then you need to find some way 
 to reduce redundant information while still getting the main 
 points of the plot.  With so many point, I would suggest 
 looking at the hexbin package (bioconductor I think) as one 
 approach, it will not be an identical scatterplot, but will 
 convey the information (possibly better) with much smaller 
 graphics file sizes.  There are other tools like sunflower 
 plots or others, but hexbin has worked well for me.
 
I took a look at the 'hexbin' package, and it is really 
interesting. You were right that it also helps to better display 
the data. Finally, this forced me to learn using the 'grid' 
package :-) I think I will use a pretty high number of bins, so 
the plot looks similar to the scatter plots I am used to -- with 
the addition of colors giving different densities.

 If you want to go the png route, the problem usually comes from 
 scaling the plot after producing it.  So, the solution is to 
 create the plot at the exact size and at the exact resolution 
 that you want to use it at in your document so that no scaling 
 needs to be done.  Use the png function, but don't accept the 
 defaults, choose the size and resolution.  If you later decide 
 on a different size of graph, recreate the file, don't let 
 LaTeX rescale the first one.

This was my strategy so far. For instance, for a figure that is 
to span the whole text block from left to right:

two_third_a4 - 8.3 * 2/3
png(new.png,
width=two_third_a4,
height=two_third_a4,
units=in,
res=300)
plot(...)

Earlier I wrote that the PNG looks good when displayed 
separately, but looks inferior when embedded in the LaTeX PDF 
document. However, I now believe that the dependence is more on 
the viewer application. It looks good displayed separately with 
'qiv', but not with 'feh'. The PDF document looks inferior when 
displayed with 'evince' or 'epdfview', but it looks okay when 
displayed with 'xpdf'. I presume now that this phenomenon it not 
directly R-related.

I thank you and everyone who responded so quickly.

Lasse


pgpA2cmkH4qfO.pgp
Description: PGP signature
__
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.