Re: [Rd] Wish list
On Jan 1, 2006, at 7:36 AM, Duncan Temple Lang wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> Gabor Grothendieck wrote:
>> This is my New Year wishlist for R features. One
>> common thread is that I find I sometimes use languages
>> other than R including javascript, Windows batch and
>> gawk. Others have mentioned other languages too. It
>> would be nice if, in those cases I could use R
>> simplifying development into a single environment
>> (viz. R).
>>
>> The following are not in any order.
>>
>> 1. Self Contained Executables
>>
>> Make it possible to create self contained R
>> executables. Something like tcl starkits
>>http://www.equi4.com/starkit.html
>> or Python py2exe
>>http://starship.python.net/crew/theller/py2exe
>> is what I am thinking of. Its ok if they
>> are interpreted as long as its all transparent.
>>
>
> We have been thinking of this, for me in the context
> of putting R on small sensor network nodes.
This was recently done with CLISP by, essentially cat'ing the image
onto the end of the CLISP executable. You could probably do the same
with an Rda and a startup script (since R isn't truly image based) on
a small custom front end that links the DLL. You'd need to patch save
and load, but you'd be able to deliver executable apps (assuming base
and everything is installed). For a completely self-contained
executable (i.e. not requiring an installer) you'd probably want to
build a "minimal" R that you can just source in or load as an image
(or we could just go to images in general R's been sort of
meandering in that direction for the last couple of years ;-) )
>
>> 2. R as a Filter
>>
>> Support using R as a filter analogously to
>> awk/gawk. e.g.
>>
>> echo a x 3 | R -f myprog.R | findstr /i answer
>> echo a x 3 | R -e "chartr('x', 'X', readLines(STDIN()))" |
>> findstr /i X
>>
>> This would allow replacement of certain awk/gawk
>> filters with R. In the above STDIN or some
>> would refer to the echo output, not to further
>> input from the script. I think /dev/stdin
>> can already be used in UNIX but not in Windows.
>>
>
> This has been in the works for a long time and I still dislike two
> small pieces of the solution that make it limited.
>
>
>> 3. Microsoft Active Scripting Language
>>
>> Make R into a Microsoft Active Scripting
>> language. Nearly every other major scripting
>> language including perl, python, ruby, tcl,
>> oorexx, vbscript, jscript and others have
>> Microsoft Active Scripting support. This would
>> allow R to be used like javascript in HTML files
>> in Microsoft environments and also in any other
>> software that supports Microsoft's active
>> scripting interface.
>
> Yes not that hard to do given the work in other interfaces,
> but I wish the Windows users would contribute it.
No, with the DCOM stuff it should be pretty straightforward these
days. We actually did a bit of this with I think it was R 1.1 or so
before the Bioconductor project got started. Security was an issue as
Duncan M. pointed out as I recall. You could basically remotely trash
someone's drive, no good. In the end, I think you can do what you
need to do with the DCOM interface and everything else you can do
with a front-end. Being able to hook into .Net/Mono would be useful I
think. On the Very Cool list would be a "managed" version of R, but
that falls into the Things That Don't Result In Degrees so its on
indefinite hold (it does give Naras and I something to talk about at
coffee though).
>
>>
>> 4. Extend Clipboard Support to Non-Text Objects on
>> Windows
>>
>> If one selects and copies a table in Internet
>> Explorer (IE) one can then paste it into Excel and
>> it comes out as expected with one Excel cell per
>> IE table cell. However, R does not currently
>> support this level of integration. (Current
>> workaround is to paste it into Excel and then copy
>> it back out of Excel. Excel will add tabs to the
>> text that is so copied.)
>>
>> I understand that this feature may be in R 2.3.0
>> but am mentioning it for completeness.
>>
>> 5. Handhelds
>>
>> Version(s) of R for handheld computers such as
>> Palm, Windows Mobile, Symbian, Blackberry, etc.
>> UNIX-based handhelds would likely be simplest
>> but the others would likely be useful to a wider
>> audience.
Many handhelds are simply too limited. Those that aren't are usually
Linux based and its just a matter of cross-compiling. Unfortunately a
lot of the chips are not really suitable for floating point work.
Additionally, a lot of the very limited PDAs (e.g. Coldfire-based
PDAs) don't have an MMU.
>>
>> 6. Issue Tracking in Packages
>>
>> Standard method of tracking issues in CRAN
>> packages. Provide svn and Trac support or
>> equivalent to CRAN package authors or at least
>> have a common change log mechanism. There is
>> currently no uniform way of finding out what has
>> changed in a package.
>>
>> 7. system
>>
>> The a
[Rd] R crash with complex matrix algebra when using EISPACK=TRUE
Dear subscribers of R-devel
I am experiencing that R crashes (further details are given below) in
some complex matrix calculations when EISPACK=TRUE has been specified in
eigen().
I discovered the behaviour some months ago just after the
release of R-2.2.0, and it has been lying on my desk since.
I apologise for not having nailed the problem down to a simple function
call, but I thought I should better report the problem now
instead of waiting.
My hope is that someone will either spot the cause
of the crash in a minute, or otherwise provide some help for me to
investigate further.
## The code :
source("http://www.daimi.au.dk/~olefc/TEST/fct.R";)
source("http://www.daimi.au.dk/~olefc/TEST/parm.crash.R";)
for(l.v in 1:4){
for(r.v in 1:4){
for(l.x in 1:4){
for(r.x in 1:4){
hvad <-
inhomoWmat.complex(subst.ratematrix(parm.same.str.sym$Gamma[,,l.v,r.v]),subst.ratematrix(parm.same.str.sym$Gamma[,,l.x,r.x]),
EISPACK=TRUE)
print(c(l.v,r.v,l.x,r.x))
}
}
}
}
## gives
[1] 1 1 1 1
[1] 1 1 1 2
[1] 1 1 1 3
[1] 1 1 1 4
[1] 1 1 2 1
Segmentation fault
### whereas the code seems to work fine when EISPACK=FALSE :
source("http://www.daimi.au.dk/~olefc/TEST/fct.R";)
source("http://www.daimi.au.dk/~olefc/TEST/parm.crash.R";)
for(l.v in 1:4){
for(r.v in 1:4){
for(l.x in 1:4){
for(r.x in 1:4){
hvad <-
inhomoWmat.complex(subst.ratematrix(parm.same.str.sym$Gamma[,,l.v,r.v]),subst.ratematrix(parm.same.str.sym$Gamma[,,l.x,r.x]),
EISPACK=FALSE)
print(c(l.v,r.v,l.x,r.x))
}
}
}
}
## works fine.
## There is some randomness in how and when the crash happens.
## The crash is either :
Segmentation fault
#
*** glibc detected *** double free or corruption (!prev): 0x08aa7298
***
# or
*** glibc detected *** free(): invalid pointer: 0x082bfd20 ***
## Seen on R-2.2-1 and R-2.2-0 .
## Not seen in R-2.1.1 !
## I haven't investiated whether it happens on Windows also.
### A few details on the matrix calculations :
The eigenvalue decomposition is done on 4 * 4 matrices where the rows
sum to 0.
The matrices may be on the edge of not being complex diagonalizable.
version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major2
minor2.1
year 2005
month12
day 20
svn rev 36812
language R
Thanks in advance of any help.
Ole Christensen
--
Ole F. Christensen
BiRC - Bioinformatics Research Center
University of Aarhus
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wish list
I very much share Duncan's concern that research in statistical software should move ahead, and contribute to some of the exciting new uses of data we see. R is the most striking success in statistical software over the last decade, in terms of the variety and quantity of statistical technology it's made available. The R mechanism for managing the system and making packages available is very effective for sharing statistical techniques. I think the community owes a big debt to the people in R core and others who've made this happen. But the most striking current developments in how data & information are collected and used are taking place largely outside our context. The software implemented in R and the people involved could add some important abilities that won't be available otherwise. How do we get from here to there, though? The very success of R tends to push against major changes, as opposed to incremental additions. Thinking about the situation now versus the way S developed starting about 30 years ago, I see differences in the context, technical and human, that challenge us. Technical challenges: Mainly, the obvious difference is the scale of current hardware and software, and the speed with which new technology arises. I think this means our response has to emphasize components, and interfaces that work _with_ other systems, including R. Human challenges: As S grew, we had a group of about 2-6 people working together with support for risk-taking research aimed at major changes. How do we get a critical mass going for the next breakthrough? We need people working closely together, we need support, and we need to include teaching and graduate research, all required to keep good research going in this area. Duncan Temple Lang wrote: > ... > > >And while we are on the topic of wishlists... >Generally (i.e. not directed specifically to Gabor), >the suggestions are very welcome, but so are contributions. >And for issues such as making the existing R available on handhelds, >that is a programming task. And I draw a large distinction between >programming and creative research which is based on new concepts and >paradigms. The pool of people working in statistical computing research >is very small. And to a large extent, their time is consumed with >programming - making the same thing work on multiple platforms, >correcting documentation, etc. which are good things, but >not obviously the best use of available research ability and time. >There are many more topics that are in progress that represent >changes to what we can do rather than just to how we do the same thing. > >One of the reasons S (R and S-Plus) is where it is now >is because in Bell Labs, the idea was to be thinking >5 years ahead and both meeting and directing the needs for the future. >Because of R's popularity (somewhat related to it being free), there is >an aspect of development that focuses more on software for statisticians >to use "right now". >Obviously, th development is a mixture of both the current and the >future, but there is less of the future and certainly less of the >longer term directions that is sacrificed by the need to maintain an >existing system and be backward-compatible. >If statistics is to fulfill its potential in this modern IT, we need new >ideas and research into those new ideas. If we focus on basic >programming tasks (however complex) and demand usability above concepts, >we risk losing those whose primary focus is in statistical computing >research from the field. > >While R provides statisticians and stat. comp. researchers with a >terrific vehicle for doing their respective work, it also acts as >a constraint for doing anything even moderately new. But much (not all) >of R is based on innovations from the 1970's, 80's and 90's. And >as IT evolves at a terrific pace, to keep up with it, we need to be >forward looking. > > >I'll leave it there - for the moment - and go fight off the ants >that are invading my desk! While I wrote this down relatively >rapidly, the ideas have been brewing for a long time. If anyone >wishes to comment on the theme, I hope they will take a few minutes >to think about the broad set of issues and tradeoffs. > > > D. > > > > >>__ >>R-devel@r-project.org mailing list >>https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > >- -- >Duncan Temple Lang[EMAIL PROTECTED] >Department of Statistics work: (530) 752-4782 >4210 Mathematical Sciences Building fax: (530) 752-7099 >One Shields Ave. >University of California at Davis >Davis, >CA 95616, >USA >-BEGIN PGP SIGNATURE- >Version: GnuPG v1.4.2 (Darwin) > >iD8DBQFDt/by9p/Jzwa2QP4RAr6UAJ4mT9C1JcGwlFFJRFVDteyetDrAjACfax7B >0MpswqQE442j23WzJjqUADA= >=Aq8t >-END PGP SIGNATURE- > >__ >R-devel@r-project.org mailing list >
Re: [Rd] all.equal() improvements (PR#8191)
I've now finally finalized my work on a subset of Andy's propositions, and committed it to R-devel. The current change doesn't show in our own checks and examples, but may well in other people's package checks. For this reason, I've also added a line to the 'USER-VISIBLE CHANGES' part of the NEWS file. Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R crash with complex matrix algebra when using EISPACK=TRUE
Try valgrind. That is reporting use outside arrays in rg, that is the
non-complex case of eigen().
Otherwise, using gctorture(TRUE) will help precipitate the error.
On Mon, 2 Jan 2006, Ole F. Christensen wrote:
>
> Dear subscribers of R-devel
>
> I am experiencing that R crashes (further details are given below) in
> some complex matrix calculations when EISPACK=TRUE has been specified in
> eigen().
> I discovered the behaviour some months ago just after the
> release of R-2.2.0, and it has been lying on my desk since.
> I apologise for not having nailed the problem down to a simple function
> call, but I thought I should better report the problem now
> instead of waiting.
> My hope is that someone will either spot the cause
> of the crash in a minute, or otherwise provide some help for me to
> investigate further.
>
>
> ## The code :
>
>
> source("http://www.daimi.au.dk/~olefc/TEST/fct.R";)
> source("http://www.daimi.au.dk/~olefc/TEST/parm.crash.R";)
>
> for(l.v in 1:4){
> for(r.v in 1:4){
>for(l.x in 1:4){
> for(r.x in 1:4){
>hvad <-
> inhomoWmat.complex(subst.ratematrix(parm.same.str.sym$Gamma[,,l.v,r.v]),subst.ratematrix(parm.same.str.sym$Gamma[,,l.x,r.x]),
> EISPACK=TRUE)
>print(c(l.v,r.v,l.x,r.x))
> }
>}
> }
> }
>
>
> ## gives
>
> [1] 1 1 1 1
> [1] 1 1 1 2
> [1] 1 1 1 3
> [1] 1 1 1 4
> [1] 1 1 2 1
> Segmentation fault
>
>
>
> ### whereas the code seems to work fine when EISPACK=FALSE :
>
>
> source("http://www.daimi.au.dk/~olefc/TEST/fct.R";)
> source("http://www.daimi.au.dk/~olefc/TEST/parm.crash.R";)
>
> for(l.v in 1:4){
> for(r.v in 1:4){
>for(l.x in 1:4){
> for(r.x in 1:4){
>hvad <-
> inhomoWmat.complex(subst.ratematrix(parm.same.str.sym$Gamma[,,l.v,r.v]),subst.ratematrix(parm.same.str.sym$Gamma[,,l.x,r.x]),
> EISPACK=FALSE)
>print(c(l.v,r.v,l.x,r.x))
> }
>}
> }
> }
>
> ## works fine.
>
>
> ## There is some randomness in how and when the crash happens.
> ## The crash is either :
>
> Segmentation fault
>
> #
>
> *** glibc detected *** double free or corruption (!prev): 0x08aa7298
>***
>
> # or
>
> *** glibc detected *** free(): invalid pointer: 0x082bfd20 ***
>
>
>
> ## Seen on R-2.2-1 and R-2.2-0 .
> ## Not seen in R-2.1.1 !
> ## I haven't investiated whether it happens on Windows also.
>
>
> ### A few details on the matrix calculations :
> The eigenvalue decomposition is done on 4 * 4 matrices where the rows
> sum to 0.
> The matrices may be on the edge of not being complex diagonalizable.
>
>
> version
> _
> platform i686-pc-linux-gnu
> arch i686
> os linux-gnu
> system i686, linux-gnu
> status
> major2
> minor2.1
> year 2005
> month12
> day 20
> svn rev 36812
> language R
>
>
> Thanks in advance of any help.
>
> Ole Christensen
>
> --
> Ole F. Christensen
> BiRC - Bioinformatics Research Center
> University of Aarhus
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] all.equal() improvements (PR#8191)
I'm "happy" to have found the first problem myself:
'Matrix' doesn't pass R CMD check anymore with the change I had
committed:
Basically because of this:
> all.equal(cbind(1:5), matrix(1:5, 5,1, dimnames=list(NULL,NULL)))
[1] "Attributes: < Names: Lengths (1, 2) differ (string compare on first 1) >"
[2] "Attributes: < Length mismatch: comparison on first 1 components >"
This new behavior is "S-compatible" insofar as S-plus 6.1 also
returns non-TRUE.
Is this what we want?
{we'll see soon how many other CRAN packages are having problems for it}
In my intuition, I'd have liked all.equal() to return TRUE for the above,
since in principle, dimnames = NULL or dimnames = list(NULL,NULL)
is a trivial difference.
OTOH, it will need "special case" code to assure this, and I
wonder if that's worth it.
Please comment!
Martin
> "MM" == Martin Maechler <[EMAIL PROTECTED]>
> on Mon, 2 Jan 2006 18:00:15 +0100 (CET) writes:
MM> I've now finally finalized my work on a subset of Andy's
MM> propositions, and committed it to R-devel.
MM> The current change doesn't show in our own checks and
MM> examples, but may well in other people's package checks.
MM> For this reason, I've also added a line to the
MM> 'USER-VISIBLE CHANGES' part of the NEWS file.
MM> Martin
MM> __
MM> R-devel@r-project.org mailing list
MM> 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] all.equal() improvements (PR#8191)
Martin,
I have some tests running over CRAN now (RUnit has also failed), but have
already noticed things like
> swiss[, 1] -> x
> names(x) <- rownames(swiss)
> all.equal(x, x[1:10])
[1] "Names: Lengths (47, 10) differ (string compare on first 10)"
[2] "Numeric: lengths (47, 10) differ"
which is telling me the obvious, with the result that the reports from
e.g. rpart are cluttered to the detriment of legibility.
I think we need to think harder about what should be reported when the
objects differ in mode or length.
Brian
On Mon, 2 Jan 2006 [EMAIL PROTECTED] wrote:
> I'm "happy" to have found the first problem myself:
>
> 'Matrix' doesn't pass R CMD check anymore with the change I had
> committed:
I am seeing a problem in setGeneric which stops it being installed.
>
> Basically because of this:
>
> > all.equal(cbind(1:5), matrix(1:5, 5,1, dimnames=list(NULL,NULL)))
> [1] "Attributes: < Names: Lengths (1, 2) differ (string compare on first 1)
> >"
> [2] "Attributes: < Length mismatch: comparison on first 1 components >"
>
> This new behavior is "S-compatible" insofar as S-plus 6.1 also
> returns non-TRUE.
>
> Is this what we want?
> {we'll see soon how many other CRAN packages are having problems for it}
>
> In my intuition, I'd have liked all.equal() to return TRUE for the above,
> since in principle, dimnames = NULL or dimnames = list(NULL,NULL)
> is a trivial difference.
> OTOH, it will need "special case" code to assure this, and I
> wonder if that's worth it.
>
> Please comment!
> Martin
>
>> "MM" == Martin Maechler <[EMAIL PROTECTED]>
>> on Mon, 2 Jan 2006 18:00:15 +0100 (CET) writes:
>
>MM> I've now finally finalized my work on a subset of Andy's
>MM> propositions, and committed it to R-devel.
>
>MM> The current change doesn't show in our own checks and
>MM> examples, but may well in other people's package checks.
>MM> For this reason, I've also added a line to the
>MM> 'USER-VISIBLE CHANGES' part of the NEWS file.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] all.equal() improvements (PR#8191)
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Mon, 2 Jan 2006 20:39:18 + (GMT) writes:
BDR> Martin,
BDR> I have some tests running over CRAN now (RUnit has also failed),
thank you, Brian, for the feedback
BDR> but have already noticed things like
>> swiss[, 1] -> x
>> names(x) <- rownames(swiss)
>> all.equal(x, x[1:10])
BDR> [1] "Names: Lengths (47, 10) differ (string compare on first 10)"
BDR> [2] "Numeric: lengths (47, 10) differ"
BDR> which is telling me the obvious, with the result that the reports from
BDR> e.g. rpart are cluttered to the detriment of legibility.
BDR> I think we need to think harder about what should be reported when the
BDR> objects differ in mode or length.
I agree; the above is good example.
[OTOH, I don't think the above behavior to be a complete show
stopper; since it's somewhat close to the way S-plus does things]
BDR> Brian
BDR> On Mon, 2 Jan 2006 [EMAIL PROTECTED] wrote:
>> I'm "happy" to have found the first problem myself:
>>
>> 'Matrix' doesn't pass R CMD check anymore with the change I had
>> committed:
BDR> I am seeing a problem in setGeneric which stops it being installed.
{ah yes; for R-devel you need the "next" version of Matrix
the important part of which I'll commit shortly to R-packages; it
will take another day before I'll upload it to CRAN}
>> Basically because of this:
>>
>> > all.equal(cbind(1:5), matrix(1:5, 5,1, dimnames=list(NULL,NULL)))
>> [1] "Attributes: < Names: Lengths (1, 2) differ (string compare on first
1) >"
>> [2] "Attributes: < Length mismatch: comparison on first 1 components >"
>>
>> This new behavior is "S-compatible" insofar as S-plus 6.1 also
>> returns non-TRUE.
>>
>> Is this what we want?
>> {we'll see soon how many other CRAN packages are having problems for it}
>>
>> In my intuition, I'd have liked all.equal() to return TRUE for the
above,
>> since in principle, dimnames = NULL or dimnames = list(NULL,NULL)
>> is a trivial difference.
>> OTOH, it will need "special case" code to assure this, and I
>> wonder if that's worth it.
>>
>> Please comment!
>> Martin
>>
>>> "MM" == Martin Maechler <[EMAIL PROTECTED]>
>>> on Mon, 2 Jan 2006 18:00:15 +0100 (CET) writes:
>>
MM> I've now finally finalized my work on a subset of Andy's
MM> propositions, and committed it to R-devel.
>>
MM> The current change doesn't show in our own checks and
MM> examples, but may well in other people's package checks.
MM> For this reason, I've also added a line to the
MM> 'USER-VISIBLE CHANGES' part of the NEWS file.
BDR> --
BDR> Brian D. Ripley, [EMAIL PROTECTED]
BDR> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
BDR> University of Oxford, Tel: +44 1865 272861 (self)
BDR> 1 South Parks Road, +44 1865 272866 (PA)
BDR> Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] checkpointing
I would like to checkpoint some of my calculations in R, specifically those using optim. As far as I can tell, R doesn't have this facility, and there seems to have been little discussion of it. checkpointing is saving enough of the current state so that work can resume where things were left off if, to take my own example, the system crashes after 8 days of calculation. My thought is that this could be added as an option to optim as one of the control parameters. I thought I'd check here to see if anyone is aware of any work in this area or has any thoughts about how to proceed. In particular, is save a reasonable way to save a few variables to disk? I could also make the code available when/if I get it working. -- Ross Boylan wk: (415) 514-8146 185 Berry St #5700 [EMAIL PROTECTED] Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] xy.coords
On 12/31/2005 4:09 PM, Gabor Grothendieck wrote: > On 12/31/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > >>On 12/31/2005 3:26 PM, Gabor Grothendieck wrote: >> >>>I think this is just playng with words. >> >>I'm starting to be convinced of that by the fact that you haven't posted >>any sample code where using a single parameter would be desirable. > > > Loose coupling is a general principle that should be followed as a matter > of course and does not need case by case justification. If there were > a performance issue, say, one might justify circumventing > otherwise desirable principles but there is no conflicting tradeoff here. Generally I agree, but I've just committed the doc change only, for these reasons: - xy.coords is likely to be used by high-level plot functions that have inputs like plot.default; if they follow its pattern closely, then they'll never need a one-parameter call. This will encourage consistency. - the interface to those functions has been unchanged for years, and I don't like changing old interfaces without strong reasons. This was really a borderline case, but the fact that I couldn't think of a situation where it would be good to use a one parameter call to xy.coords tipped the balance in my mind. Duncan Murdoch > > > >>The fact that its always been >> >>>like that is not sufficient and is not related to consistency. >>>xyz.coords also does not work in accordance with the help file >>>so the fact that the error extends to it just means they are both >>>in error. >> >>>Modularity means loose coupling -- i.e. a function should be >>>as independent as possible from its surroundings. The fact >>>that the second argument is not missing in uses within R base >>>is not a valid argument for appropriate attention to this principle. >>> >>>Furthermore, its clear that the current way it works is not even >>>the intended way -- the intended and better way is as documented >>>and the software, not the documentation, ought to be changed. >> >>Take a look at the examples. It's pretty clear that it is working as >>intended, and the documentation incorrectly says "missing" where it >>means "NULL". >> >>Duncan Murdoch >> >>> >>>On 12/31/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >>> >>> On 12/31/2005 12:57 PM, Gabor Grothendieck wrote: >It does not achieve design consistency. It's consistent with the way it has been for at least 7 years, and is consistent with xyz.coords(). One would have to >specify NULL but that should not really be necessary. In fact, one almost never needs to specify NULL there. It's the default value for y in the high level functions that call xy.coords, so it is put there automatically. Duncan Murdoch >On 12/31/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > > > >>On 12/31/2005 12:21 PM, Gabor Grothendieck wrote: >> >> >> >>>I think the point is that (1) it does not work as documented and (2) in >>>most functions one can omit unnecessary args without having >>>to specify NULL so its behvaior seems inconsistent from a design >>>viewpoint. By allowing either missing or NULL it will work as >>>documented, >>>and probably intended, yet continue to be backward compatible with >>>existing usages. >> >>But a simpler change is to change the documentation, and it achieves all >>of those objectives. >> >>Duncan Murdoch >> >> >> >>>On 12/31/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>> On 12/31/2005 8:57 AM, Gabor Grothendieck wrote: >It could be changed to missing(y) || is.null(y) and the docs amended. >That way existing code will continue to work and code that otherwise >gives an error currently, but should have worked, will now work too. Can you give an example where you would want to use xy.coords(y ~ x)? Normally xy.coords() is used in other functions, and they can default y to NULL (see plot.default, for example). Duncan Murdoch >On 12/31/05, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > > > > > >>On 12/30/2005 10:10 PM, Gabor Grothendieck wrote: >> >> >> >> >> >>>In ?xy.coords it says: >>> >>> If 'y' is missing and 'x' is a >>> >>> formula: of the form 'yvar ~ xvar'. 'xvar' and 'yvar' are used as >>> x and y variables. >>> >>> list: containing components 'x' and 'y', these are used to define >>> plotting coordinates. >>> >>> time series: the x values are taken to be 'time(x)' and the y >>> values to be the time series. >>> >>> matrix with two columns: the f
[Rd] load, environment[[, and attr<-/attributes<- (PR#8457)
Full_Name: Mark Bravington Version: 2.2.1 OS: Windows XP Submission from: (NULL) (203.132.243.69) # [EMAIL PROTECTED] There is a bug to do with 'load', environment access via '[[', and 'attr<-' or 'attributes<-'. Modifying the attributes of a *copy* of an object can modify the original too, under certain conditions: - the copy needs to be created using env[[ not by env$ nor just by name - the original object must have been 'load'ed and not subsequently read-accessed before the copy was created The script below might clarify this. BTW the problem is not only for .GlobalEnv. It's intriguing that 'load' doesn't seem to be "fully creating" the object-- is it just creating a promise or something like that? Mark Bravington [EMAIL PROTECTED] a <- 1 attr( a, 'thing') <- 99 tf <- tempfile() save( a, file=tf) load( tf) y <- .GlobalEnv[[ 'a']] attr( y, 'thing') <- NULL a # attr gone! load( tf) y <- .GlobalEnv$a attr( y, 'thing') <- NULL a # OK load( tf) a # to force access y <- .GlobalEnv[[ 'a']] attr( y, 'thing') <- NULL a # OK unlink( tf) --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 2 minor = 2.1 year = 2005 month = 12 day = 20 svn rev = 36812 language = R Windows XP Professional (build 2600) Service Pack 1.0 Locale: LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252 Search Path: .GlobalEnv, package:methods, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, Autoloads, package:base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
