[Rd] Phonetic symbols (IPA) in R graphics
Hi all, I would like to add phonetic symbols in my figures. Usually I typeset my documents in LaTeX and I use the tipa [1] package to get International Phonetic Alphabet (IPA) fonts. So, my problem would be solved if I could insert LaTeX commands in the text() function (I guess at least). I would like to avoid using psfrag (that is, inserting a string in the eps figure and then substituting it with the right symbol with dvips) because I would like to work with pdf pictures and pdflatex as well as latex -> dvips -> ps2pdf. If inserting special fonts is not possible at the moment, I would appreciate some hints on how I could go about modifying text() to include this feature. (This is why I post to r-devel instead of r-help) Thank you! Giampiero [1] http://www.essex.ac.uk/linguistics/clmt/latex4ling/tipa/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with tuned Rblas from CRAN with R-2.4.0
I just ran the example on a Win2000/P4 BLAS DLL system. It works fine on 2.4.1 beta (2006-12-10 r40146) as well as 2.5.0 Under development (unstable) (2006-12-10 r40146). I have had the same DLL file for a couple of years now (downloaded from the Wisconsin CRAN if I remember correctly) but occasionally I check the file sizes between the one available on CRAN and the one I have and the size (in bytes) seems to stay the same. Andy __ Andy Jaworski 518-1-01 Process Laboratory 3M Corporate Research Laboratory - E-mail: [EMAIL PROTECTED] Tel: (651) 733-6092 Fax: (651) 736-3122 Uwe Ligges <[EMAIL PROTECTED] .uni-dortmund.de> To Sent by: Daniel Nordlund [EMAIL PROTECTED] <[EMAIL PROTECTED]> -project.org cc r-devel@stat.math.ethz.ch Subject 12/13/2006 01:58 Re: [Rd] Problem with tuned Rblas AMfrom CRAN with R-2.4.0 I just looked into the one for P4 and it does export zdrot_ and works for me. Is your one from CRAN master? Uwe Ligges Daniel Nordlund wrote: > I encountered the following problem in R-2.4.0 for Windows binary downloaded from CRAN (data from R-help post by Ethan Johnsons). I was also using the contributed binary Rblas.dll for Intel P4 chip. The problem doesn't occur with the default Rblas.dll. > > > x=c(3.05176E-05, 0.000457764, 0.003204346, 0.0138855, 0.04165649, 0.09164429, 0.1527405, 0.1963806, 0.1963806, 0.1527405, 0.09164429, 0.04165649, 0.0138855, 0.003204346, 0.000457764, 3.05176E-05) > y=c(0.306, 0.0004566, 0.0031985, 0.0139083, 0.0415539, 0.0917678, 0.1528134, 0.1962831, 0.1962994, 0.1527996, 0.0917336, 0.0415497, 0.0139308, 0.0031917, 0.0004529, 0.301) > fit.lm<-lm(y~x) > summary(fit.lm) > > I got the following popup window error message > >The procedure entry point zdrot_ could not be found in the dynamic link library Rblas.dll > > > After closing the popup, the following was printed in the console: > > Error in chol2inv(Qr$qr[p1, p1, drop = FALSE]) : > lapack routines cannot be loaded > In addition: Warning message: > unable to load shared library 'C:\R\R-2.4.1beta/modules//lapack.dll': > LoadLibrary failure: The specified procedure could not be found. > > I subsequently downloaded R-2.4.1beta from CRAN and had the same problem with the contributed binary Rblas.dll > > > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status beta > major 2 > minor 4.1 > year 2006 > month 12 > day07 > svn rev40137 > language R > version.string R version 2.4.1 beta (2006-12-07 r40137) > > OS: WinXP Pro service pack 2 > > I haven't had any problems with the contributed binary up thru R-2.3.1. I checked the changes file and saw that for R-2.4.0 the Rblas.dll would have to be recompiled, but also that the contributed binaries on CRAN had been updated. However, I couldn’t find any Rblas binaries with a date after 2005. Any suggestions on where to find an Rblas binary for WinXP and P4 chip, or do I need to try to compile one on my own? > > Thanks for any assistance, > > Dan > > Daniel Nordlund > Bothell, WA USA > > __ > 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Phonetic symbols (IPA) in R graphics
If all else fails (and hopefully someone who knows more about fonts and such can give you a better suggestion so you don't even have to try this) then look at the last example for the subplot function in the TeachingDemos package. This shows how you can insert images into a plot, you could create an image file of the symbol you want to use and then have subplot put it in the correct position. Hope this helps, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare [EMAIL PROTECTED] (801) 408-8111 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Giampiero Salvi Sent: Wednesday, December 13, 2006 7:21 AM To: r-devel@r-project.org Subject: [Rd] Phonetic symbols (IPA) in R graphics Hi all, I would like to add phonetic symbols in my figures. Usually I typeset my documents in LaTeX and I use the tipa [1] package to get International Phonetic Alphabet (IPA) fonts. So, my problem would be solved if I could insert LaTeX commands in the text() function (I guess at least). I would like to avoid using psfrag (that is, inserting a string in the eps figure and then substituting it with the right symbol with dvips) because I would like to work with pdf pictures and pdflatex as well as latex -> dvips -> ps2pdf. If inserting special fonts is not possible at the moment, I would appreciate some hints on how I could go about modifying text() to include this feature. (This is why I post to r-devel instead of r-help) Thank you! Giampiero [1] http://www.essex.ac.uk/linguistics/clmt/latex4ling/tipa/ __ 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
[Rd] capturing value of C or Fortran function
Re: src/main/dotcode.c:do_dotCode() The value, if there is one, of a function called by .C or .Fortran is not captured, so one needs a wrapper. To avoid that, the user would have to declare that there is a value, specify its type, and supply an R variable to hold the value. Presumably, all of these could be combined in a new "VALUE=var" parameter. Then do_dotCode could arrange the correct type of C variable to receive the value (for every one of the 66 possible instances of the call), and then transfer that value to 'var'. It seems doable with a strong enough macro, if a bit complicated. Or one could say VALUE= and get the value as a new, (n+1)_th element of the current list value. Of course, existing code naming an argument with "VALUE" would break, so a completely new interface, perhaps .C.function(), .Fortran.function(), would be required to avoid that. Has this facility been ruled out? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] data frame subset patch, take 2
Martin Maechler wrote: > [snip] > Note however that some of these changes are backward > incompatible. I do hope that the changes gaining efficiency > for such large data frames are worth some adaption of > current/old R source code.. > > Feedback on this topic is very welcome! Martin, my feedback would be that changes that improve the efficiency of data frames are very welcome. And if implementing them in a sensible manner breaks some old code in a way that is not obnoxious, i.e., by making some previously sensible behavior less sensible, then it is worthwhile to do so. (Where sensible is defined in terms of the new semantics.) As a particular example, I would consider it OK to break old code that relied on default row names being character data. (But this may not be necessary). -- Tony Plate > > Martin > > __ > 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] Problem with tuned Rblas from CRAN with R-2.4.0
Thanks to Uwe Ligges and Andy Jaworski for their responses. I thought the Rblas I was using was from CRAN master, and I when I encountered the problem originally, I downloaded a new copy from CRAN master. However, I must have misplaced it on download and used an old copy. Long story short, the copy I had was apparently corrupted. I downloaded a new copy from CRAN, and all is functioning. Thanks again for the quick responses. Dan Daniel Nordlund Bothell, WA USA > -Original Message- > From: Uwe Ligges [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 12, 2006 11:58 PM > To: Daniel Nordlund > Cc: r-devel@stat.math.ethz.ch > Subject: Re: [Rd] Problem with tuned Rblas from CRAN with R-2.4.0 > > I just looked into the one for P4 and it does export zdrot_ and works > for me. Is your one from CRAN master? > > Uwe Ligges > > > Daniel Nordlund wrote: > > I encountered the following problem in R-2.4.0 for Windows binary downloaded > from CRAN (data from R-help post by Ethan Johnsons). I was also using the > contributed binary Rblas.dll for Intel P4 chip. The problem doesn't occur > with the > default Rblas.dll. > > > > > > x=c(3.05176E-05, 0.000457764, 0.003204346, 0.0138855, 0.04165649, > > 0.09164429, > 0.1527405, 0.1963806, 0.1963806, 0.1527405, 0.09164429, 0.04165649, 0.0138855, > 0.003204346, 0.000457764, 3.05176E-05) > > y=c(0.306, 0.0004566, 0.0031985, 0.0139083, 0.0415539, 0.0917678, > > 0.1528134, > 0.1962831, 0.1962994, 0.1527996, 0.0917336, 0.0415497, 0.0139308, 0.0031917, > 0.0004529, > 0.301) > > fit.lm<-lm(y~x) > > summary(fit.lm) > > > > I got the following popup window error message > > > >The procedure entry point zdrot_ could not be found in the dynamic link > > library > Rblas.dll > > > > > > After closing the popup, the following was printed in the console: > > > > Error in chol2inv(Qr$qr[p1, p1, drop = FALSE]) : > > lapack routines cannot be loaded > > In addition: Warning message: > > unable to load shared library 'C:\R\R-2.4.1beta/modules//lapack.dll': > > LoadLibrary failure: The specified procedure could not be found. > > > > I subsequently downloaded R-2.4.1beta from CRAN and had the same problem > > with > the contributed binary Rblas.dll > > > > > > platform i386-pc-mingw32 > > arch i386 > > os mingw32 > > system i386, mingw32 > > status beta > > major 2 > > minor 4.1 > > year 2006 > > month 12 > > day07 > > svn rev40137 > > language R > > version.string R version 2.4.1 beta (2006-12-07 r40137) > > > > OS: WinXP Pro service pack 2 > > > > I haven't had any problems with the contributed binary up thru R-2.3.1. I > > checked > the changes file and saw that for R-2.4.0 the Rblas.dll would have to be > recompiled, > but also that the contributed binaries on CRAN had been updated. However, I > couldn’t find any Rblas binaries with a date after 2005. Any suggestions on > where to > find an Rblas binary for WinXP and P4 chip, or do I need to try to compile > one on my > own? > > > > Thanks for any assistance, > > > > Dan > > > > Daniel Nordlund > > Bothell, WA USA > > > > __ > > 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] data frame subset patch, take 2
I think the efficiency gain is worthwhile. Thx. -jason - Original Message - From: "Martin Maechler" <[EMAIL PROTECTED]> To: "Marcus G. Daniels" <[EMAIL PROTECTED]> Cc: ; "Vladimir Dergachev" <[EMAIL PROTECTED]> Sent: Tuesday, December 12, 2006 10:08 AM Subject: Re: [Rd] data frame subset patch, take 2 [SNIP] > Note however that some of these changes are backward > incompatible. I do hope that the changes gaining efficiency > for such large data frames are worth some adaption of > current/old R source code.. > > Feedback on this topic is very welcome! > > Martin > [SNIP] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] data frame subset patch, take 2
On Wednesday 13 December 2006 6:01 am, Martin Maechler wrote:
>
> - Vladimir, have you verified your 'take2' against recent versions
> of R-devel?
Yes.
>
> - If they still work, could you re-post them to R-devel, this
> time using a proper MIME type,
> i.e. most probably one of
> application/x-tar
> application/x-compressed-tar
> application/x-gzip
>
> In case you don't know how to achieve this,
> I'd be interested to get it by "private" e-mail.
No problem. The old e-mail did have a mime type: "text/x-diff".
I am resending the patch - now compressed, hopefully it will get pass whatever
filters are in place.
With regard to speedups in R, here is my wish list - I would greatly
appreciate comments on what makes sense here or not, etc:
1. I greatly miss equivalents of Tcl append and lappend commands - not
the function performed by these commands but efficiency (they are O(1) on
average). Tcl easily handles lists with 1e6 components and strings of 10s of
megabytes in length.
2. It would be nice to have true hashed arrays in R (i.e. O(1) access
times). So far I have used named lists for this, but they are O(n):
> L<-list(); system.time(for(i in 1:1)L[[paste(i)]]<-i);
[1] 2.864 0.004 2.868 0.000 0.000
> L<-list(); system.time(for(i in 1:2)L[[paste(i)]]<-i);
[1] 11.789 0.216 12.004 0.000 0.000
3. Efficient manipulation of large numbers of strings. The big reason
character row.names are slow is because they require a large number of string
objects that slow down garbage collector.
This is possibly not a problem that has an easy solution, here are a
couple of approaches I have considered:
a) Inline strings - use a structure like
union {
struct {
unsigned char size;
char body[15];
} inlined_string; /* use this when size<16 */
struct {
unsigned char flag;
char reserved[7]; /* for 64 bit */
CHRSXP ptr;
} indirect_string; /* use this when flag=255 */
}
This basically turns small strings into an enum type stored
within a 128-bit integer. This would greatly decrease required number of
CHRSXP in many common cases (in particular for many rownames).
The biggest disadvantage is more complicated access to string
data. Also this does not solve the issue of how to deal with 1e6 long
strings - though I feel like 15 characters should be good enough for most
uses.
b) CHRSXPs are always leaf nodes. One could implement true reference
counting
and create a separate garbage collector pool for them. This way one can rely
on reference counting to free string objects during normal operation, but
also keep track of the number of referenced strings during garbage collector
passes - and trigger string garbage collection passes (with a warning) when
the number of referenced strings is much smaller the number of objects in
string pool.
This gets rid of overhead that strings impose on garbage
collector. The disadvantage are very large changes to R code.
best
Vladimir Dergachev
subset.patch.2.diff.gz
Description: GNU Zip compressed data
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] data frame subset patch, take 2
Vladimir Dergachev wrote: > 2. It would be nice to have true hashed arrays in R (i.e. O(1) access > times). So far I have used named lists for this, but they are O(n): > new.env(hash=TRUE) with get/assign/exists works ok. But I suspect its just too easy to use named lists because it is easy, and that has bad performance ramifications for user code (perhaps the R developers are more vigilant about this for the R code itself). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Phonetic symbols (IPA) in R graphics
Hi Giampiero Salvi wrote: > Hi all, > I would like to add phonetic symbols in my figures. Usually I typeset > my documents in LaTeX and I use the tipa [1] package to get > International Phonetic Alphabet (IPA) fonts. So, my problem would be > solved if I could insert LaTeX commands in the text() function (I > guess at least). > > I would like to avoid using psfrag (that is, inserting a string in > the eps figure and then substituting it with the right symbol with > dvips) because I would like to work with pdf pictures and pdflatex > as well as latex -> dvips -> ps2pdf. Take a look at ... Fonts, lines, and transparency in R graphics. R News, 4(2):5-9, September 2004. Non-standard fonts in PostScript and PDF graphics. R News, 6(2):41-47, May 2006. http://www.stat.auckland.ac.nz/~paul/Talks/fonts.pdf Paul > If inserting special fonts is not possible at the moment, I would > appreciate some hints on how I could go about modifying text() to > include this feature. (This is why I post to r-devel instead of > r-help) > > Thank you! > Giampiero > > [1] http://www.essex.ac.uk/linguistics/clmt/latex4ling/tipa/ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 [EMAIL PROTECTED] http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] capturing value of C or Fortran function
Well, fortran subroutines don't really have return values (versus fortran functions, which do - as far as I know that's the only difference between fortran subroutines and functions). There is also a somewhat sticky matter, of C routines that returns fairly complex types, like pointers, strings... and likewise, fortran functions can return rather complex things, like matrices, etc. It is going to be difficult to do a one-size-fit-all solution. So all you are trying to cater for, is a rather small subset of C/fortran functions which returns a single int or a single double? (anything to do with arrays you'll need to "smuggle" the array size out the old-fashion way via argument pointers). Harris A. Jaffee wrote: > Re: src/main/dotcode.c:do_dotCode() > > The value, if there is one, of a function called by .C or .Fortran is not > captured, so one needs a wrapper. To avoid that, the user would have to > declare that there is a value, specify its type, and supply an R variable > to hold the value. Presumably, all of these could be combined in a new > "VALUE=var" parameter. Then do_dotCode could arrange the correct type of > C variable to receive the value (for every one of the 66 possible instances > of the call), and then transfer that value to 'var'. It seems doable with > a strong enough macro, if a bit complicated. Or one could say VALUE= > and get the value as a new, (n+1)_th element of the current list value. > > Of course, existing code naming an argument with "VALUE" would break, so a > completely new interface, perhaps .C.function(), .Fortran.function(), would > be required to avoid that. > > Has this facility been ruled out? > > __ > 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] data frame subset patch, take 2
On Wednesday 13 December 2006 1:23 pm, Marcus G. Daniels wrote: > Vladimir Dergachev wrote: > > 2. It would be nice to have true hashed arrays in R (i.e. O(1) access > > times). So far I have used named lists for this, but they are O(n): > > new.env(hash=TRUE) with get/assign/exists works ok. But I suspect its > just too easy to use named lists because it is easy, and that has bad > performance ramifications for user code (perhaps the R developers are > more vigilant about this for the R code itself). Cool, thank you ! I wonder whether environments could be extended to allow names() to work (altough I see that ls() does the same function) and to allow for(i in E) loops. thank you Vladimir Dergachev __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] data frame subset patch, take 2
Hi, We had the "names" discussion and, AFAIR, the idea that someone might misinterpret the output as suggesting that one could index by number, seemed to kill it. A more reasonable argument against is that names<- is problematic. You can use $, [[ (with character subscripts), and yes ls does sort of do what you want (but sorts the values, not sure if that is good). I think it is also inefficient in that I believe it copies the CHARSXP's (not sure we really need to do that, but I have not had time to sort out the issues). And there is an eapply as well, so ls() is not always needed. mget can be used to retrieve multiple values (and should be much more efficient than multiple calls to get). There is no massign (no one seems to have asked for it), and better design choice might be to vectorize assign. best wishes Robert Vladimir Dergachev wrote: > On Wednesday 13 December 2006 1:23 pm, Marcus G. Daniels wrote: >> Vladimir Dergachev wrote: >>> 2. It would be nice to have true hashed arrays in R (i.e. O(1) access >>> times). So far I have used named lists for this, but they are O(n): >> new.env(hash=TRUE) with get/assign/exists works ok. But I suspect its >> just too easy to use named lists because it is easy, and that has bad >> performance ramifications for user code (perhaps the R developers are >> more vigilant about this for the R code itself). > > Cool, thank you ! > > I wonder whether environments could be extended to allow names() to work > (altough I see that ls() does the same function) and to allow for(i in E) > loops. > >thank you > >Vladimir Dergachev > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Robert Gentleman, PhD Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 PO Box 19024 Seattle, Washington 98109-1024 206-667-7700 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Curious finding in MASS:::confint.glm() tied to eval()
Greetings all,
I was in the process of creating a function to generate profile
likelihood confidence intervals for a proportion using a binomial glm.
This is a component of a larger function to generate and plot confidence
intervals for proportions using the above, along with bootstrap (BCa),
Wilson and Exact to visually demonstrate the variation across the
methods to some folks.
I had initially tried this using:
R version 2.4.0 Patched (2006-11-19 r39944)
However, I just verified that it still occurs in:
R version 2.4.1 RC (2006-12-11 r40157)
In both cases, I started R using '--vanilla' and this is under FC6,
fully updated.
Using the following code, it runs fine:
x <- 14
n <- 35
conf <- 0.95
DF <- data.frame(y = x / n, weights = n)
mod <- glm(y ~ 1, weights = weights, family = binomial(), data = DF)
pl.ci <- plogis(confint(mod, level = conf))
Waiting for profiling to be done...
> pl.ci
2.5 %97.5 %
0.2490412 0.5651094
However, when I encapsulate the above in a function:
PropCI <- function(x, n, conf = 0.95)
{
DF <- data.frame(y = x / n, weights = n)
mod <- glm(y ~ 1, weights = weights, family = binomial(), data = DF)
plogis(confint(mod, level = conf))
}
I get the following:
# Nothing else in the current global environment
> ls()
[1] "PropCI"
> PropCI(14, 35)
Waiting for profiling to be done...
Error in inherits(x, "data.frame") : object "DF" not found
If however, I create a 'DF' in the global environment (which may NOT be
the same 'DF' values as within the function!!):
DF <- data.frame(y = 14 / 35, weights = 35)
> DF
y weights
1 0.4 35
> ls()
[1] "DF" "PropCI"
> PropCI(14, 35)
Waiting for profiling to be done...
2.5 %97.5 %
0.2490412 0.5651094
To my point above about the 'DF' in the global environment not being the
same as the 'DF' within the function body:
> DF <- data.frame(y = 5 / 40, weights = 40)
> DF
y weights
1 0.125 40
> PropCI(14, 35)
Waiting for profiling to be done...
2.5 %97.5 %
0.3752233 0.4217556
Rather scary I think
So, this suggested a problem in where confint.glm() was looking for
'DF'.
I subsequently traced through the code using debug(), having removed
'DF' from the global environment:
> debug(MASS:::confint.glm)
> PropCI(14, 35)
debugging in: confint.glm(mod, level = conf)
...
debug: object <- profile(object, which = parm, alpha = (1 - level)/4,
trace = trace)
Browse[1]>
Error in inherits(x, "data.frame") : object "DF" not found
which brought me to profile.glm():
> debug(MASS:::profile.glm)
> PropCI(14, 35)
Waiting for profiling to be done...
debugging in: profile.glm(object, which = parm, alpha = (1 - level)/4,
trace = trace)
...
debug: mf <- update(fitted, method = "model.frame")
Browse[1]>
Error in inherits(x, "data.frame") : object "DF" not found
which brought me to update.default():
> debug(update.default)
> PropCI(14, 35)
Waiting for profiling to be done...
debugging in: update.default(fitted, method = "model.frame")
...
debug: if (evaluate) eval(call, parent.frame()) else call
Browse[1]>
Error in inherits(x, "data.frame") : object "DF" not found
which brought me to eval():
> debug(eval)
> PropCI(14, 35)
debugging in: eval(mf, parent.frame())
...
debugging in: eval(mf, parent.frame())
debug: .Internal(eval(expr, envir, enclos))
Browse[1]>
Error in inherits(x, "data.frame") : object "DF" not found
Unfortunately, at this point, largely due to lack of sleep of late, my
eyes are sufficiently glazed over and my brain sufficiently vapor locked
that the resolution is not immediately clear and I have not yet dug into
the C code for eval().
Presumably, either I am missing something fundamental here, or there is
a bug where, environment-wise, these respective functions are looking in
the wrong place for 'DF', probably based upon the default environment
arguments noted above.
Any comments from a fresh pair of eyes would be most welcome.
Regards and thanks,
Marc Schwartz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] data frame subset patch, take 2
Robert Gentleman wrote: > Hi, >We had the "names" discussion and, AFAIR, the idea that someone might > misinterpret the output as suggesting that one could index by number, > seemed to kill it. A more reasonable argument against is that names<- is > problematic. > > You can use $, [[ (with character subscripts), and yes ls does sort of > do what you want (but sorts the values, not sure if that is good). I > think it is also inefficient in that I believe it copies the CHARSXP's > (not sure we really need to do that, but I have not had time to sort out I misremembered - it does not copy CHARSXPs. > the issues). And there is an eapply as well, so ls() is not always needed. > > mget can be used to retrieve multiple values (and should be much more > efficient than multiple calls to get). There is no massign (no one seems > to have asked for it), and better design choice might be to vectorize > assign. > > best wishes >Robert > > > > > > Vladimir Dergachev wrote: >> On Wednesday 13 December 2006 1:23 pm, Marcus G. Daniels wrote: >>> Vladimir Dergachev wrote: 2. It would be nice to have true hashed arrays in R (i.e. O(1) access times). So far I have used named lists for this, but they are O(n): >>> new.env(hash=TRUE) with get/assign/exists works ok. But I suspect its >>> just too easy to use named lists because it is easy, and that has bad >>> performance ramifications for user code (perhaps the R developers are >>> more vigilant about this for the R code itself). >> Cool, thank you ! >> >> I wonder whether environments could be extended to allow names() to work >> (altough I see that ls() does the same function) and to allow for(i in E) >> loops. >> >>thank you >> >>Vladimir Dergachev >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > -- Robert Gentleman, PhD Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M2-B876 PO Box 19024 Seattle, Washington 98109-1024 206-667-7700 [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] caching frequently used values
Hi,
I am trying to find an elegant way to compute and store some
frequently used matrices "on demand". The Matrix package already uses
something like this for storing decompositions, but I don't know how
to do it.
The actual context is the following:
A list has information about a basis of a B-spline space (nodes,
order) and gridpoints at which the basis functions would be evaluated
(not necessarily the nodes). Something like this:
bsplinegrid <- list(nodes=1:8,order=4,grid=seq(2,5,by=.2))
I need the design matrix (computed by splineDesign) for various
derivatives (not necessarily known in advance), to be calculated by
the function
bsplinematrix <- function(bsplinegrid, deriv=0) {
x <- bsplinegrid$grid
Matrix(splineDesign(bslinegrid$knots, x, ord=basis$order,
derivs = rep(deriv,length(x
}
However, I don't want to call splineDesign all the time. A smart way
would be storing the calculated matrices in a list inside bsplinegrid.
Pseudocode would look like this:
bsplinematrix <- function(bsplinegrid, deriv=0) {
if (is.null(bsplinegrid$matrices[[deriv+1]])) {
## compute the matrix and put it in the list bsplinegrid$matrices,
## but not of the local copy
}
bsplinegrid$matrices[[deriv+1]]
}
My problem is that I don't know how to modify bsplinegrid$matrices
outside the function -- assignment inside would only modify the local
copy.
Any help would be appreciated -- I wanted to learn how Matrix does it,
but don't know how to display the source with s3 methods (getAnywhere
doesn't work).
Tamas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Using substitute from inside an S4 method
Hi all,
I don't understand why this does not what I expect :
## code start here ##
setClass("num",representation(x="numeric"))
num<-function(x) new("num",x=x)
add<-function(e1,e2) {
cat("Computing
",deparse(substitute(e1)),"+",deparse(substitute(e2)),"\n")
[EMAIL PROTECTED]@x
}
setMethod("+","num",function(e1,e2) {
cat("Computing
",deparse(substitute(e1)),"+",deparse(substitute(e2)),"\n")
[EMAIL PROTECTED]@x
})
a<-num(3.2)
b<-num(-1.4)
add(a,b)
a+b
## code ends here ##
a+b does not work : I would like that add(a,b) and a+b give the exact same
result
I've seen a post on R-devel, but the answer seemed not to apply here.
I've tried to use deparse(substitute(e1,sys.frame(-1))) and
deparse(substitute(e1,sys.frame(-2))) (as it was advised by GG in january
2006). But it did not work.
Therefore, i'm looking for 1) an explanation for this phenomenon (link to a
doc, anything) and/or 2) a way to do what i want, if it is possible.
Thanks a lot
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] caching frequently used values
the idea you are considering is also, at times, referred to as
memoizing. I would not use a list, but rather an environment, and
basically you implement something that first looks to see if there is a
value, and if not, compute and store. It can speed things up a lot in
some examples (and slow them down a lot in others).
Wikipedia amongst other sources:
http://en.wikipedia.org/wiki/Memoization
Environments have advantages over lists here (if there are lots of
matrices the lookup can be faster - make sure you use hash=TRUE), and
reference semantics, which you probably want.
Tamas K Papp wrote:
> Hi,
>
> I am trying to find an elegant way to compute and store some
> frequently used matrices "on demand". The Matrix package already uses
> something like this for storing decompositions, but I don't know how
> to do it.
>
> The actual context is the following:
>
> A list has information about a basis of a B-spline space (nodes,
> order) and gridpoints at which the basis functions would be evaluated
> (not necessarily the nodes). Something like this:
>
> bsplinegrid <- list(nodes=1:8,order=4,grid=seq(2,5,by=.2))
>
> I need the design matrix (computed by splineDesign) for various
> derivatives (not necessarily known in advance), to be calculated by
> the function
>
> bsplinematrix <- function(bsplinegrid, deriv=0) {
> x <- bsplinegrid$grid
> Matrix(splineDesign(bslinegrid$knots, x, ord=basis$order,
> derivs = rep(deriv,length(x
> }
>
> However, I don't want to call splineDesign all the time. A smart way
> would be storing the calculated matrices in a list inside bsplinegrid.
> Pseudocode would look like this:
>
> bsplinematrix <- function(bsplinegrid, deriv=0) {
> if (is.null(bsplinegrid$matrices[[deriv+1]])) {
> ## compute the matrix and put it in the list bsplinegrid$matrices,
> ## but not of the local copy
> }
> bsplinegrid$matrices[[deriv+1]]
> }
>
> My problem is that I don't know how to modify bsplinegrid$matrices
> outside the function -- assignment inside would only modify the local
> copy.
>
> Any help would be appreciated -- I wanted to learn how Matrix does it,
> but don't know how to display the source with s3 methods (getAnywhere
> doesn't work).
>
> Tamas
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] caching frequently used values
Hi Robert,
Thanks for your answer. I would create and environment with
new.env(), but how can I assign and retrieve values based on a
numerical index (the derivative)? The example of the help page of
assign explicitly shows that assign("a[1]") does not work for this
purpose.
Thanks,
Tamas
On Wed, Dec 13, 2006 at 01:54:28PM -0800, Robert Gentleman wrote:
> the idea you are considering is also, at times, referred to as
> memoizing. I would not use a list, but rather an environment, and
> basically you implement something that first looks to see if there is a
> value, and if not, compute and store. It can speed things up a lot in
> some examples (and slow them down a lot in others).
>
> Wikipedia amongst other sources:
> http://en.wikipedia.org/wiki/Memoization
>
> Environments have advantages over lists here (if there are lots of
> matrices the lookup can be faster - make sure you use hash=TRUE), and
> reference semantics, which you probably want.
>
> Tamas K Papp wrote:
> >Hi,
> >
> >I am trying to find an elegant way to compute and store some
> >frequently used matrices "on demand". The Matrix package already uses
> >something like this for storing decompositions, but I don't know how
> >to do it.
> >
> >The actual context is the following:
> >
> >A list has information about a basis of a B-spline space (nodes,
> >order) and gridpoints at which the basis functions would be evaluated
> >(not necessarily the nodes). Something like this:
> >
> >bsplinegrid <- list(nodes=1:8,order=4,grid=seq(2,5,by=.2))
> >
> >I need the design matrix (computed by splineDesign) for various
> >derivatives (not necessarily known in advance), to be calculated by
> >the function
> >
> >bsplinematrix <- function(bsplinegrid, deriv=0) {
> > x <- bsplinegrid$grid
> > Matrix(splineDesign(bslinegrid$knots, x, ord=basis$order,
> > derivs = rep(deriv,length(x
> >}
> >
> >However, I don't want to call splineDesign all the time. A smart way
> >would be storing the calculated matrices in a list inside bsplinegrid.
> >Pseudocode would look like this:
> >
> >bsplinematrix <- function(bsplinegrid, deriv=0) {
> > if (is.null(bsplinegrid$matrices[[deriv+1]])) {
> >## compute the matrix and put it in the list bsplinegrid$matrices,
> >## but not of the local copy
> > }
> > bsplinegrid$matrices[[deriv+1]]
> >}
> >
> >My problem is that I don't know how to modify bsplinegrid$matrices
> >outside the function -- assignment inside would only modify the local
> >copy.
> >
> >Any help would be appreciated -- I wanted to learn how Matrix does it,
> >but don't know how to display the source with s3 methods (getAnywhere
> >doesn't work).
> >
> >Tamas
> >
> >__
> >R-devel@r-project.org mailing list
> >https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> --
> Robert Gentleman, PhD
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M2-B876
> PO Box 19024
> Seattle, Washington 98109-1024
> 206-667-7700
> [EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Segfault in pure R code
On 12/13/06, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> Göran Broström wrote:
> > I tried once more under the debugger, and
> >
> > ++
> > [EMAIL PROTECTED]:~/R/BEMANNING/Doc$ R -d gdb
> > GNU gdb 6.5-debian
> > Copyright (C) 2006 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB. Type "show warranty" for details.
> > This GDB was configured as "i486-linux-gnu"...Using host libthread_db
> > library "/lib/tls/i686/cmov/libthread_db.so.1".
> >
> > (gdb) run
> > Starting program: /usr/local/lib/R/bin/exec/R
> > Failed to read a valid object file image from memory.
> >
> > R version 2.4.0 Patched (2006-10-29 r39744)
> > Copyright (C) 2006 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 certain conditions.
> > Type 'license()' or 'licence()' for distribution details.
> >
> > Natural language support but running in an English locale
> >
> > R is a collaborative project with many contributors.
> > Type 'contributors()' for more information and
> > 'citation()' on how to cite R or R packages in publications.
> >
> > Type 'demo()' for some demos, 'help()' for on-line help, or
> > 'help.start()' for an HTML browser interface to help.
> > Type 'q()' to quit R.
> >
> > [Previously saved workspace restored]
> >
> >
> >> library(xtable)
> >> ?xtable)
> >>
> > Error: syntax error in "?xtable)"
> >
> >> ?xtable
> >> help.start()
> >>
> > Making links in per-session dir ...
> > If '/usr/bin/firefox' is already running, it is *not* restarted, and
> > you must switch to its window.
> > Otherwise, be patient ...
> >
> >> library(bemanning)
> >> load("bemanning07-32.rda")
> >> courses("Ingrid")
> >>
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x080f5026 in R_gc_internal (size_needed=17588127) at memory.c:1313
> > 1313PROCESS_NODES();
> > (gdb)
> >
> >
> > How do I continue?
> >
>
> Ouch. Call the marines...
>
> The error comes from the garbage collector, which means that something
> got corrupted in internal data structures some time previously.
>
> The most important thing is to preserve the bug. Rebuild anything and
> the symptom disappears, but the bug will still be there. So keep the R
> binary, the script, and the .RData file around.
OK, I'll do that. However, I have no time this week to look into the
things you suggest below, but I'll try to get at it next week.
Göran
>
> Some ideas:
>
> Is it reproducible on other machines?
>
> Do you have valgrind installed? Notes for using it are on
> http://developer.r-project.org/valgrind-internal.html
>
> Turning on gctorture() may trigger the bug at an earlier state.
>
> The last resort is to painstakingly backtrace to the point of the
> damage using watchpoints and whatever, but I'd rather not go there
> right away.
>
> -p
> > Göran
> >
> > On 12/12/06, Göran Broström <[EMAIL PROTECTED]> wrote:
> >
> >> On 12/12/06, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> >>
> >>> Göran Broström wrote:
> >>>
> I just caught a segfault:
>
>
>
> > courses("Ingrid")
> >
> >
> *** caught segfault ***
> address 0x99b279c, cause 'memory not mapped'
>
> Traceback:
> 1: structure(y, class = oldClass(x), row.names = attr(x, "row.names"))
> 2: `[.data.frame`(gudata, -(1:5))
> 3: gudata[-(1:5)]
> 4: names(gudata[-(1:5)])
> 5: inherits(x, "factor")
> 6: is.factor(table)
> 7: match(x, table, nomatch = 0)
> 8: who %in% names(gudata[-(1:5)])
> 9: courses("Ingrid")
>
> when running a function 'courses' in an R package without compiled
> code. Is this "possible"? I have got many segfaults when testing my
> own packages, but it has always been caused by stupidities in C or
> Fortran code, never with pure R code.
>
> So, before I start debugging, I'd like to know if a segfault in pure R
> code indicates a bug in R itself, or if it can be in my function?
>
>
>
> >>> By definition, reproducible segfaults in R code are bugs in R, unless
> >>> caused by abuse of .C calls or similar. (Irreproducible ones are often
> >>> hardware faults.)
> >>>
> >>> However, at least presently, you are the only one with a handle on the
> >>> bug. So either you get to do the debugging or you have to provide
> >>> something that others can reproduce.
> >>>
> >>> Astarting point could be to run R under the debugger (R -d gdb) and
> >>> generate a C backtrace, then look at the variables involved.
> >>>
> >> Thanks, Peter,
> >>
> >> the error is reproducible. The full session is
> >>
Re: [Rd] caching frequently used values
On Wed, Dec 13, 2006 at 03:05:46PM -0800, Robert Gentleman wrote:
> e1 = new.env(hash=TRUE)
>
> e1[["1"]] = whateveryouwant
>
> ie. just transform to characters, but I don't see why you want to do
> that - surely there are more informative names to be used -
Because they are derivatives, and best indexed by numbers. I wrote an
example to demonstrate what I think the solution is (for memoizing
powers of numbers). It works, but I am not an experienced programmer:
can you please look at it to check that I do things right and do not
abuse any feature of R?
## memoize powers of integers
createpowerlist <- function(n) {
list(n=n,env=new.env(hash=TRUE))
}
getpower <- function(powerlist,i) {
iname <- as.character(i)
if (exists(iname,powerlist$env))
get(iname,powerlist$env)
else {
res <- i^powerlist$n# result
assign(iname,res,powerlist$env)
res
}
}
cubelist <- createpowerlist(3)
exists("12",cubelist$env) # FALSE
getpower(cubelist,12) # 1728
exists("12",cubelist$env) # TRUE
Thanks,
Tamas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] caching frequently used values
e1 = new.env(hash=TRUE)
e1[["1"]] = whateveryouwant
ie. just transform to characters, but I don't see why you want to do
that - surely there are more informative names to be used -
Tamas K Papp wrote:
> Hi Robert,
>
> Thanks for your answer. I would create and environment with
> new.env(), but how can I assign and retrieve values based on a
> numerical index (the derivative)? The example of the help page of
> assign explicitly shows that assign("a[1]") does not work for this
> purpose.
>
> Thanks,
>
> Tamas
>
> On Wed, Dec 13, 2006 at 01:54:28PM -0800, Robert Gentleman wrote:
>
>> the idea you are considering is also, at times, referred to as
>> memoizing. I would not use a list, but rather an environment, and
>> basically you implement something that first looks to see if there is a
>> value, and if not, compute and store. It can speed things up a lot in
>> some examples (and slow them down a lot in others).
>>
>> Wikipedia amongst other sources:
>> http://en.wikipedia.org/wiki/Memoization
>>
>> Environments have advantages over lists here (if there are lots of
>> matrices the lookup can be faster - make sure you use hash=TRUE), and
>> reference semantics, which you probably want.
>>
>> Tamas K Papp wrote:
>>> Hi,
>>>
>>> I am trying to find an elegant way to compute and store some
>>> frequently used matrices "on demand". The Matrix package already uses
>>> something like this for storing decompositions, but I don't know how
>>> to do it.
>>>
>>> The actual context is the following:
>>>
>>> A list has information about a basis of a B-spline space (nodes,
>>> order) and gridpoints at which the basis functions would be evaluated
>>> (not necessarily the nodes). Something like this:
>>>
>>> bsplinegrid <- list(nodes=1:8,order=4,grid=seq(2,5,by=.2))
>>>
>>> I need the design matrix (computed by splineDesign) for various
>>> derivatives (not necessarily known in advance), to be calculated by
>>> the function
>>>
>>> bsplinematrix <- function(bsplinegrid, deriv=0) {
>>> x <- bsplinegrid$grid
>>> Matrix(splineDesign(bslinegrid$knots, x, ord=basis$order,
>>> derivs = rep(deriv,length(x
>>> }
>>>
>>> However, I don't want to call splineDesign all the time. A smart way
>>> would be storing the calculated matrices in a list inside bsplinegrid.
>>> Pseudocode would look like this:
>>>
>>> bsplinematrix <- function(bsplinegrid, deriv=0) {
>>> if (is.null(bsplinegrid$matrices[[deriv+1]])) {
>>>## compute the matrix and put it in the list bsplinegrid$matrices,
>>>## but not of the local copy
>>> }
>>> bsplinegrid$matrices[[deriv+1]]
>>> }
>>>
>>> My problem is that I don't know how to modify bsplinegrid$matrices
>>> outside the function -- assignment inside would only modify the local
>>> copy.
>>>
>>> Any help would be appreciated -- I wanted to learn how Matrix does it,
>>> but don't know how to display the source with s3 methods (getAnywhere
>>> doesn't work).
>>>
>>> Tamas
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>> --
>> Robert Gentleman, PhD
>> Program in Computational Biology
>> Division of Public Health Sciences
>> Fred Hutchinson Cancer Research Center
>> 1100 Fairview Ave. N, M2-B876
>> PO Box 19024
>> Seattle, Washington 98109-1024
>> 206-667-7700
>> [EMAIL PROTECTED]
>
--
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] caching frequently used values
Tamas K Papp <[EMAIL PROTECTED]> writes:
> On Wed, Dec 13, 2006 at 03:05:46PM -0800, Robert Gentleman wrote:
>
>> e1 = new.env(hash=TRUE)
>>
>> e1[["1"]] = whateveryouwant
>>
>> ie. just transform to characters, but I don't see why you want to do
>> that - surely there are more informative names to be used -
>
> Because they are derivatives, and best indexed by numbers. I wrote an
> example to demonstrate what I think the solution is (for memoizing
> powers of numbers). It works, but I am not an experienced programmer:
> can you please look at it to check that I do things right and do not
> abuse any feature of R?
>
> ## memoize powers of integers
>
> createpowerlist <- function(n) {
> list(n=n,env=new.env(hash=TRUE))
I would do:
new.env(hash=TRUE, parent=emptyenv())
> }
>
> getpower <- function(powerlist,i) {
> iname <- as.character(i)
> if (exists(iname,powerlist$env))
> get(iname,powerlist$env)
> else {
> res <- i^powerlist$n# result
> assign(iname,res,powerlist$env)
> res
That's fine, but you could do:
get(iname, powerlist$env) ==> powerlist$env[[iname]]
assing(iname, res, powerlist$env) ==> powerlist$env[[iname]] <- res
Perhaps that's easier to read since is familiar to those who have used
lists?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] A possible improvement to apropos
Hello all,
I've had the following apropos alternative in my ~/.Rprofile for some
time, and have found it more useful than the current version.
Basically, my version ignores case when searching.
If others find this useful, perhaps apropos could be suitably patched
(and I'd be willing to create such a patch).
+ seth
Here is my version of apropos:
APROPOS <- function (what, where = FALSE, mode = "any")
{
if (!is.character(what))
stop("argument ", sQuote("what"), " must be a character vector")
x <- character(0)
check.mode <- mode != "any"
for (i in seq(search())) {
contents <- ls(pos = i, all.names = TRUE)
found <- grep(what, contents, ignore.case = TRUE, value = TRUE)
if (length(found)) {
if (check.mode) {
found <- found[sapply(found, function(x) {
exists(x, where = i, mode = mode, inherits = FALSE)
})]
}
numFound <- length(found)
x <- c(x, if (where)
structure(found, names = rep.int(i, numFound)) else found)
}
}
x
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] caching frequently used values
I use the R.oo Object class for what has been suggested previously.
The Object class can be thought of as utility wrapper class for
environments (actually environments gained much of its behavior some
time ago when "$" etc was being mapped to get() calls).
For caching to file, take a look at the R.cache package. From ?loadCache:
simulate <- function(mean, sd) {
# 1. Try to load cached data, if already generated
key <- list(mean, sd)
data <- loadCache(key)
if (!is.null(data)) {
cat("Loaded cached data\n")
return(data);
}
# 2. If not available, generate it.
cat("Generating data from scratch...")
data <- rnorm(1000, mean=mean, sd=sd)
Sys.sleep(1) # Emulate slow algorithm
cat("ok\n")
saveCache(data, key=key, comment="simulate()")
data;
}
data <- simulate(2.3, 3.0)
data <- simulate(2.3, 3.5)
data <- simulate(2.3, 3.0) # Will load cached data
>From the 'key' list, loadCache()/saveCache() will calculate a 32-char
hexadecimal hashcode (using the digest package), which is used as a
filename in the .Rcache/ directory. Thus, you don't have to worry
about coming up with unique cache names; the chances for a false hit
using the digest algorithms are very small. As long as the 'key'
object is not too large, this procedure is very fast.
Then, combining both in-memory and on-file caching you can start doing
clever this. In my already too long wish list, I have some ideas on a
special class for in-memory/on-file caching which can be used
globally. For instance, when we run out of memory, in-memory cached
values can be stored to file or discarded and so on. Now probably
someone says this is just about reinventing the swap of already well
developed OSes; I would say we can do much better than a generic swap
since we know what the data is and how long it takes to recalculate it
etc.
Hope this helps
Henrik
Combining the k
On 12/14/06, Tamas K Papp <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 13, 2006 at 03:05:46PM -0800, Robert Gentleman wrote:
>
> > e1 = new.env(hash=TRUE)
> >
> > e1[["1"]] = whateveryouwant
> >
> > ie. just transform to characters, but I don't see why you want to do
> > that - surely there are more informative names to be used -
>
> Because they are derivatives, and best indexed by numbers. I wrote an
> example to demonstrate what I think the solution is (for memoizing
> powers of numbers). It works, but I am not an experienced programmer:
> can you please look at it to check that I do things right and do not
> abuse any feature of R?
>
> ## memoize powers of integers
>
> createpowerlist <- function(n) {
> list(n=n,env=new.env(hash=TRUE))
> }
>
> getpower <- function(powerlist,i) {
> iname <- as.character(i)
> if (exists(iname,powerlist$env))
> get(iname,powerlist$env)
> else {
> res <- i^powerlist$n# result
> assign(iname,res,powerlist$env)
> res
> }
> }
>
> cubelist <- createpowerlist(3)
> exists("12",cubelist$env) # FALSE
> getpower(cubelist,12) # 1728
> exists("12",cubelist$env) # TRUE
>
>
> Thanks,
>
> Tamas
>
> __
> 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
