Re: [Rd] section needed in FAQ - Using R (PR#9698)
On May 21, 2007, at 5:59 AM, John Fox wrote: Dear Peter and Ray, I think that Ray's problem finding apropos is that apropos has one p. Interestingly, help.search(appropos) (as suggested by Peter) is able to accommodate the spelling error. Regards, John John Fox, Professor Thanks for your information. I see I was spelling it wrong. Can I make the suggestion that if one does help(help), which I tried, that the page should mention apropos. Perhaps in the See Also section. This was a mistake on my part, but documentation can be helpful in response to user mistakes, rather than fragile. thanx - ray -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Dalgaard Sent: Monday, May 21, 2007 3:15 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Rd] section needed in FAQ - Using R (PR#9698) [EMAIL PROTECTED] wrote: By the way, the R program itself is really badly in need of an appropos() to go alongside help(). Perhaps help() can be renamed to hunt() or huntAndPeck(). help.search(appropos) -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ 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] list element names in S4 class extending list
can list names attributes be preserved through S4 class containment? seems to be so but only if the containment relationship is direct ... see below. setClass(c1, contains=list) [1] c1 l1 = list(a=1, b=2) o1 = new(c1, l1) names(o1) # pleasant surprise [1] a b setClass(c2, contains=c1) [1] c2 o2 = new(c2, l1) names(o2) # sad NULL sessionInfo() R version 2.6.0 Under development (unstable) (2007-05-11 r41535) powerpc-apple-darwin8.9.0 locale: C attached base packages: [1] stats graphics grDevices utils datasets methods [7] base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.5.0 refuses to print enough digits to recover exact floating point values
I have noticed that in R 2.5.0, no method of textual output will print a double mode quantity with more than 15 digits after the decimal point. From the help page (?print.default) it appears that this is intentional, since digits after the fifteenth may be uncertain. However, fifteen digits after the decimal point are not enough to represent all the values that an IEEE-double can take. (You need one more.) This means it is now impossible to write out data in textual format (e.g. in order to manipulate it with another program) and read back in exactly the same values. Some analyses are sensitive to this sort of extra rounding, especially if it happens repeatedly. I'd really appreciate some way of forcing R to print enough digits to represent every possible IEEE double value. I would also argue that this should be the default behavior of dump(), write.table() and friends, and save(...,ascii=TRUE), to prevent data loss. [Tangentially, support for C99 hexadecimal notation for floating point values in input and output would also be nice, but wouldn't help much for interoperability, since very few programs understand it.] zw __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] The R.dll problem
Hi r-devel, I've linked my windows application to the R.dll following the instructions from the R documents, however, my application always encounters C stack limit. Do anyone know why and how to fix this? Thank you very much! [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.5.0 refuses to print enough digits to recover exact floating point values
Zack Weinberg wrote: I have noticed that in R 2.5.0, no method of textual output will print a double mode quantity with more than 15 digits after the decimal point. From the help page (?print.default) it appears that this is intentional, since digits after the fifteenth may be uncertain. However, fifteen digits after the decimal point are not enough to represent all the values that an IEEE-double can take. (You need one more.) This means it is now impossible to write out data in textual format (e.g. in order to manipulate it with another program) and read back in exactly the same values. Some analyses are sensitive to this sort of extra rounding, especially if it happens repeatedly. I'd really appreciate some way of forcing R to print enough digits to represent every possible IEEE double value. I would also argue that this should be the default behavior of dump(), write.table() and friends, and save(...,ascii=TRUE), to prevent data loss. Example: formatC(exp(1), digits=100, width=-1) Uwe Ligges [Tangentially, support for C99 hexadecimal notation for floating point values in input and output would also be nice, but wouldn't help much for interoperability, since very few programs understand it.] zw __ 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] relist, an inverse operator to unlist
Hi Seth, On Mon, May 21, 2007 at 05:15:10PM -0700, Seth Falcon wrote: I will also add that the notion of a default argument on a generic function seems a bit odd to me. If an argument is available for dispatch, I just don't see what sense it makes to have a default. In those cases, the default should be handled by the method that has a signature with said argument matching the missing class. What often does make sense is to define a generic function where some argument are not available for dispatch. For example: setGeneric(foo, signature=flesh, function(flesh, skeleton=attr(flesh, skeleton) standardGeneric(foo))) That's an excellent suggestion. Thanks! However, I had to set the signature to c(numeric, missing) rather than just numeric. I have uploaded a new version here: http://www.econ.upenn.edu/~clausen/computing/relist.R Cheers, Andrew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] The R.dll problem
On May 22, 2007, at 5:33 AM, Ev Whin wrote: Hi r-devel, I've linked my windows application to the R.dll following the instructions from the R documents, however, my application always encounters C stack limit. Are you using threads? If so, you have to disable the C stack limit (R_CStackLimit=-1), because threads may use a varying stack base. If you are not, you better check your code as you may be corrupting the stack. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] inline C/C++ in R: question and suggestion
This is a question and maybe an announcement.
We've been discussing in the group that it would be nice to have a
mechanism for something like inline C/C++ function calls in R. I do
not want to reinvent the wheel, therefore, if something like that
already exists, please give me a hint -- I could not find anything. If
not, here is a working solution, please criticise so I could improve it.
Example: I work on images (Bioconductor:EBImage) and just came to a
point where I need to apply certain functions to image data, which are
grey scale intensities in the range [0,1]. Assume I want to transform my
image data from I(x,y,i) to exp(-(d/s)^2)*I(x,y,i), where I is the
original intensity in dependence on coordinates x,y and frame i; s is a
given value and d^2=(x-centre.x)^2+(y-centre.y)^2 for a given centre.
Trying an R loop will run forever already on moderate image sizes as I
do not see how to vectorize it.
Now, below is the solution using the inline C code, completely in R
and runs instantly. I created a small package inline that simply
encapsulates a quite simple function cfunction. The package source is
available from http://www.ebi.ac.uk/~osklyar/inline -- please give it a
try and I would be happy to hear your comments, both on already existing
implementations for inline calls and on the current one. It is a draft
and I will be happy to improve it (especially comments on how to ensure
that the shared object is unloaded when the function is removed). In the
example below EBImage is not required, I use randomly generated values
instead of images, but the output it quite obvious. After installing
inline the example should just work by copy-pasting.
Best and thanks in advance,
Oleg
code - character(17)
code[1] - SEXP res;
code[2] - int nprotect = 0, nx, ny, nz, x, y;
code[3] - PROTECT(res = Rf_duplicate(a)); nprotect++;
code[4] - nx = INTEGER(GET_DIM(a))[0];
code[5] - ny = INTEGER(GET_DIM(a))[1];
code[6] - nz = INTEGER(GET_DIM(a))[2];
code[7] - double sigma2 = REAL(s)[0] * REAL(s)[0], d2 ;
code[8] - double cx = REAL(centre)[0], cy = REAL(centre)[1], *data,
*rdata;
code[9] - for (int im = 0; im nz; im++) {
code[10] - data = (REAL(a)[im*nx*ny]); rdata =
(REAL(res)[im*nx*ny]);
code[11] - for (x = 0; x nx; x++)
code[12] -for (y = 0; y ny; y++) {
code[13] - d2 = (x-cx)*(x-cx) + (y-cy)*(y-cy);
code[14] - rdata[x + y*nx] = data[x + y*nx] * exp(-d2/sigma2);
code[15] - }}
code[16] - UNPROTECT(nprotect);
code[17] - return res;
library(inline)
funx - cfunction(signature(a=array, s=numeric, centre=numeric), code)
x - array(runif(50*50), c(50,50,1))
res - funx(a=x, s=15, centre=c(30,35))
image(res[,,1])
res - funx(x, 10, c(15,15))
x11(); image(res[,,1])
--
Dr Oleg Sklyar * EBI/EMBL, Cambridge CB10 1SD, England * +44-1223-494466
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.5.0 refuses to print enough digits to recover exact floating point values
On 5/22/07, Uwe Ligges [EMAIL PROTECTED] wrote: Zack Weinberg wrote: I'd really appreciate some way of forcing R to print enough digits to represent every possible IEEE double value. I would also argue that this should be the default behavior of dump(), write.table() and friends, and save(...,ascii=TRUE), to prevent data loss. Example: formatC(exp(1), digits=100, width=-1) Well, okay, now what about dump, write.table, save, etc? zw __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: adding an 'exact' argument to [[
In addition to $ that was mentioned in this thread there is also attr, e.g. names(attributes(CO2)) [1] names row.names class formula outer labels [7] units attr(CO2, f) # matches formula uptake ~ conc | Plant On 5/17/07, Seth Falcon [EMAIL PROTECTED] wrote: Hi all, One of the things I find most problematic in R is the partial matching of names in lists. Robert and I have discussed this and we believe that having a mechanism that does not do partial matching would be of significant benefit to R programmers. To that end, I have written a patch that modifies the behavior of [[ as follows: 1. [[ gains an 'exact' argument with default value NA 2. Behavior of 'exact' argument: exact=NA partial matching is performed as usual, however, a warning will be issued when a partial match occurs. This is the default. exact=TRUE no partial matching is performed. exact=FALSE partial matching is allowed and no warning issued if it occurs. This change has been discussed among R-core members and there appeared to be a general consensus that this approach was a good way to proceed. However, we are interested in other suggestions from the broader R developer community. Some additional rationale for our approach: Lists are used as the underlying data structures in many R programs and in these cases the named elements are not a fixed set of things with a fixed set of names. For these programs, [[ will be used with an argument that gets evaluated at runtime and partial matching here is almost always a disaster. Furthermore, dealing with data that has common prefixes happens often and is not an exceptional circumstance (a precondition for partial matching issues). We have tested a similar patch that simply eliminated partial matching for [[ on all CRAN and Bioconductor packages and did not see any obvious failures. A downside of this approach is that S4 methods on [[ will need to be modified to accommodate the new signature. However, by adding an argument, we are able to move more slowly towards a non-partially matching [[ (eventually, the default could be exact=TRUE, but that is a discussion for another day). + seth -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center http://bioconductor.org __ 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] inline C/C++ in R: question and suggestion
Oleg,
On May 22, 2007, at 1:59 PM, Oleg Sklyar wrote:
We've been discussing in the group that it would be nice to have a
mechanism for something like inline C/C++ function calls in R. I
do not want to reinvent the wheel, therefore, if something like
that already exists, please give me a hint -- I could not find
anything. If not, here is a working solution, please criticise so I
could improve it.
Example: I work on images (Bioconductor:EBImage) and just came to a
point where I need to apply certain functions to image data, which
are grey scale intensities in the range [0,1]. Assume I want to
transform my image data from I(x,y,i) to exp(-(d/s)^2)*I(x,y,i),
where I is the original intensity in dependence on coordinates x,y
and frame i; s is a given value and d^2=(x-centre.x)^2+(y-centre.y)
^2 for a given centre. Trying an R loop will run forever already on
moderate image sizes as I do not see how to vectorize it.
That is actually a (rare) case that can be completely vectorized:
d=(cx-rep(1:dim(I)[1],dim(I)[2]*dim(I)[3]))^2+(cy-rep(1:dim(I)
[2],each=dim(I)[1],times=dim(I)[3]))^2
I=I*exp(-(d/s^2))
Clearly the drawback is the use of memory, but you could vectorize
per frame if you wish. At any rate it's not that slow anyway:
I=array(runif(100*100*10),c(100,100,10))
system.time({d=(cx-rep(1:dim(I)[1],dim(I)[2]*dim(I)[3]))^2+(cy-rep
(1:dim(I)[2],each=dim(I)[1],times=dim(I)[3]))^2;I=I*exp(-(d/s^2))})
user system elapsed
0.022 0.010 0.032
system.time(funx(I,15,c(30,35)))
user system elapsed
0.008 0.001 0.010
Of course C wins, no doubt about that :).
Now, below is the solution using the inline C code, completely in
R and runs instantly. I created a small package inline that
simply encapsulates a quite simple function cfunction. The
package source is available from http://www.ebi.ac.uk/~osklyar/
inline -- please give it a try and I would be happy to hear your
comments, both on already existing implementations for inline
calls and on the current one.
I really like the idea! Except for the fact that it's forcing the use
of C++ which adds unnecessary overhead :P I'd like a configurable
extension [including .m] and the ability to prepend functions as
code. What would be very useful now is a set of tools that would
allow you to construct the source with R commands, so that you could
compute on it, edit it etc. That would be really cool ... you could
even imagine compiling a very restricted set of R into C code ...
yes, I know I'm dreaming ;)
Thanks for the good idea!
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] relist, an inverse operator to unlist
AndrewC == Andrew Clausen [EMAIL PROTECTED] on Tue, 22 May 2007 07:51:54 -0400 writes: AndrewC Hi Seth, AndrewC On Mon, May 21, 2007 at 05:15:10PM -0700, Seth Falcon wrote: I will also add that the notion of a default argument on a generic function seems a bit odd to me. If an argument is available for dispatch, I just don't see what sense it makes to have a default. In those cases, the default should be handled by the method that has a signature with said argument matching the missing class. What often does make sense is to define a generic function where some argument are not available for dispatch. For example: setGeneric(foo, signature=flesh, function(flesh, skeleton=attr(flesh, skeleton) standardGeneric(foo))) AndrewC That's an excellent suggestion. Thanks! However, I had to set the signature AndrewC to c(numeric, missing) rather than just numeric. AndrewC I have uploaded a new version here: AndrewC http://www.econ.upenn.edu/~clausen/computing/relist.R This looks good from far. I won't have time to do anything more about it for the next few days. Please remind me (in private) about it if you don't hear back within one week. Martin AndrewC Cheers, AndrewC Andrew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inline C/C++ in R: question and suggestion
On 5/22/2007 1:59 PM, Oleg Sklyar wrote: This is a question and maybe an announcement. We've been discussing in the group that it would be nice to have a mechanism for something like inline C/C++ function calls in R. I do not want to reinvent the wheel, therefore, if something like that already exists, please give me a hint -- I could not find anything. If not, here is a working solution, please criticise so I could improve it. This would be nice. One suggestion that probably doesn't affect your package: It would be even nicer if R incorporated something that Duncan Temple Lang suggested last year, namely a new kind of quoting that didn't need escapes in the string. He suggested borrowing triple quotes from Python; I suggested something more like heredocs as in shells or Perl, or like \verb in TeX, in case you wanted triple quotes in your C function. It would be nice to settle on something, so that instead of code[1] - SEXP res; code[2] - int nprotect = 0, nx, ny, nz, x, y; code[3] - PROTECT(res = Rf_duplicate(a)); nprotect++; code[4] - nx = INTEGER(GET_DIM(a))[0]; code[5] - ny = INTEGER(GET_DIM(a))[1]; one could use (for example): code - ''' SEXP res; int nprotect = 0, nx, ny, nz, x, y; PROTECT(res = Rf_duplicate(a)); nprotect++; nx = INTEGER(GET_DIM(a))[0]; ny = INTEGER(GET_DIM(a))[1]; ''' I think the only way this would affect your package is that you need to be able to handle embedded newlines in strings, but I can't see why you wouldn't be able to do that automatically. Another suggestion: You might want to allow a list of signatures and code chunks to be passed to the compiler, producing a list of functions to evaluate them, all compiled into one DLL. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inline C/C++ in R: question and suggestion
On Tuesday 22 May 2007 3:52 pm, Duncan Murdoch wrote:
On 5/22/2007 1:59 PM, Oleg Sklyar wrote:
One suggestion that probably doesn't affect your package: It would be
even nicer if R incorporated something that Duncan Temple Lang suggested
last year, namely a new kind of quoting that didn't need escapes in the
string. He suggested borrowing triple quotes from Python; I suggested
something more like heredocs as in shells or Perl, or like \verb in TeX,
in case you wanted triple quotes in your C function. It would be nice
to settle on something, so that instead of
I second that. My favorite implementation of this is in Tcl, where curly
braces {} mean that the text they enclose is unmodified. Since language
constructs using them are normally balanced this is not an impediment.
One extremely useful application of this (aside from long strings) is
specifying inline data frames - I don't know how to do this otherwise.
I.e. something like:
A- scan.string({#
Id Value Mark
1 a 3
2 b 4
# })
best
Vladimir Dergachev
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Quoting (was: inline C/C++ in R: question and suggestion
On 22/05/2007 4:01 PM, Vladimir Dergachev wrote:
On Tuesday 22 May 2007 3:52 pm, Duncan Murdoch wrote:
On 5/22/2007 1:59 PM, Oleg Sklyar wrote:
One suggestion that probably doesn't affect your package: It would be
even nicer if R incorporated something that Duncan Temple Lang suggested
last year, namely a new kind of quoting that didn't need escapes in the
string. He suggested borrowing triple quotes from Python; I suggested
something more like heredocs as in shells or Perl, or like \verb in TeX,
in case you wanted triple quotes in your C function. It would be nice
to settle on something, so that instead of
I second that. My favorite implementation of this is in Tcl, where curly
braces {} mean that the text they enclose is unmodified. Since language
constructs using them are normally balanced this is not an impediment.
That wouldn't work in R, because the parser couldn't tell whether
{ a }
was a block of code or a quoted string.
One extremely useful application of this (aside from long strings) is
specifying inline data frames - I don't know how to do this otherwise.
I.e. something like:
A- scan.string({#
Id Value Mark
1 a 3
2 b 4
# })
When your data doesn't contain quote marks, you can just use regular
quotes to do that. I don't know of a scan.string function, but this works:
A - read.table(textConnection(#
Id Value Mark
1 a 3
2 b 4
#), head = TRUE)
I think DTL's suggestion would be most useful when putting a lot of code
in a string, where the escapes make the code harder to read. For
example, just about any function using a complicated regular expression.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Quoting (was: inline C/C++ in R: question and suggestion
On Tuesday 22 May 2007 4:58 pm, Duncan Murdoch wrote:
On 22/05/2007 4:01 PM, Vladimir Dergachev wrote:
On Tuesday 22 May 2007 3:52 pm, Duncan Murdoch wrote:
On 5/22/2007 1:59 PM, Oleg Sklyar wrote:
I second that. My favorite implementation of this is in Tcl, where curly
braces {} mean that the text they enclose is unmodified. Since language
constructs using them are normally balanced this is not an impediment.
That wouldn't work in R, because the parser couldn't tell whether
{ a }
One easy workaround is to have string{ ... } construct - it should be very
easy to parse string{ differently from { alone.
was a block of code or a quoted string.
One extremely useful application of this (aside from long strings) is
specifying inline data frames - I don't know how to do this otherwise.
I.e. something like:
A- scan.string({#
Id Value Mark
1 a 3
2 b 4
# })
When your data doesn't contain quote marks, you can just use regular
quotes to do that. I don't know of a scan.string function, but this works:
A - read.table(textConnection(#
Id Value Mark
1 a 3
2 b 4
#), head = TRUE)
Cool, thank you !
I think DTL's suggestion would be most useful when putting a lot of code
in a string, where the escapes make the code harder to read. For
example, just about any function using a complicated regular expression.
Also anything using .Tcl(). Quotes in data frame definition are useful because
they could be employed to delimit text fields with spaces in them.
best
Vladimir Dergachev
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Quoting
Vladimir Dergachev wrote: I think DTL's suggestion would be most useful when putting a lot of code in a string, where the escapes make the code harder to read. For example, just about any function using a complicated regular expression. Also anything using .Tcl(). Quotes in data frame definition are useful because they could be employed to delimit text fields with spaces in them. .Tcl() is usually the wrong solution anyway, you really should use tcl() unless absolutely necessary. In some contexts (probably not when using source() ), read.table(stdin()) does the trick too, as does reading from a pipe() connection, at least on Unix/Linux. The latter can be useful to filter out prompt characters. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: adding an 'exact' argument to [[
Hi again, Robert has committed the proposed patch to R-devel. So [[ now has an 'exact' argument and the behavior is as described: Seth Falcon [EMAIL PROTECTED] writes: 1. [[ gains an 'exact' argument with default value NA 2. Behavior of 'exact' argument: exact=NA partial matching is performed as usual, however, a warning will be issued when a partial match occurs. This is the default. exact=TRUE no partial matching is performed. exact=FALSE partial matching is allowed and no warning issued if it occurs. + seth -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center http://bioconductor.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] relist, an inverse operator to unlist
One additional idea. I wonder if reshape might be promoted to a generic and relist made into methods for it. The unlisted version of an object would be the long version and the original version of the list would be the wide version. This would consolidate the two concepts together and make it easier to use since the user could leverage his knowledge of how reshape works to lists where it would work analogously. Essentially reshape(myList, direction = long) would be similar to unlist but would add the attributes need to reverse the procedure and reshape(myList, direction = wide) would perform the inversion. I am not sure if the reshape package has any bearing here as well. On 5/22/07, Andrew Clausen [EMAIL PROTECTED] wrote: Hi Seth, On Mon, May 21, 2007 at 05:15:10PM -0700, Seth Falcon wrote: I will also add that the notion of a default argument on a generic function seems a bit odd to me. If an argument is available for dispatch, I just don't see what sense it makes to have a default. In those cases, the default should be handled by the method that has a signature with said argument matching the missing class. What often does make sense is to define a generic function where some argument are not available for dispatch. For example: setGeneric(foo, signature=flesh, function(flesh, skeleton=attr(flesh, skeleton) standardGeneric(foo))) That's an excellent suggestion. Thanks! However, I had to set the signature to c(numeric, missing) rather than just numeric. I have uploaded a new version here: http://www.econ.upenn.edu/~clausen/computing/relist.R Cheers, Andrew __ 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] Quoting
On Tuesday 22 May 2007 7:05 pm, Peter Dalgaard wrote:
Vladimir Dergachev wrote:
I think DTL's suggestion would be most useful when putting a lot of code
in a string, where the escapes make the code harder to read. For
example, just about any function using a complicated regular expression.
Also anything using .Tcl(). Quotes in data frame definition are useful
because they could be employed to delimit text fields with spaces in
them.
.Tcl() is usually the wrong solution anyway, you really should use tcl()
unless absolutely necessary.
Actually I could not figure out how to use tcl() - it seems to work only to
call a single Tcl/Tk command.
I mostly use .Tcl() to create guis along the lines of
foreach {control desc var value} {
label Just a description title1 0
entry Edit some text text_var {Hello there}
} {
switch -exact -- $control {
label {
label .l$var -text $desc
grid .l$var - -sticky news
}
entry {
label .l$var -text $desc
entry .e$var -variable $var
grid .l$var .e$var -sticky news
global $var
set $var $value
}
# other control types follow
}
}
this can get pretty versatile and works for plots and other things..
best
Vladimir Dergachev
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] regexp bug in very recent r-devel
completion is semi-broken in today's r-devel, and the reason seems to be some regular expression changes: sessionInfo() R version 2.6.0 Under development (unstable) (2007-05-22 r41673) i686-pc-linux-gnu locale: [...] attached base packages: [1] stats graphics grDevices utils datasets methods [7] base regexpr(o, foo, fixed = TRUE) [1] 2 attr(,match.length) [1] 1 gregexpr(o, foo, fixed = FALSE) [[1]] [1] 2 3 attr(,match.length) [1] 1 1 gregexpr(o, foo, fixed = TRUE) *** caught segfault *** address 0xc022fdab, cause 'memory not mapped' Traceback: 1: gregexpr(o, foo, fixed = TRUE) Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace On a different machine, this freezes R for a long time, consuming CPU cycles and a lot of memory, before returning an error: gregexpr(o, foobar, fixed = TRUE) Error in gregexpr(o, foobar, fixed = TRUE) : negative length vectors are not allowed sessionInfo() R version 2.6.0 Under development (unstable) (2007-05-22 r41675) x86_64-unknown-linux-gnu -Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
