Re: [Rd] Sweave vignettes and bitmap on windows
While I don't agree with it, this "feature" of bitmap is deliberate according
to Prof. Ripley:
http://tolstoy.newcastle.edu.au/R/devel/04/09/0682.html
- Tom
Tom Short
EPRI
Martin Morgan wrote:
>
> During vignette generation on Windows, Sweave seems to clean up before
> all graphics files are completely processed. For instance, if tmp.Rnw
> is:
>
> \documentclass[12pt]{article}
> \begin{document}
> <<>>=
> bitmap("afile.png")
> plot(1:100)
> dev.off()
> @
> \end{document}
>
> Then:
>
> C:\R\tmp>R CMD Sweave tmp.Rnw
> Writing to file tmp.tex
> Processing code chunks ...
> 1 : echo term verbatim
>
> You can now run LaTeX on 'tmp.tex'
>
> C:\R\tmp>Error: /undefinedfilename in
> (C:\\DOCUME~1\\mtmorgan\\LOCALS~1\\Temp\\R
> Operand stack:
>
> Execution stack:
>%interp_exit .runexec2 --nostringval-- --nostringval--
> --nostringval-
> --nostringval-- --nostringval-- false 1 %stopped_push
> Dictionary stack:
>--dict:1126/1686(ro)(G)-- --dict:0/20(G)-- --dict:70/200(L)--
> Current allocation mode is local
> Last OS error: No such file or directory
> AFPL Ghostscript 8.54: Unrecoverable error, exit code 1
>
> Note Sweave finishes before the error message appears. Adding
> Sys.sleep(10) appears to give ghostscript a chance to finish, and no
> error message is generated.
>
> Are there solutions to this?
>
> C:\R\tmp>R --version
> R version 2.6.0 alpha (2007-09-05 r42789)
> Copyright (C) 2007 The R Foundation for Statistical Computing
> ISBN 3-900051-07-0
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under the terms of the
> GNU General Public License version 2.
> For more information about these matters see
> http://www.gnu.org/licenses/.
>
> Thanks,
> --
> Martin Morgan
> Bioconductor / Computational Biology
> http://bioconductor.org
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
View this message in context:
http://www.nabble.com/Sweave-vignettes-and-bitmap-on-windows-tf4484568.html#a12789148
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xlsReadWrite Pro and embedding objects and files in Excel worksheets
Another option for creating XLS files it to write out HTML instead. Excel can read html files just fine, and a useful trick is giving the html file a .xls extension. So, from the user's point of view, it is an excel file even though it's just an html file. Using html works great for embedding links and formatted tables. You can use the R2HTML package to generate HTML files, including formatting for a large number of R objects. One thing you can't do with this approach is include graphics. In theory you could do that by extending this approach. Excel can read in *.mhtml files, which are multipart mime-encoded bundles that include the html file plus mime-encoded graphics files that go with it. You could generate png files in R to include. Excel will also happily read in mhtml files with a .xls extension. The following links could help you get started: http://en.wikipedia.org/wiki/MHTML http://finzi.psych.upenn.edu/R/library/caTools/html/base64.html I don't know of an R package that has a function to encode files as a multipart mime, but the link above is a good start. - Tom Tom Short EPRI Mark W Kimpel wrote: > > Hans-Peter and other R developers, > > How are you? Have you made any progess with embedding Url's in Excel? > > Well, I have been busy thinking of more things for you to do;) > > My colleagues in the lab are not R literate, and some are barely > computer literate, so I give them everything in Excel workbooks. I have > gradually evolved a system such that these workbooks have become > compendia of my data, output, and methods. That, in fact, is why I > bought the Pro version of xlsReadWritePro. I have been saving graphics > as PDF files, then inserting them as object in Excel sheets. > > What I would like to be able to do is to embed objects (files) in sheets > of a workbook directly from within R. I would also like to be able to > save my current R workspace as an object embedded in a sheet so that in > the future, if packages change, I could go back and recreate the > analysis. I do not need to be able to manuipulate files that R has not > created, like a PDF file from another user. I would, however, like to be > able to save my graphics as PDF files inside a worksheet, even if it > meant creating a temp file or something. > > Before people begin talking about how MySQL or some other database could > handle all that archiving, let me say that that is not what my > colleagues want. They want a nice Excel file that they can take home on > there laptops. One thing I like about worksheets is that they themselves > can contain many embedded files, so it keeps our virtual desks neater > and less confusing. > > Hans, if you could do this, it would be of tremendous benefit to me and > hopefully a lot of people. R developers tend to think that all > scientists are running Linux on 64-bit computers, but most biomedical > researches still store date in Excel files. This won't solve everybody's > needs, but it could be a start. > > Well, let me know what you think. I am cc'ing R-devel to see if any of > those guys have ideas as well. > > Thanks, > Mark > > > > -- > Mark W. Kimpel MD > Neuroinformatics > Department of Psychiatry > Indiana University School of Medicine > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- View this message in context: http://www.nabble.com/xlsReadWrite-Pro-and-embedding-objects-and-files-in-Excel-worksheets-tf3191737.html#a8871790 Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Am I missing something about debugging?
Rather than using debug, I generally like using recover. When called, it shows the call stack, and you can pick what to view. Using option(error=recover) triggers it on errors. You can't step through code as when using browser(), but I find jumping to different points on the call stack to be more useful. - Tom Tom Short EPRI Ross Boylan wrote: > > I would like to be able to trace execution into calls below the current > function, or to follow execution as calls return. This is roughly the > distinction between "step" and "next" in many debuggers. > > I would also like to be able to switch to a location further up the call > stack than the location at which I enter the debugger, to see the > context of the current operations. > > Are there ways to do these things with the R debugger? I've studied the > man pages and FAQ's, and looked at the debug package, but I don't see a > way except for manually calling debug on the function that is about to > be called if I want to descend. That's quite awkward, particularly > since it must be manually undone (the debug package may be better on > that score). I'm also not entirely sure that such recursion > (essentially, debugging within the debugger) is OK. > > I tried looking up the stack with things like sys.calls(), from within > the browser, but they operated as if I were at the top level (e.g., > sys.function(-1) gets an error that it can't go there). I was doing > this in ess, and there's some chance the "can't write .Last.value" error > (wording approximate) cause by having an old version is screwing things > up). > > Since R is interpreted I would expect debugging to be a snap, but these > limitations make me suspect there is something about the language design > that makes implementing these facilities hard. For example, the browser > as documented in the Green book has up and down functions to change the > frame (p. 265); these are conspicuously absent in R. > -- > Ross Boylan wk: (415) 514-8146 > 185 Berry St #5700 [EMAIL PROTECTED] > Dept of Epidemiology and Biostatistics fax: (415) 514-8150 > University of California, San Francisco > San Francisco, CA 94107-1739 hm: (415) 550-1062 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- View this message in context: http://www.nabble.com/Am-I-missing-something-about-debugging--tf2910389.html#a8134920 Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in acosh (win32) (PR#9403)
> This is a bug in the mingw runtime, and not in R. So the difference is > between OSes, not between R versions. Note that > > > acosh(2) > [1] 1.316958 > > acosh(2+0i) > [1] 0+NaNi > > acosh(2+1e-10i) > [1] 1.316958+0i > > so it seems to be happening only for exactly real complex numbers. > I think there are also problems with branch cuts. > Interesting. Unfortunately, that's a common scenerio to convert to complex numbers to ensure complex output if appropriate: acosh(as.complex(-2)) I guess acosh(as.complex(x) + 1e-10i) is a bit better than my current workaround of: myacosh <- function(x) log(x + sqrt(x^2 - 1)) > > On Thu, 30 Nov 2006, [EMAIL PROTECTED] wrote: > > > Full_Name: Tom Short > > Version: 2.4.0 > > OS: Windows XP > > Submission from: (NULL) (68.236.159.227) > > > > > > It looks like there's a bug in acosh with complex number in windows: > > > >> acosh(2) > > [1] 1.316958 > >> acosh(2+0i) > > [1] 0+NaNi > > > > This happens for me on Windows XP with the following versions: > > R version 2.2.0, 2005-10-06, i386-pc-mingw32 > > R version 2.4.0 (2006-10-03) i386-pc-mingw32 > > > > It works fine with the following: > > R version 2.4.0 (2006-10-03) i386-pc-linux-gnu (debian) > > R version 2.1.0, 2005-04-18, i386-pc-linux-gnu (debian) > > > >> acosh(2+0i) > > [1] 1.316958+0i > > > > I didn't find any problem with asinh or atanh taking complex numbers. In > > src/main/complex.c, there are some #ifdef Win32's in z_asin and z_acos, > so it > > may be related to that. > > acosh is unrelated to those. According to this: http://mingw.cvs.sourceforge.net/mingw/runtime/mingwex/complex/cacosh.c?view=markup cacosh uses either casin or cacos, so it looks like they are related. And, the ifdef's for z_acos and z_asin both say "broken for cabs(*z) >= 1", matching this: > acosh(.99+0i) [1] 0+0.1415395i > acosh(1.01+0i) [1] 0+NaNi That also turned up a similar bug in mingw's asinh, this time with real and imaginary components swapped: > asinh(2i) [1] 0+NaNi > asinh(1e-10 + 2i) [1] 1.316958+1.570796i - Tom Tom Short EPRI Solutions, Inc. > > - Tom > > > > Tom Short > > EPRI Solutions, Inc. > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Brian D. Ripley, [EMAIL PROTECTED] > 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 > -- View this message in context: http://www.nabble.com/bug-in-acosh-%28win32%29-%28PR-9403%29-tf2731987.html#a7670239 Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug in acosh (win32) (PR#9403)
Full_Name: Tom Short Version: 2.4.0 OS: Windows XP Submission from: (NULL) (68.236.159.227) It looks like there's a bug in acosh with complex number in windows: > acosh(2) [1] 1.316958 > acosh(2+0i) [1] 0+NaNi This happens for me on Windows XP with the following versions: R version 2.2.0, 2005-10-06, i386-pc-mingw32 R version 2.4.0 (2006-10-03) i386-pc-mingw32 It works fine with the following: R version 2.4.0 (2006-10-03) i386-pc-linux-gnu (debian) R version 2.1.0, 2005-04-18, i386-pc-linux-gnu (debian) > acosh(2+0i) [1] 1.316958+0i I didn't find any problem with asinh or atanh taking complex numbers. In src/main/complex.c, there are some #ifdef Win32's in z_asin and z_acos, so it may be related to that. - Tom Tom Short EPRI Solutions, Inc. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Any interest in "merge" and "by" implementations specifically for so
Kevin, Whether or not the R core developers want to merge these functions in base R, they would make a great little package on CRAN. That way others could easily use them, and for yourself, the package automatically gets updated with new versions of R. It sounds like you're done with the hard parts. All that you need to do is add some documentation along with a couple of configuration files, and you're done. - Tom -- View this message in context: http://www.nabble.com/Any-interest-in-%22merge%22-and-%22by%22-implementations-specifically-for-sorted-data--tf2009595.html#a5595038 Sent from the R devel forum at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Any interest in "merge" and "by" implementations specifically for so
> Hi Tom,
>
> > Now, try sorting and using a loop:
> >
> >> idx <- order(i)
> >> xs <- x[idx]
> >> is <- i[idx]
> >> res <- array(NA, 1e6)
> >> idx <- which(diff(is) > 0)
> >> startidx <- c(1, idx+1)
> >> endidx <- c(idx, length(xs))
> >> f1 <- function(x, startidx, endidx, FUN = sum) {
> > + for (j in 1:length(res)) {
> > + res[j] <- FUN(x[startidx[j]:endidx[j]])
> > + }
> > + res
> > + }
> >> unix.time(res1 <- f1(xs, startidx, endidx))
> > [1] 6.86 0.00 7.04 NA NA
>
> I wonder how much time the sorting, reordering and creation os
> startidx and endidx would add to this time?
Done interactively, sorting and indexing seemed fast. Here are some timings:
> unix.time({idx <- order(i)
+xs <- x[idx]
+is <- i[idx]
+res <- array(NA, 1e6)
+idx <- which(diff(is) > 0)
+startidx <- c(1, idx+1)
+endidx <- c(idx, length(xs))
+ })
[1] 1.06 0.00 1.09 NA NA
> That looks interesting. Does it only work for specific operating
> systems and processors? I will give it a try.
No, as far as I know, it works on all operating systems. Also, it gets a
little faster if you directly put the sum in the function:
> f4 <- function(x, startidx, endidx) {
+ for (j in 1:length(res)) {
+ res[j] <- sum(x[startidx[j]:endidx[j]])
+ }
+ res
+ }
> f5 <- cmpfun(f4)
> unix.time(res5 <- f5(xs, startidx, endidx))
[1] 2.67 0.03 2.95 NA NA
- Tom
--
View this message in context:
http://www.nabble.com/Any-interest-in-%22merge%22-and-%22by%22-implementations-specifically-for-sorted-data--tf2009595.html#a5578580
Sent from the R devel forum at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Any interest in "merge" and "by" implementations specifically for so
Kevin, starting with your idea of sorting first, you can get some speedups
just using R. Start by comparing the base case that Bill used:
> x <- runif(2e6)
> i <- rep(1:1e6, 2)
> unix.time(res0 <- unlist(lapply(split(x,i), sum)))
[1] 11.00 0.16 11.28NANA
Now, try sorting and using a loop:
> idx <- order(i)
> xs <- x[idx]
> is <- i[idx]
> res <- array(NA, 1e6)
> idx <- which(diff(is) > 0)
> startidx <- c(1, idx+1)
> endidx <- c(idx, length(xs))
> f1 <- function(x, startidx, endidx, FUN = sum) {
+ for (j in 1:length(res)) {
+ res[j] <- FUN(x[startidx[j]:endidx[j]])
+ }
+ res
+ }
> unix.time(res1 <- f1(xs, startidx, endidx))
[1] 6.86 0.00 7.04 NA NA
For the case of sum (or averages), you can vectorize this using cumsum as
follows. This won't work for median or max.
> f2 <- function(x, startidx, endidx) {
+ cum <- cumsum(x)
+ res <- cum[endidx]
+ res[2:length(res)] <- res[2:length(res)] - cum[endidx[1:(length(res) -
1)]]
+ res
+ }
> unix.time(res2 <- f2(xs, startidx, endidx))
[1] 0.20 0.00 0.21 NA NA
You can also use Luke Tierney's byte compiler
(http://www.stat.uiowa.edu/~luke/R/compiler/) to speed up the loop for
functions where you can't vectorize:
> library(compiler)
> f3 <- cmpfun(f1)
Note: local functions used: FUN
> unix.time(res3 <- f3(xs, startidx, endidx))
[1] 3.84 0.00 3.91 NA NA
- Tom
--
View this message in context:
http://www.nabble.com/Any-interest-in-%22merge%22-and-%22by%22-implementations-specifically-for-sorted-data--tf2009595.html#a5562816
Sent from the R devel forum at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
