Re: [Rd] filenames with special characters in the R/ directory of a package?
On Fri, Feb 12, 2010 at 5:35 AM, blue sky wrote:
> According to R-exts.pdf (page 3):
> For maximal portability filenames should only
> contain only ASCII characters not excluded already (that is
> A-Za-z0-9._!#$%&+,;=...@^(){}’[]
>
> I have some files with special characters like '[' and '%' e.g.
> '[.set.R'.
That character list in your extract from R-exts.pdf is a list of
non-special characters. And [ and % are in there.
It's clarification of three sentences previous, which says:
"the characters ‘"’, ‘*’, ‘:’, ‘/’, ‘<’, ‘>’, ‘?’, ‘\’, and ‘|’ are
not allowed in file names"
> I also have some functions that also have those special
> characters defined in those files exported in NAMESPACE.
>
> I use the following command to install. And I get no warning or errors.
>
> R CMD INSTALL -d -l my_custom_dir my.pkg
>
> I then load the package. I get the following errors and warnings. I
> changed a file to one without these special characters. Then the
> corresponding warning/error disappears. Is it the case that there
> should never be files with special characters as names?
>
>> library(my.pkg)
> Error in namespaceExport(ns, exports) :
> undefined exports: %is%
> In addition: Warning message:
> S3 methods ‘[.set’ were declared in NAMESPACE but not found
> Error: package/namespace load failed for 'my.pkg'
Have you done an R CMD check on your package? I suspect a problem in
your NAMESPACE file, but it's not related to "special characters".
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Startup configuration file
On Wed, Feb 10, 2010 at 3:06 PM, Barry Rowlingson wrote: > But I agree that writing a saveable options package is the first step > - then making that a default in R is the second so people don't have > to edit profiles and R packages and applications can expect an API for > savable state. More thinking about this has turned it into a problem of being able to serialize R objects to XML. The most reliable way I can find of doing that is to use serialize, then rawToChar, and put a big old hex string in the XML. Hardly the most user-friendly format, but then users aren't supposed to edit XML anyway. I have also considered having encoding types for objects, something like: 66f6e.a7726 3.141 3.146.28 at which point I remembered that R objects can also have attributes which can be any other R objects too. At which point I realized life's too short for this... ..and had a rethink. Lots of software these days has a configuration directory, and runs all the scripts or configs within - think /etc/cron.daily/ or /etc/init.d on a unix system. This has the advantage that components of the system can manage their own startup files there, and not worry about stomping on others. So you'd have a .Rprofile.d/ folder with, say, a cran.R file that could be sourced by anything that used CRAN, for example to set the default mirror. I'd insist that each file in .Rprofile.d/ started with a "# do not edit this file" warning... I'll think some more over coffee until I realise why this is another of my dumb ideas... Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] filenames with special characters in the R/ directory of a package?
'Writing R Extensions' does say what names are allowed in the R
directory (at the start of section 1.1.3 in section-numbered formats).
To wit
The R subdirectory contains R code files, only. The code files to be
installed must start with an ASCII (lower or upper case) letter or
digit and have one of the extensions .R, .S, .q, .r, or .s.
'[.set.R' does not meet that rule, and so is skipped. This is not
something R CMD check reports, since the wording implies that other
names can be used for files to be not installed.
On Fri, 12 Feb 2010, Barry Rowlingson wrote:
On Fri, Feb 12, 2010 at 5:35 AM, blue sky wrote:
According to R-exts.pdf (page 3):
For maximal portability filenames should only
contain only ASCII characters not excluded already (that is
A-Za-z0-9._!#$%&+,;=...@^(){}’[]
I have some files with special characters like '[' and '%' e.g.
'[.set.R'.
That character list in your extract from R-exts.pdf is a list of
non-special characters. And [ and % are in there.
It's clarification of three sentences previous, which says:
"the characters ‘"’, ‘*’, ‘:’, ‘/’, ‘<’, ‘>’, ‘?’, ‘\’, and ‘|’ are
not allowed in file names"
I also have some functions that also have those special
characters defined in those files exported in NAMESPACE.
I use the following command to install. And I get no warning or errors.
R CMD INSTALL -d -l my_custom_dir my.pkg
I then load the package. I get the following errors and warnings. I
changed a file to one without these special characters. Then the
corresponding warning/error disappears. Is it the case that there
should never be files with special characters as names?
library(my.pkg)
Error in namespaceExport(ns, exports) :
undefined exports: %is%
In addition: Warning message:
S3 methods ‘[.set’ were declared in NAMESPACE but not found
Error: package/namespace load failed for 'my.pkg'
Have you done an R CMD check on your package? I suspect a problem in
your NAMESPACE file, but it's not related to "special characters".
Barry
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Startup configuration file
On 12/02/2010 3:50 AM, Barry Rowlingson wrote: On Wed, Feb 10, 2010 at 3:06 PM, Barry Rowlingson wrote: But I agree that writing a saveable options package is the first step - then making that a default in R is the second so people don't have to edit profiles and R packages and applications can expect an API for savable state. More thinking about this has turned it into a problem of being able to serialize R objects to XML. The most reliable way I can find of doing that is to use serialize, then rawToChar, and put a big old hex string in the XML. Hardly the most user-friendly format, but then users aren't supposed to edit XML anyway. I have also considered having encoding types for objects, something like: 66f6e.a7726 3.141 3.146.28 If you're storing hex, why not just use the binary save() format? (Or the save(ascii=TRUE) format.) What is the advantage of XML? at which point I remembered that R objects can also have attributes which can be any other R objects too. At which point I realized life's too short for this... ..and had a rethink. Lots of software these days has a configuration directory, and runs all the scripts or configs within - think /etc/cron.daily/ or /etc/init.d on a unix system. This has the advantage that components of the system can manage their own startup files there, and not worry about stomping on others. So you'd have a .Rprofile.d/ folder with, say, a cran.R file that could be sourced by anything that used CRAN, for example to set the default mirror. I'd insist that each file in .Rprofile.d/ started with a "# do not edit this file" warning... I'll think some more over coffee until I realise why this is another of my dumb ideas... I see two ways such a thing might be used: everything run at startup, or just running things as needed. Running everything at startup has the disadvantage that it requires all sorts of diverse packages to be loaded, so running things as needed makes more sense. But do you really want to make it so granular that it depends on the kind of task (accessing CRAN, ...)? Wouldn't it be good enough to have one user init file per package, and have it executed when the package is loaded? Duncan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Startup configuration file
On Feb 12, 2010, at 3:50 , Barry Rowlingson wrote: On Wed, Feb 10, 2010 at 3:06 PM, Barry Rowlingson wrote: But I agree that writing a saveable options package is the first step - then making that a default in R is the second so people don't have to edit profiles and R packages and applications can expect an API for savable state. More thinking about this has turned it into a problem of being able to serialize R objects to XML. This is getting OT, but, please, no XML. It's entirely useless in this context IMHO (as it is in others, but that's another story) and we already have reliable support for storing R objects (more than one in fact). Despite the fact that some used to claim human readability of XML in practice it turns out to be false, so I don't see any real benefits of XML in this context. Cheers, Simon The most reliable way I can find of doing that is to use serialize, then rawToChar, and put a big old hex string in the XML. Hardly the most user-friendly format, but then users aren't supposed to edit XML anyway. I have also considered having encoding types for objects, something like: 66f6e.a7726 3.141 3.146.28 at which point I remembered that R objects can also have attributes which can be any other R objects too. At which point I realized life's too short for this... ..and had a rethink. Lots of software these days has a configuration directory, and runs all the scripts or configs within - think /etc/cron.daily/ or /etc/init.d on a unix system. This has the advantage that components of the system can manage their own startup files there, and not worry about stomping on others. So you'd have a .Rprofile.d/ folder with, say, a cran.R file that could be sourced by anything that used CRAN, for example to set the default mirror. I'd insist that each file in .Rprofile.d/ started with a "# do not edit this file" warning... I'll think some more over coffee until I realise why this is another of my dumb ideas... Barry __ 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] R Startup configuration file
FYI, a while ago I was looking into the "problem" with generic settings files. I didn't find an omnibus/perfect solution, but have a look at the Settings class in the R.utils package (R/Settings.R in the source code). It tries to deal with automatic loading and saving of settings (robust detection of the quiting of an R session etc), finding the settings file and so. You can use this to load package specific settings as well. (We make use of this in the aroma.* framework (aroma.core, aroma.affymetrix etc), but I'll leave there for now). My $.02 /Henrik On Fri, Feb 12, 2010 at 3:22 PM, Simon Urbanek wrote: > > On Feb 12, 2010, at 3:50 , Barry Rowlingson wrote: > >> On Wed, Feb 10, 2010 at 3:06 PM, Barry Rowlingson >> wrote: >> >>> But I agree that writing a saveable options package is the first step >>> - then making that a default in R is the second so people don't have >>> to edit profiles and R packages and applications can expect an API for >>> savable state. >> >> More thinking about this has turned it into a problem of being able >> to serialize R objects to XML. > > > This is getting OT, but, please, no XML. It's entirely useless in this > context IMHO (as it is in others, but that's another story) and we already > have reliable support for storing R objects (more than one in fact). Despite > the fact that some used to claim human readability of XML in practice it > turns out to be false, so I don't see any real benefits of XML in this > context. > > Cheers, > Simon > > > >> The most reliable way I can find of >> doing that is to use serialize, then rawToChar, and put a big old hex >> string in the XML. Hardly the most user-friendly format, but then >> users aren't supposed to edit XML anyway. I have also considered >> having encoding types for objects, something like: >> >> 66f6e.a7726 >> 3.141 >> > name="baz">3.146.28 >> >> at which point I remembered that R objects can also have attributes >> which can be any other R objects too. At which point I realized life's >> too short for this... >> >> ..and had a rethink. Lots of software these days has a configuration >> directory, and runs all the scripts or configs within - think >> /etc/cron.daily/ or /etc/init.d on a unix system. This has the >> advantage that components of the system can manage their own startup >> files there, and not worry about stomping on others. So you'd have a >> .Rprofile.d/ folder with, say, a cran.R file that could be sourced by >> anything that used CRAN, for example to set the default mirror. I'd >> insist that each file in .Rprofile.d/ started with a "# do not edit >> this file" warning... >> >> I'll think some more over coffee until I realise why this is another >> of my dumb ideas... >> >> Barry >> >> __ >> 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] filenames with special characters in the R/ directory of a package?
It is strange to me why the filename must start with a letter or
digit, while the following characters can be something like '['. Is
there a reason why it is designed in this way? So that I can
understand the design principle rather than memorizing the facts
derived from the principle.
On Fri, Feb 12, 2010 at 5:10 AM, Prof Brian Ripley
wrote:
> 'Writing R Extensions' does say what names are allowed in the R directory
> (at the start of section 1.1.3 in section-numbered formats). To wit
>
> The R subdirectory contains R code files, only. The code files to be
> installed must start with an ASCII (lower or upper case) letter or
> digit and have one of the extensions .R, .S, .q, .r, or .s.
>
> '[.set.R' does not meet that rule, and so is skipped. This is not something
> R CMD check reports, since the wording implies that other names can be used
> for files to be not installed.
>
>
> On Fri, 12 Feb 2010, Barry Rowlingson wrote:
>
>> On Fri, Feb 12, 2010 at 5:35 AM, blue sky wrote:
>>>
>>> According to R-exts.pdf (page 3):
>>> For maximal portability filenames should only
>>> contain only ASCII characters not excluded already (that is
>>> A-Za-z0-9._!#$%&+,;=...@^(){}’[]
>>>
>>> I have some files with special characters like '[' and '%' e.g.
>>> '[.set.R'.
>>
>> That character list in your extract from R-exts.pdf is a list of
>> non-special characters. And [ and % are in there.
>>
>> It's clarification of three sentences previous, which says:
>>
>> "the characters ‘"’, ‘*’, ‘:’, ‘/’, ‘<’, ‘>’, ‘?’, ‘\’, and ‘|’ are
>> not allowed in file names"
>>
>>> I also have some functions that also have those special
>>> characters defined in those files exported in NAMESPACE.
>>>
>>> I use the following command to install. And I get no warning or errors.
>>>
>>> R CMD INSTALL -d -l my_custom_dir my.pkg
>>>
>>> I then load the package. I get the following errors and warnings. I
>>> changed a file to one without these special characters. Then the
>>> corresponding warning/error disappears. Is it the case that there
>>> should never be files with special characters as names?
>>>
library(my.pkg)
>>>
>>> Error in namespaceExport(ns, exports) :
>>> undefined exports: %is%
>>> In addition: Warning message:
>>> S3 methods ‘[.set’ were declared in NAMESPACE but not found
>>> Error: package/namespace load failed for 'my.pkg'
>>
>> Have you done an R CMD check on your package? I suspect a problem in
>> your NAMESPACE file, but it's not related to "special characters".
>>
>> Barry
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley, rip...@stats.ox.ac.uk
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UK Fax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Startup configuration file
On 12 February 2010 at 09:22, Simon Urbanek wrote: | On Feb 12, 2010, at 3:50 , Barry Rowlingson wrote: | | > On Wed, Feb 10, 2010 at 3:06 PM, Barry Rowlingson | > wrote: | > | >> But I agree that writing a saveable options package is the first | >> step | >> - then making that a default in R is the second so people don't have | >> to edit profiles and R packages and applications can expect an API | >> for | >> savable state. | > | > More thinking about this has turned it into a problem of being able | > to serialize R objects to XML. | | | This is getting OT, but, please, no XML. It's entirely useless in this | context IMHO (as it is in others, but that's another story) and we | already have reliable support for storing R objects (more than one in | fact). Despite the fact that some used to claim human readability of | XML in practice it turns out to be false, so I don't see any real | benefits of XML in this context. Fully agreed. OTOH I had the same idea as Barry the other day about maybe making files like $R_HOME/profile.site 'walk' over a directory, say, $R_HOME/profile.site.d/ so that users could drop files there and upon installation and re-installation those user-contributed snippets would just survive. This foo.d/ directory scheme is getting more and more common in Unix/Linux land as Barry noted. Dirk -- Registration is open for the 2nd International conference R / Finance 2010 See http://www.RinFinance.com for details, and see you in Chicago in April! __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Startup configuration file
On Fri, Feb 12, 2010 at 2:22 PM, Simon Urbanek
wrote:
> This is getting OT, but, please, no XML. It's entirely useless in this
> context IMHO (as it is in others, but that's another story) and we already
> have reliable support for storing R objects (more than one in fact). Despite
> the fact that some used to claim human readability of XML in practice it
> turns out to be false, so I don't see any real benefits of XML in this
> context.
Yes, I agree. Originally I was hoping to have a nice
human-and-computer readable config.ini file:
[options]
contrasts = structure(list(contrasts = structure(c("contr.treatment",
"contr.poly"
), .Names = c("unordered", "ordered"))), .Names = "contrasts")
but the lack of an ini parser in R made me think "heck, let's do it in
something we do have a parser for...".
maybe I should use JSON? Yeah, we have a parser and that's what all
the hipster web 3.0 kids are using these days
Barry
--
blog: http://geospaced.blogspot.com/
web: http://www.maths.lancs.ac.uk/~rowlings
web: http://www.rowlingson.com/
twitter: http://twitter.com/geospacedman
pics: http://www.flickr.com/photos/spacedman
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Darwinian software development and the library function
Hi, Charlotte: I'm not sure what you mean. If you mean writing something like "print.foo (myfoo, ...)", this is relatively benign I suppose, but I avoid it where feasible. On multiple occasions, I've pushed collaborators and even maintainers of other packages to change this or allow me to change it to conform to the standard; if my memory is correct, there have been several violations of this standard in the "fda" package, which are no longer there because I changed them. If a user with an object "x" of class "foo" writes print(x=x) or print(foo=x), I'm not sure what it would do, but it might not be what you want. My "sos" package masks "?". However, I don't like it. I generally consider such to be potentially user hostile, and whenever feasible, I prefer to avoid such code. I did it in this case for a couple of reasons. First, using "?" (actually "???") seems so much easier to remember than "findFn" that it justifies this transgression of standard protocol. Second, one of the leading figures in the R community (Duncan Murdoch) contributed suggested we do this and contributed the code. If you change the definition of "print" itself, that seems to me to be a much bigger issue, with consequences much more difficult to predict. If someone else also overwrites "print" making it different and incompatible with yours, then your code may not work or theirs may not, depending on which gets loaded first in the search path. Worse, your code cannot possibly have been tested as thoroughly as the standard code. If your code includes a subtle bug that only occurs under special circumstances, it may be hard for the person experiencing the problem to find, because they don't expect it. Hope this helps. Spencer Charlotte Maia wrote: Hi all, Legend has it, that polite R programmers don't overwrite, say, the print function. However, this seems quite un-Darwinian to me (especially given that I don't want to call all my arguments x and y). I might want a function print.foo (myfoo, ...). So I decided to be very impolite (in one of my packages) and overwrite a few standard generics. Plus, to the best of my knowledge it doesn't interfere with normal use (yay...). This brings us to the library function. Which by default gives a whole lot of warnings loading my package (and any other package that does something similar), scaring off polite R programmers and perhaps some mainstream R users. I'm starting to think that the default for library, should be warn.conflicts=FALSE. However, just reading the documentation, I noticed a reference to something called .conflicts.OK. Not sure what that does, however if it does what it sounds like, then it largely fixes the problem. The biggest issue though, is whether or not one should be impolite (i.e. Darwinian) and overwrite print etc in the first place...? I'm inclined to go in favour of overwriting the functions. However, it has the potential to introduce some technical problems. Other's opinions appreciated. kind regards -- Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R Startup configuration file
On 12/02/2010 10:33 AM, Barry Rowlingson wrote:
On Fri, Feb 12, 2010 at 2:22 PM, Simon Urbanek
wrote:
> This is getting OT, but, please, no XML. It's entirely useless in this
> context IMHO (as it is in others, but that's another story) and we already
> have reliable support for storing R objects (more than one in fact). Despite
> the fact that some used to claim human readability of XML in practice it
> turns out to be false, so I don't see any real benefits of XML in this
> context.
Yes, I agree. Originally I was hoping to have a nice
human-and-computer readable config.ini file:
[options]
contrasts = structure(list(contrasts = structure(c("contr.treatment",
"contr.poly"
), .Names = c("unordered", "ordered"))), .Names = "contrasts")
but the lack of an ini parser in R made me think "heck, let's do it in
something we do have a parser for...".
maybe I should use JSON? Yeah, we have a parser and that's what all
the hipster web 3.0 kids are using these days
We have read.dcf() if you want human and machine readable.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] aggregate: with 2 by variables in the result the 2nd by-variable is wrong (PR#14213)
Full_Name: Franz Quehenberger Version: 2.10.1 OS: Windows XP Submission from: (NULL) (145.244.10.3) aggregate is supposed to produce a data.frame that contains a line for each combination of levels of the variables in the by list. The first columns of the result contain these combinations of levels. With two by variables the second by-variable takes always only one value. However, it works fine with one or three by-variables. The problems seems to be caused by this line of code in aggregate(): w <- as.data.frame(w, stringsAsFactors = FALSE)[which(!unlist(lapply(z, is.null))), , drop = FALSE] or more specifically by: [which(!unlist(lapply(z, is.null))), , drop = FALSE] Kind regards FQ # demonstration of the aggregate bug ind R 2.10.1 factor.a=rep(letters[1:3],4) factor.b=rep(letters[4:5],each=3,times=2) factor.c=rep(letters[4:5+2],each=6) data=data.frame(factor.a,factor.b,factor.c,x) x=1:12 #one by-variable works: aggregate(x,list(a=factor.a),FUN=mean) #thre by-variable work fine: aggregate(x,list(a=factor.a,b=factor.b,c=factor.b),FUN=mean) #two by-variables do not produce the levels of the second by-variable correctly: aggregate(x,list(a=factor.a,b=factor.b),FUN=mean) # data print(data) Result of the R code: > # demonstration of the aggregate bug ind R 2.10.1 > factor.a=rep(letters[1:3],4) > factor.b=rep(letters[4:5],each=3,times=2) > factor.c=rep(letters[4:5+2],each=6) > data=data.frame(factor.a,factor.b,factor.c,x) > x=1:12 > #one by-variable works: > aggregate(x,list(a=factor.a),FUN=mean) a x 1 a 5.5 2 b 6.5 3 c 7.5 > #thre by-variable work fine: > aggregate(x,list(a=factor.a,b=factor.b,c=factor.b),FUN=mean) a b c x 1 a d d 4 2 b d d 5 3 c d d 6 4 a e e 7 5 b e e 8 6 c e e 9 > #two by-variables do not produce the levels of the second by-variable correctly: > aggregate(x,list(a=factor.a,b=factor.b),FUN=mean) a b x 1 a d 4 2 b d 5 3 c d 6 4 a d 7 5 b d 8 6 c d 9 Warnmeldung: In data.frame(w, lapply(y, unlist, use.names = FALSE), stringsAsFactors = FALSE) : row names were found from a short variable and have been discarded > # data > print(data) factor.a factor.b factor.c x 1 adf 1 2 bdf 2 3 cdf 3 4 aef 4 5 bef 5 6 cef 6 7 adg 7 8 bdg 8 9 cdg 9 10aeg 10 11beg 11 12ceg 12 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] long integer in R?
R-exts.pdf dosen't list many types that are supported in C++, for example, long. Are there storage.mode corresponds to those extra types? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Unexpected behaviour of x[i] when i is a matrix, on Windows
Hi,
when running the following on different instances of R (Linux and
Windows), I get different results. The one for Linux seems to be the
intended / documented one. When using numeric indices rather than
characters, Windows seemed to behave as expected.
---On Windows--
x = matrix(FALSE, nrow=3, ncol=3)
colnames(x) = LETTERS[1:3]
rownames(x) = letters[1:3]
x
# A B C
# a FALSE FALSE FALSE
# b FALSE FALSE FALSE
# c FALSE FALSE FALSE
x [ cbind("b", "B") ] = TRUE
x
b B
# FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE TRUE TRUE
sessionInfo()
R version 2.10.0 (2009-10-26)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
---On Linux--
x = matrix(FALSE, nrow=3, ncol=3)
colnames(x) = LETTERS[1:3]
rownames(x) = letters[1:3]
x
# A B C
# a FALSE FALSE FALSE
# b FALSE FALSE FALSE
# c FALSE FALSE FALSE
x [ cbind("b", "B") ] = TRUE
x
# A B C
# a FALSE FALSE FALSE
# b FALSE TRUE FALSE
# c FALSE FALSE FALSE
> sessionInfo()
R version 2.11.0 Under development (unstable) (2010-02-12 r51125)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices datasets utils methods base
other attached packages:
[1] fortunes_1.3-7
--
Best wishes
Wolfgang
--
Wolfgang Huber
EMBL
http://www.embl.de/research/units/genome_biology/huber/contact
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] long integer in R?
On Feb 12, 2010, at 12:33 , blue sky wrote: R-exts.pdf dosen't list many types that are supported in C++, for example, long. Are there storage.mode corresponds to those extra types? There are none - that's why they are not listed. As for long: on 32- bit platforms (and Win64) int and long are equivalent so you can simply use INTSXP. On 64-bit unix platforms (LP64) there is no way to losslessly use it (other than raw) but in most applications you can simply use REALSXP as it gives you at least 52-bits of precision which its sufficient for most applications. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected behaviour of x[i] when i is a matrix, on Windows
You're comparing 2.10.0 on Windows with 2.11.0 on Linux.
Have you tried 2.11.0 on Windows? => same result as on Linux.
-Peter Ehlers
Wolfgang Huber wrote:
Hi,
when running the following on different instances of R (Linux and
Windows), I get different results. The one for Linux seems to be the
intended / documented one. When using numeric indices rather than
characters, Windows seemed to behave as expected.
---On Windows--
x = matrix(FALSE, nrow=3, ncol=3)
colnames(x) = LETTERS[1:3]
rownames(x) = letters[1:3]
x
# A B C
# a FALSE FALSE FALSE
# b FALSE FALSE FALSE
# c FALSE FALSE FALSE
x [ cbind("b", "B") ] = TRUE
x
b B
# FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE TRUE TRUE
sessionInfo()
R version 2.10.0 (2009-10-26)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
---On Linux--
x = matrix(FALSE, nrow=3, ncol=3)
colnames(x) = LETTERS[1:3]
rownames(x) = letters[1:3]
x
# A B C
# a FALSE FALSE FALSE
# b FALSE FALSE FALSE
# c FALSE FALSE FALSE
x [ cbind("b", "B") ] = TRUE
x
# A B C
# a FALSE FALSE FALSE
# b FALSE TRUE FALSE
# c FALSE FALSE FALSE
> sessionInfo()
R version 2.11.0 Under development (unstable) (2010-02-12 r51125)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices datasets utils methods base
other attached packages:
[1] fortunes_1.3-7
--
Peter Ehlers
University of Calgary
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected behaviour of x[i] when i is a matrix, on Windows
On Feb 12, 2010, at 12:50 , Wolfgang Huber wrote:
Hi,
when running the following on different instances of R (Linux and
Windows), I get different results. The one for Linux seems to be the
intended / documented one. When using numeric indices rather than
characters, Windows seemed to behave as expected.
AFAICT this has nothing to do with the platform but with using an
older R version in Windows that doesn't support it ...
From NEWS:
CHANGES IN R VERSION 2.11.0
[...]
NEW FEATURES
[...]
o n-dimensional arrays with dimension names can now be indexed
by an n-column character matrix. The indices are matched
against the dimension names. NA indices are propagated to the
result. Unmatched values and "" are not allowed and result in
an error.
Cheers,
Simon
---On Windows--
x = matrix(FALSE, nrow=3, ncol=3)
colnames(x) = LETTERS[1:3]
rownames(x) = letters[1:3]
x
# A B C
# a FALSE FALSE FALSE
# b FALSE FALSE FALSE
# c FALSE FALSE FALSE
x [ cbind("b", "B") ] = TRUE
x
b B
# FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE TRUE TRUE
sessionInfo()
R version 2.10.0 (2009-10-26)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
---On Linux--
x = matrix(FALSE, nrow=3, ncol=3)
colnames(x) = LETTERS[1:3]
rownames(x) = letters[1:3]
x
# A B C
# a FALSE FALSE FALSE
# b FALSE FALSE FALSE
# c FALSE FALSE FALSE
x [ cbind("b", "B") ] = TRUE
x
# A B C
# a FALSE FALSE FALSE
# b FALSE TRUE FALSE
# c FALSE FALSE FALSE
> sessionInfo()
R version 2.11.0 Under development (unstable) (2010-02-12 r51125)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices datasets utils methods base
other attached packages:
[1] fortunes_1.3-7
--
Best wishes
Wolfgang
--
Wolfgang Huber
EMBL
http://www.embl.de/research/units/genome_biology/huber/contact
__
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] Unexpected behaviour of x[i] when i is a matrix, on Windows
On 2/12/10 10:12 AM, Peter Ehlers wrote: You're comparing 2.10.0 on Windows with 2.11.0 on Linux. Have you tried 2.11.0 on Windows? => same result as on Linux. Indeed, this is new functionality added to R-devel (5 Jan). Indexing an n-dim array with an n-column matrix used to only be supported when the matrix contained integers. Character matrices are now supported to map to dimnames of the array. Here's the NEWS entry: o n-dimensional arrays with dimension names can now be indexed by an n-column character matrix. The indices are matched against the dimension names. NA indices are propagated to the result. Unmatched values and "" are not allowed and result in an error. Cheers, + seth -- Seth Falcon | @sfalcon | http://userprimary.net/user __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Unexpected behaviour of x[i] when i is a matrix, on Windows
Hi Simon and Peter
Ouch, I am sorry for raising this.
I hadn't even considered that this basic functionality might only have
entered R between 2.10 and 2.11 - and that trying to use it would not
raise an error pre-2.11.
The Windows PC was that of a student, which is a lame non-excuse for not
trying with 2.11 there.
Sorry again for wasting your time, and best wishes
Wolfgang
Simon Urbanek scripsit 02/12/2010 07:15 PM:
On Feb 12, 2010, at 12:50 , Wolfgang Huber wrote:
Hi,
when running the following on different instances of R (Linux and
Windows), I get different results. The one for Linux seems to be the
intended / documented one. When using numeric indices rather than
characters, Windows seemed to behave as expected.
AFAICT this has nothing to do with the platform but with using an older
R version in Windows that doesn't support it ...
From NEWS:
CHANGES IN R VERSION 2.11.0
[...]
NEW FEATURES
[...]
o n-dimensional arrays with dimension names can now be indexed
by an n-column character matrix. The indices are matched
against the dimension names. NA indices are propagated to the
result. Unmatched values and "" are not allowed and result in
an error.
Cheers,
Simon
---On Windows--
x = matrix(FALSE, nrow=3, ncol=3)
colnames(x) = LETTERS[1:3]
rownames(x) = letters[1:3]
x
# A B C
# a FALSE FALSE FALSE
# b FALSE FALSE FALSE
# c FALSE FALSE FALSE
x [ cbind("b", "B") ] = TRUE
x
b B
# FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE FALSE TRUE TRUE
sessionInfo()
R version 2.10.0 (2009-10-26)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
---On Linux--
x = matrix(FALSE, nrow=3, ncol=3)
colnames(x) = LETTERS[1:3]
rownames(x) = letters[1:3]
x
# A B C
# a FALSE FALSE FALSE
# b FALSE FALSE FALSE
# c FALSE FALSE FALSE
x [ cbind("b", "B") ] = TRUE
x
# A B C
# a FALSE FALSE FALSE
# b FALSE TRUE FALSE
# c FALSE FALSE FALSE
> sessionInfo()
R version 2.11.0 Under development (unstable) (2010-02-12 r51125)
x86_64-unknown-linux-gnu
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices datasets utils methods base
other attached packages:
[1] fortunes_1.3-7
--
Best wishes
Wolfgang
--
Wolfgang Huber
EMBL
http://www.embl.de/research/units/genome_biology/huber/contact
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Best wishes
Wolfgang
--
Wolfgang Huber
EMBL
http://www.embl.de/research/units/genome_biology/huber/contact
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] aggregate: with 2 by variables in the result the 2nd by-variable is wrong (PR#14213)
franz.quehenber...@medunigraz.at wrote: Full_Name: Franz Quehenberger Version: 2.10.1 OS: Windows XP Submission from: (NULL) (145.244.10.3) aggregate is supposed to produce a data.frame that contains a line for each combination of levels of the variables in the by list. The first columns of the result contain these combinations of levels. With two by variables the second by-variable takes always only one value. However, it works fine with one or three by-variables. The problems seems to be caused by this line of code in aggregate(): w <- as.data.frame(w, stringsAsFactors = FALSE)[which(!unlist(lapply(z, is.null))), , drop = FALSE] or more specifically by: [which(!unlist(lapply(z, is.null))), , drop = FALSE] Kind regards FQ # demonstration of the aggregate bug ind R 2.10.1 factor.a=rep(letters[1:3],4) factor.b=rep(letters[4:5],each=3,times=2) factor.c=rep(letters[4:5+2],each=6) data=data.frame(factor.a,factor.b,factor.c,x) x=1:12 #one by-variable works: aggregate(x,list(a=factor.a),FUN=mean) #thre by-variable work fine: aggregate(x,list(a=factor.a,b=factor.b,c=factor.b),FUN=mean) #two by-variables do not produce the levels of the second by-variable correctly: aggregate(x,list(a=factor.a,b=factor.b),FUN=mean) # data print(data) Result of the R code: # demonstration of the aggregate bug ind R 2.10.1 factor.a=rep(letters[1:3],4) factor.b=rep(letters[4:5],each=3,times=2) factor.c=rep(letters[4:5+2],each=6) data=data.frame(factor.a,factor.b,factor.c,x) x=1:12 #one by-variable works: aggregate(x,list(a=factor.a),FUN=mean) a x 1 a 5.5 2 b 6.5 3 c 7.5 #thre by-variable work fine: aggregate(x,list(a=factor.a,b=factor.b,c=factor.b),FUN=mean) a b c x 1 a d d 4 2 b d d 5 3 c d d 6 4 a e e 7 5 b e e 8 6 c e e 9 #two by-variables do not produce the levels of the second by-variable correctly: aggregate(x,list(a=factor.a,b=factor.b),FUN=mean) a b x 1 a d 4 2 b d 5 3 c d 6 4 a d 7 5 b d 8 6 c d 9 Warnmeldung: In data.frame(w, lapply(y, unlist, use.names = FALSE), stringsAsFactors = FALSE) : row names were found from a short variable and have been discarded # data print(data) factor.a factor.b factor.c x 1 adf 1 2 bdf 2 3 cdf 3 4 aef 4 5 bef 5 6 cef 6 7 adg 7 8 bdg 8 9 cdg 9 10aeg 10 11beg 11 12ceg 12 I don't see this is 2.10.1 nor in 2.11.0 (Windows Vista). I can't think of how you might have got your result. Is there something you haven't mentioned? What's your sessionInfo()? -- Peter Ehlers University of Calgary __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [ANN] OCaml-R binding for the R language.
This post is to announce the 0.2 release of OCaml-R. OCaml-R is a binding embedding the R interpreter into Objective Caml code. Home page: http://home.gna.org/ocaml-r/ Download page: http://download.gna.org/ocaml-r/ Deb packages: http://yziquel.homelinux.org/debian/pool/main/o/ocaml-r/ Tutorial: http://home.gna.org/ocaml-r/gettingstarted.en.html OCamlDoc API: http://yziquel.homelinux.org/topos/api/ocaml-r/index.html http://home.gna.org/ocaml-r/refdoc/index.html The goal of OCaml-R is to provide adequate integration of the R interpreter into Objective Caml, and a framework suitable to bind R library into OCaml code. Version 0.2 is a near-complete rewrite of the 0.1 version by Maxence Guesdon, with an incompatible API. Main features are: - Safe handling of R default environment variables at compile time, following what is done in littler. - R Signal handlers do not conflict with OCaml code. - Integration with findlib, enabling the #require "R.interpreter" to initialise statically the R interpreter. Compiling with 'ocamlfind ocamlopt -package R.interpreter' also initialises the R interpreter at compile-time, so to speak. - Some (most?) functionalities of the R standalone library are wrapped. - Low-level binding, in the sense that you construct low-level R calls to execute them. You can also parse R code to execute it, if you wish. - R exceptions are chained back to Objective Caml. - R's garbage collector is chained with OCaml's garbage collector. This is done rather inefficiently for the moment (freeing n R values in O(n^2) time complexity), and we expect to bring this down to O(n) with a thin garbage collecting layer in the future. - We provide a double typing scheme, with some subtyping features. A first typing mimics the dynamic typing of the R language, while a second typing, for the end-user, aims at providing a static typing of R values and functions. (This can be bettered). - S3 classes are supported (static typing is however still unsatisfying). S4 classes are not yet supported. Help welcome. - Some basic R datatypes, such as dataframes, are wrapped, and a framework to wrap the standard library has been put in place. - Basic data structures can be converted back and forth between OCaml and the R interpreter. - Ability to inspect (read-only) the inner structure of R values, which is quite convenient: you get to know rather quickly what a given piece of R code returns, which you need to know to type R code statically in order to bind it to OCaml. - Not thread-safe at all. At least, not more than R is... Lwt-style multithreading of R code could be possible, modulo some simple and deep (i.e. below R API) changes in the R evaluation functions. POSIX threading a single R thread with multiple OCaml threads is not yet possible, but is within reach. - Doesn't interact well the R "Defaults" package. While most of the code sticks or could stick to the R API, or at least to the public part of the R headers, there are some functionalities which are outright out of the scope of the R API. Some of these functionalities are for convenience only (i.e. inspecting internals of R values), while others are crucial to the binding (chaining R exceptions to OCaml). Hopefully, this lays down a foundation on which one could import R functionalities, libraries and packages to OCaml. -- Guillaume Yziquel http://yziquel.homelinux.org/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Copyright versus Licenses
On Tue, Jan 19, 2010 at 11:54 AM, Simon Urbanek wrote: > Copyright is the right that the author of an original work holds > automatically (unless someone else can claim to own his work - e.g. his > employer etc.) under the Berne Convention. The copyright gives only the > author all rights - including but not limited to the right to copy, modify, > distribute the work etc. Licenses are used to give some of those rights to > other people under certain conditions. Hence you cannot "assign yourself > copyright" because you already have it (and if you don't then your cannot > assign it). Also you don't need to give the "copyright" to anyone else - you > can give certain rights to others using licenses -- such as GPL, LGPL, EUPL > etc. -- but you don't give copyright by those since you have far more rights > as the author (e.g., you can do whatever your want with the original work > beyond the restrictions of the license). There are cases where you may want > to give your copyright to someone, e.g., an organization that represents all > authors of a project which makes it easier to change licenses etc., but that > is a different story. Interesting, but what about the situation where a new author adds his name as copyright holder without the consent of the original copyright holder, and with only one person making the decision whether or not this change is warranted: the new copyright holder? Doesn't this amount to giving the copyright away, or giving it away to everybody? GPL is often called copyleft for a reason: it basically cancels most of the rights that you would have with an ordinary copyright so that others can freely copy your work with no requirements other than that your copyright notice be retained, along with a potentially unlimited number of other "copyright" notices attached to the same work. (For completeness, there is a clause about not leaving misleading impressions about previous authors, but in my opinion the only way this could be enforced is if the contributions of the previous author are not altered. But this is inconsistent with the broad freedoms granted by the main text of the license.) The only "infringement" cases that I am aware of is where a company is sued because it tried to turn GPL software into a commercial product. This is what GPL was designed to do. It is not designed to protect authors (because that would be an attack on software freedom and apple pie, according to true believers). Dominick [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Copyright versus Licenses
Dominick Samperi a écrit : Interesting, but what about the situation where a new author adds his name as copyright holder without the consent of the original copyright holder, and with only one person making the decision whether or not this change is warranted: the new copyright holder? Doesn't this amount to giving the copyright away, or giving it away to everybody? If someone writes some code in a file, he is entitled to be the copyright owner of what he wrote. Kicking him away means not using his changes. GPL is often called copyleft for a reason: it basically cancels most of the rights that you would have with an ordinary copyright so that others can freely copy your work with no requirements other than that your Nope. You cannot "cancel" your rights. You have them. Full stop. You just give enough rights to other fellows. And restrictions when it comes to distributing GPL stuff. Essentially. You are not taking your rights away from and giving them to others. That doesn't make sense. The only "infringement" cases that I am aware of is where a company is sued because it tried to turn GPL software into a commercial product. This is what GPL was designed to do. Nope. GPL allows you to make commercial GPL products. So you cannot say that it forbids turning GPL work into a commercial product. And there are cases where ISP have been 'distributing' GPL code in the routers, ADSL boxes. They've been sued for not disclosing the source code. They haven't been sued for shipping GPL code in these ADSL boxes in the scope of a commercial contract. Quite the opposite. It is not designed to protect authors (because that would be an attack on software freedom and apple pie, according to true believers). It is designed to protect people receiving software from vendors who may want to conceal the source code of what they're distributing. Among other things. But, for instance, if your code may be hijacked by a big corporation, putting it under the GPL is a guarantee that it doesn't make huge sense to hijack it. So here you protect the author. But how is this R related? All the best, -- Guillaume Yziquel http://yziquel.homelinux.org/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Copyright versus Licenses
On Fri, Feb 12, 2010 at 8:01 PM, Guillaume Yziquel < guillaume.yziq...@citycable.ch> wrote: > Dominick Samperi a écrit : > > >> Interesting, but what about the situation where a new author adds his name >> as copyright holder without the >> consent of the original copyright holder, and with only one person making >> the decision whether or not this >> change is warranted: the new copyright holder? Doesn't this amount to >> giving >> the copyright away, or >> giving it away to everybody? >> > > If someone writes some code in a file, he is entitled to be the copyright > owner of what he wrote. Kicking him away means not using his changes. Sounds like a YES > GPL is often called copyleft for a reason: it basically cancels most of >> the >> rights that you would have with >> an ordinary copyright so that others can freely copy your work with no >> requirements other than that your >> > > Nope. You cannot "cancel" your rights. You have them. Full stop. > You just give enough rights to other fellows. And restrictions when it comes > to distributing GPL stuff. Essentially. > You are not taking your rights away from and giving them to others. That > doesn't make sense. I know of no version of GPL that is consistent with these comments, especially the last line. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Darwinian software development and the library function
Hi Spencer, Sorry, I wasn't very clear in my initial post. The function print.foo (myfoo, ...) won't pass R check (unless one overwrites print first). One has to write print.foo (x, ...), which in my personal opinion, can be problematic. In my oosp package, I have overwritten print (along with a few others). Initially, I overwrote both print and print.default. However now, I merely use print = function (...) base::print (...). Not really a generic, however it acts exactly the same (I think...). Plus Rd documentation still documents print.mymethod in the usual way. kind regards Charlotte On Sat, Feb 13, 2010 at 4:41 AM, spencerg wrote: > Hi, Charlotte: > > I'm not sure what you mean. If you mean writing something like > "print.foo (myfoo, ...)", this is relatively benign I suppose, but I avoid > it where feasible. On multiple occasions, I've pushed collaborators and > even maintainers of other packages to change this or allow me to change it > to conform to the standard; if my memory is correct, there have been > several violations of this standard in the "fda" package, which are no > longer there because I changed them. If a user with an object "x" of class > "foo" writes print(x=x) or print(foo=x), I'm not sure what it would do, but > it might not be what you want. > > My "sos" package masks "?". However, I don't like it. I generally > consider such to be potentially user hostile, and whenever feasible, I > prefer to avoid such code. I did it in this case for a couple of reasons. > First, using "?" (actually "???") seems so much easier to remember than > "findFn" that it justifies this transgression of standard protocol. Second, > one of the leading figures in the R community (Duncan Murdoch) contributed > suggested we do this and contributed the code. > > If you change the definition of "print" itself, that seems to me to be a > much bigger issue, with consequences much more difficult to predict. If > someone else also overwrites "print" making it different and incompatible > with yours, then your code may not work or theirs may not, depending on > which gets loaded first in the search path. Worse, your code cannot > possibly have been tested as thoroughly as the standard code. If your code > includes a subtle bug that only occurs under special circumstances, it may > be hard for the person experiencing the problem to find, because they don't > expect it. > > Hope this helps. > Spencer > > > Charlotte Maia wrote: >> >> Hi all, >> >> Legend has it, that polite R programmers don't overwrite, say, the >> print function. >> However, this seems quite un-Darwinian to me (especially given that I >> don't want to call all my arguments x and y). >> I might want a function print.foo (myfoo, ...). >> >> So I decided to be very impolite (in one of my packages) and overwrite >> a few standard generics. >> Plus, to the best of my knowledge it doesn't interfere with normal use >> (yay...). >> >> This brings us to the library function. >> Which by default gives a whole lot of warnings loading my package (and >> any other package that does something similar), scaring off polite R >> programmers and perhaps some mainstream R users. >> >> I'm starting to think that the default for library, should be >> warn.conflicts=FALSE. >> However, just reading the documentation, I noticed a reference to >> something called .conflicts.OK. >> Not sure what that does, however if it does what it sounds like, then >> it largely fixes the problem. >> >> The biggest issue though, is whether or not one should be impolite >> (i.e. Darwinian) and overwrite print etc in the first place...? >> >> I'm inclined to go in favour of overwriting the functions. >> However, it has the potential to introduce some technical problems. >> >> Other's opinions appreciated. >> >> >> kind regards >> > > > -- > Spencer Graves, PE, PhD > President and Chief Operating Officer > Structure Inspection and Monitoring, Inc. > 751 Emerson Ct. > San José, CA 95126 > ph: 408-655-4567 > > -- Charlotte Maia http://sites.google.com/site/maiagx __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
