Re: [Rd] [R] R drop behavior -- set as option in later version?
>>> Balaji S. Srinivasan stanford.edu> writes:
Balaji> I know the topic of drop=TRUE/FALSE has been
Balaji> discussed quite a bit,
{ indeed and often enough by great minds so that at one point in time
newcomres could believe it was not worth the pain to take it up again ...
There are many much more interesting problems to be tackled!
}
Balaji> discussed quite a bit, but I was wondering whether
Balaji> it might be possible to set "drop=FALSE" as a global
Balaji> setting (e.g. as an option in options()) so that one
Balaji> does not have to remember ...
[..]
No, no, no!
In my book, options() should *NEVER* change fundamental
behavior of function of the S language (nor its R implementation).
Ideally, options() should only influence printed output;
pragmatically a few exceptions have been allowed,
but for some of them I'm not sure it was a wise decision to
introduce.
One of the major features and beauties of S it's that it is a
functional language {in most respects} and functions --- think
about a function in the mathematical sense! --- should not
return different results for the same function arguments
depending on some ``outer settings''.
At the first DSC meeting 1999 (and/or the second, 2001 ?),
several of the R developers had several chats with
John Eaton, author of GNU octave [the first matlab clone],
and I think he also had a talk on this:
He said one of the biggest mistakes (or even the only real bad
mistake) he made in octave development was to allow such
options, more and more, on user requests {many for matlab
compatibility, and matlab was inferior sometimes, and later
changed itself, etc etc}
Balaji> I searched in R-help and did not see any previous
Balaji> proposals along these lines,
for good reasons:
1) it does not at all belong to R-help, but to R-devel
2) if you think more about it, as Gregor has in parts,
see below.
[..]
Gregor> I agree with you that you find yourself typing the
Gregor> same constructs over and over. I think that we need
Gregor> to distinguish two modes of working with R. If you
Gregor> do analysis, then you can really get tired of typing
Gregor> drop=FALSE, na.rm=TRUE etc. But this things are
Gregor> very important when you are programming in R. Since
Gregor> these two modes are not really separated in R I do
Gregor> not think this is an easy task, but it would be
Gregor> great to have it. I had recently the same question
Gregor> for na.rm=TRUE. But imagine how hard would it be to
Gregor> have two separate modes ... argh, probably a mess^2
Gregor> or have I missed something obvious.
Yes, exactly : "Mess ^ 2" --- and if you allow both 'drop' and
'na.rm' options, it's "Mess ^ 3" -- not something anyone really wants!
In the history of S, I think there have been several attempts of
having a hack and an ``own local better'' version of S (or R),
sometimes indeed implemented even via such an options() setting.
Longer term it always becomes a maintenance nightmare
(unless you want to entirely decouple from the rest of the progammeRs)!
Particularly with the high quality assurance code in effect for
R packages -- how could you try to ensure that all packages
work correctly with all such possible options() setting
combinations ??
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Complete documentation gram.y ??
Hi everybody, Does anybody know where I can find documentation about file gram.y?. What I need to do is related to the parse tree. I need the parse tree of a R user defined function for being used by a c++ function. Briefly, I have a C++ function that is used to generate random numbers from a specified objective function and I want to use R just to verified the sintaxis of the function and I want C++ for doing the evaluations of the mentioned function. Thanks for any help in advance. Patricia. ___ Do You Yahoo!? La mejor conexión a Internet y 2GB extra a tu correo por $100 al mes. http://net.yahoo.com.mx __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Complete documentation gram.y ??
On 9/8/2006 10:03 AM, Patricia Bautista wrote: > Hi everybody, > > Does anybody know where I can find documentation about > file gram.y?. It's input to bison (or yacc). You could read bison documentation to find what it does. I don't think there is any documentation for it other than that and the source code itself. Duncan Murdoch What I need to do is related to the > parse tree. I need the parse tree of a R user defined > function for being used by a c++ function. Briefly, I > have a C++ function that is used to generate random > numbers from a specified objective function and I want > to use R just to verified the sintaxis of the function > and I want C++ for doing the evaluations of the > mentioned function. > > Thanks for any help in advance. > Patricia. > > > > > > ___ > Do You Yahoo!? > La mejor conexión a Internet y 2GB extra a tu correo por $100 al mes. > http://net.yahoo.com.mx > > __ > 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] Extending [ method to S4 class and drop argument (PR#9211)
Full_Name: John Verzani
Version: 2.4.0 alpha (2006-09-05 r39134)
OS: linux, gentoo 2.6.17
Submission from: (NULL) (163.238.43.26)
When extending the "[" method to a new S4 class, the default value for the drop
argument is not being found. Here is a small example:
setClass("test",representation(x="character"))
setMethod("[","test",function(x,i,j,...,drop=TRUE) {print(i);print(drop)})
a = new("test",x="fred")
a[1]
resulting in:
[1] 1
Error in print(drop) : argument "drop" is missing, with no default
I'm expecting TRUE for the value of drop. That's correct isn't?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Complete documentation gram.y ??
Patricia Bautista wrote: > Hi everybody, > > Does anybody know where I can find documentation about > file gram.y?. What I need to do is related to the > parse tree. I need the parse tree of a R user defined > function for being used by a c++ function. Briefly, I > have a C++ function that is used to generate random > numbers from a specified objective function and I want > to use R just to verified the sintaxis of the function > and I want C++ for doing the evaluations of the > mentioned function. A function in R can't exist unless its syntactically correct. Or is your function reading a text representation of an R function (from a file or user input as a string)? In which case it would be easier to check the syntax from R just by using 'eval' in a 'try' clause, and then pass the function object to C++ in the usual documented way (as an SEXP). Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extending [ method to S4 class and drop argument (PR#9211)
Try this:
> setClass("test",representation(x="character"))
[1] "test"
> setMethod("[","test",function(x,i,j,...,drop) {
+print(i)
+if (missing(drop)) drop <- TRUE
+print(drop)
+ })
[1] "["
> a = new("test",x="fred")
> a[1]
[1] 1
[1] TRUE
On 9/8/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Full_Name: John Verzani
> Version: 2.4.0 alpha (2006-09-05 r39134)
> OS: linux, gentoo 2.6.17
> Submission from: (NULL) (163.238.43.26)
>
>
> When extending the "[" method to a new S4 class, the default value for the
> drop
> argument is not being found. Here is a small example:
>
> setClass("test",representation(x="character"))
> setMethod("[","test",function(x,i,j,...,drop=TRUE) {print(i);print(drop)})
> a = new("test",x="fred")
> a[1]
>
> resulting in:
>
> [1] 1
> Error in print(drop) : argument "drop" is missing, with no default
>
> I'm expecting TRUE for the value of drop. That's correct isn't?
>
> __
> 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] (PR#9202) Re: Bugs with partial name matching
On Tue, 5 Sep 2006, Anil Maliyekkel wrote: > This problem does not appear when the following is done > > > D = list(ABCD=2:1) > > D$ABC[]=c(3,4) > > D > $ABCD > [1] 2 1 > > $ABC > [1] 3 4 > > > It appears to be a sequence specific bug for the $ operator, which > might explain why it did not occur with my original examples where I > had a character data column, but did appear where I had a numeric > data column that was a sequence. Appearances can be deceptive. The point is that 2:1 and 3:4 are integer vectors but c(3,4) is a double precision vector. Assigning values of a different type into a vector requires copying and so masks the bug. > Going back to the original partial replacement problem, is there > anyway to turn off partial matching, or to selectively apply exact > matching when trying to access a single element? No. > I can get the > desired single element match using the convoluted syntax D["ABC"] > [[1]] and perform partial replacement operations on a new column. > However, it would be nice to have single element access operator that > does exact matching. It wouldn't fix the bug, and we are running low on symbols that could be used. -thomas Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#9202) Re: Bugs with partial name matching
> > I can get the
> > desired single element match using the convoluted syntax D["ABC"]
> > [[1]] and perform partial replacement operations on a new column.
> > However, it would be nice to have single element access operator that
> > does exact matching.
>
> It wouldn't fix the bug, and we are running low on symbols that could be
> used.
SV4 and Splus have a function called elNamed() (and a corresponding
elNamed<-) that does exact matching. E.g.,
> zlist<-list(abc=1, xyz=2)
> elNamed(zlist, "a")
NULL
> elNamed(zlist, "a", mustfind=TRUE) # error should say "element", not "slot"
Problem in elNamed(zlist, "a", mustfind = TRUE): Failed to find required slot
"a"
Use traceback() to see the call stack
> elNamed(zlist, "abc")
[1] 1
> elNamed(zlist, "ab") <- 3
> dput(zlist)
list("abc" = 1
, "xyz" = 2
, "ab" = 3
)
It works on lists and atomic vectors and I think it
is not intended to be a generic function. There is
a similar el(x, i) function for numeric subsetting
that is not intended to be generic (that is for
speed and safety when writing methods for [).
Its only documentation is some self-doc:
> elNamed
# extract or (when used on left of assignment) replace the element of `object'
associated
# with `name'. Differs from `$' in using only exact matching. Set `mustfind=T'
if you
# want an error to occur when there is no such named element. NOT to be used
for slots.
function(object, name, mustfind = F)
.Internal(elNamed(object, name, mustfind), "S_el_named", T, 0)
It isn't used much and has some surprises. E.g.,
elNamed(zlist, "ab")<-NULL
sets $ab to NULL; it doesn't remove it as ab$ab would.
Bill Dunlap
Insightful Corporation
bill at insightful dot com
360-428-8146
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extending [ method to S4 class and drop argument (PR#9211)
Or more in the spirit of method dispatch, and to get some insight into
why this design decision is not a bug:
> setClass("test",representation(x="character"))
[1] "test"
>
> setMethod("[",
+ signature(x="test", drop="missing"),
+ function(x, i, j, ..., drop) {
+ cat("here\n")
+ callNextMethod(x, i, j, ..., drop=TRUE)
+ })
[1] "["
>
> setMethod("[","test",function(x, i, j, ..., drop) {
+ cat("there\n")
+ print(drop)
+ })
[1] "["
>
> a = new("test",x="fred")
> a[1]
here
there
[1] TRUE
'drop' is 'missing', and 'missing' satisfies the implicit 'ANY'
condition in the signature of the original method. With this insight,
the design decision to 'ignore' the default argument seems appropriate
to me -- developers implementing the generic might well want to
dispatch on it, since after all it is in the generic signature. This
could lead to an explosion of methods if many arguments have 'default'
values, but such an explosion probably points to a nice distinction
between arguments-for-dispatch and arguments-for-evaluation.
To tell the truth, I hadn't really understood why the error originally
reported occurred, until writing the method with drop="missing" just
now.
Martin
"Gabor Grothendieck" <[EMAIL PROTECTED]> writes:
> Try this:
>
>> setClass("test",representation(x="character"))
> [1] "test"
>> setMethod("[","test",function(x,i,j,...,drop) {
> +print(i)
> +if (missing(drop)) drop <- TRUE
> +print(drop)
> + })
> [1] "["
>> a = new("test",x="fred")
>> a[1]
> [1] 1
> [1] TRUE
>
>
> On 9/8/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Full_Name: John Verzani
>> Version: 2.4.0 alpha (2006-09-05 r39134)
>> OS: linux, gentoo 2.6.17
>> Submission from: (NULL) (163.238.43.26)
>>
>>
>> When extending the "[" method to a new S4 class, the default value for the
>> drop
>> argument is not being found. Here is a small example:
>>
>> setClass("test",representation(x="character"))
>> setMethod("[","test",function(x,i,j,...,drop=TRUE) {print(i);print(drop)})
>> a = new("test",x="fred")
>> a[1]
>>
>> resulting in:
>>
>> [1] 1
>> Error in print(drop) : argument "drop" is missing, with no default
>>
>> I'm expecting TRUE for the value of drop. That's correct isn't?
>>
>> __
>> 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
--
Martin T. Morgan
Bioconductor / Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024
Seattle, WA 98109
http://bioconductor.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extending [ method to S4 class and drop argument (PR#9211)
Or more in the spirit of method dispatch, and to get some insight into
why this design decision is not a bug:
> setClass("test",representation(x="character"))
[1] "test"
>
> setMethod("[",
+ signature(x="test", drop="missing"),
+ function(x, i, j, ..., drop) {
+ cat("here\n")
+ callNextMethod(x, i, j, ..., drop=TRUE)
+ })
[1] "["
>
> setMethod("[","test",function(x, i, j, ..., drop) {
+ cat("there\n")
+ print(drop)
+ })
[1] "["
>
> a = new("test",x="fred")
> a[1]
here
there
[1] TRUE
'drop' is 'missing', and 'missing' satisfies the implicit 'ANY'
condition in the signature of the original method. With this insight,
the design decision to 'ignore' the default argument seems appropriate
to me -- developers implementing the generic might well want to
dispatch on it, since after all it is in the generic signature. This
could lead to an explosion of methods if many arguments have 'default'
values, but such an explosion probably points to a nice distinction
between arguments-for-dispatch and arguments-for-evaluation.
To tell the truth, I hadn't really understood why the error originally
reported occurred, until writing the method with drop="missing" just
now.
Martin
"Gabor Grothendieck" <[EMAIL PROTECTED]> writes:
> Try this:
>
>> setClass("test",representation(x="character"))
> [1] "test"
>> setMethod("[","test",function(x,i,j,...,drop) {
> +print(i)
> +if (missing(drop)) drop <- TRUE
> +print(drop)
> + })
> [1] "["
>> a = new("test",x="fred")
>> a[1]
> [1] 1
> [1] TRUE
>
>
> On 9/8/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Full_Name: John Verzani
>> Version: 2.4.0 alpha (2006-09-05 r39134)
>> OS: linux, gentoo 2.6.17
>> Submission from: (NULL) (163.238.43.26)
>>
>>
>> When extending the "[" method to a new S4 class, the default value for the
>> drop
>> argument is not being found. Here is a small example:
>>
>> setClass("test",representation(x="character"))
>> setMethod("[","test",function(x,i,j,...,drop=TRUE) {print(i);print(drop)})
>> a = new("test",x="fred")
>> a[1]
>>
>> resulting in:
>>
>> [1] 1
>> Error in print(drop) : argument "drop" is missing, with no default
>>
>> I'm expecting TRUE for the value of drop. That's correct isn't?
>>
>> __
>> 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
--
Martin T. Morgan
Bioconductor / Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024
Seattle, WA 98109
http://bioconductor.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#9202) Re: Bugs with partial name matching
Anil Maliyekkel wrote: > [snip] > > Going back to the original partial replacement problem, is there > anyway to turn off partial matching, or to selectively apply exact > matching when trying to access a single element? I can get the > desired single element match using the convoluted syntax D["ABC"] > [[1]] and perform partial replacement operations on a new column. > However, it would be nice to have single element access operator that > does exact matching. The easiest thing to do is probably to always supply full names, and if you want to create a new component, then create it in its entirity (not by assigning to a subset of a non-existent component). A couple of years ago I proposed (with code) an operator '$$' that did only exact matching, but that proposal didn't gather any interest at the time. It might actually make more sense to have the roles switched, so that the ordinary '$' required exact matches, while the special '$$' allowed partial matching (to allow for convenient interactive use). But, that's probably a bigger change than the R code base & community could bear. Then again, what about the following as a way forward to eliminating partial matching on names for "$" and "[[": (1) Announce that partial matching for "$" and "[[" is deprecated (1a) (optional) Introduce "$$" operator with partial matching, intended solely for interactive use, with QA checks to ensure that it is not used in packages (2) Introduce warnings upon use of partial matching with "$" and "[[", with an option() to turn them off. Initially these warnings are off by default, but QA tools turn them on, and package maintainers see the warnings. (3) After a year or two (assuming most packages no longer contain use of partial matching), change the default warning about partial matching to "on". (4) After another year, eliminate partial matching with "$" and "[[". Opinions? -- Tony Plate > > Anil > > __ > 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] install.packages(,type="source") broken on Windows
Hi,
On Windows, 'install.packages(,type="source")' displays the same output
than 'R CMD INSTALL --help' and doesn't install anything...
This is with R version 2.4.0 alpha (2006-09-06 r39158).
> install.packages('cat',type='source')
trying URL 'http://cran.cnr.Berkeley.edu/src/contrib/cat_0.0-6.tar.gz'
Content type 'application/x-gzip' length 22914 bytes
opened URL
downloaded 22Kb
Unknown option: configure-args
Usage: R CMD INSTALL [options] pkgs
Install the add-on packages specified by pkgs into the default R library
tree (/library) or the tree specified via '--library'. The
elements of pkgs can be relative or absolute paths to directories with
the package (bundle) sources, or to gzipped package 'tar' archives.
Then optionally pack the installed package into a zip file.
Options:
-h, --helpprint short help message and exit
-v, --version print version info and exit
-c, --clean remove all files created during installation
--fakedo minimal install for testing purposes
--unsafe install on top of any existing installation
-d, --debug [x] turn on shell and build-help debugging
-l, --library=LIB install packages to library tree LIB
--docs=TYPE type(s) of documentation to build and install
--with-package-versions
allow for multiple versions of the same package
--use-zip-datacollect data files in zip archive
--use-zip-helpcollect help and examples into zip archives
--use-zip combine '--use-zip-data' and '--use-zip-help'
--auto-zipselect whether to zip automatically
--build zip-up the installation. Implies --auto-zip
TYPE can be "none" or "normal" or "chm" (the default) or "all", or
a comma-separated list of one or more of
'txt', 'html', 'latex', "example' and 'chm'.
Report bugs to <[EMAIL PROTECTED]>.
The downloaded packages are in
c:\temp\RtmpoKYvqb\downloaded_packages
updating HTML package descriptions
H.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] install.packages(,type="source") broken on Windows
[EMAIL PROTECTED] writes: > Hi, > > On Windows, 'install.packages(,type="source")' displays the same output > than 'R CMD INSTALL --help' and doesn't install anything... Yes. The culprit is r39127 | urbaneks | 2006-09-05 20:45:00 +0200 (Tue, 05 Sep 2006) | 1 line Bugfix: install.packages ignored unnamed configure.args which forgets to check whether there are any args to name. (There is a generic issue in that available.packages has a configure.args argument which is passed on to --configure-args in the INSTALL script: The Windows INSTALL doesn't understand the argument since configure doesn't work on Windows. However, things should work when no such arguments are passed.) -- 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
Re: [Rd] install.packages(,type="source") broken on Windows
OK thanks. Just FYI the same thing happens with R version 2.5.0 devel (2006-09-07 r39185). Best, H. Peter Dalgaard wrote: > [EMAIL PROTECTED] writes: > > >> Hi, >> >> On Windows, 'install.packages(,type="source")' displays the same output >> than 'R CMD INSTALL --help' and doesn't install anything... >> > > Yes. The culprit is > > > r39127 | urbaneks | 2006-09-05 20:45:00 +0200 (Tue, 05 Sep 2006) | 1 line > > Bugfix: install.packages ignored unnamed configure.args > > > which forgets to check whether there are any args to name. (There is a > generic issue in that available.packages has a configure.args argument > which is passed on to --configure-args in the INSTALL script: The > Windows INSTALL doesn't understand the argument since configure > doesn't work on Windows. However, things should work when no such > arguments are passed.) > > -- Hervé Pagès E-mail: [EMAIL PROTECTED] Phone: (206) 667-5791 Fax: (206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
