Re: [Rd] Suggestion: help(package name)
On Tue, 7 Jun 2005, Duncan Murdoch wrote: [...] My proposal (modified following the suggestions I've heard so far) is as follows: - to check that a couple of help topic aliases exist (pkg.package and pkg) - to recommend that pkg.package contain general information about the package, and that pkg be an alias for it, if it isn't used for some other purpose. - to write promptPackage() to help create an initial version of pkg.package.Rd. It can get some information from the DESCRIPTION file; perhaps it could go looking for a vignette, or the INDEX, or - to modify the other help system tools to make use of this (e.g. the package:pkg heading on a page would become a link to the pkg.package alias, etc.) I've now committed some of this to R-devel, and I invite comments. I've abandoned the idea of the check, which seems too controversial. I've done the second and third items, but not the 4th. I wrote about a dozen of these files this afternoon as I was refining promptPackage. It is very quick to generate a basic man page using promptPackage with an option saying you want a final version. Manually editing this file, running it through checks, etc. took me around 10-20 minutes per package. I only did the base packages, and they probably have less in their overview than most contributors would want, so someone starting from nothing would probably take longer --- but many packages already have the text written somewhere, and they just need to add an alias to an Rd file, or perhaps reformat an INDEX file. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NEWS, WISHLIST, THANKS
On 6/9/2005 3:41 PM, Gabor Grothendieck wrote: I have NEWS, WISHLIST and THANKS files in the 'dyn' package in the same directory as the DESCRIPTION file but I noticed that they did not survive the move to CRAN, at least on Windows. How do I incorporate them so that they are not omitted? The R extensions manuals tells you the filenames that mean something to R. (See the Package Structure section.) All else is omitted unless it's in the inst directory, in which case it should be copied up a level upon installation. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: help(package name)
Henrik Bengtsson wrote:
It seems that it comes down to two things: 1) a standard Rd topic or
alias pkg.package, and 2) enforcing this standard with R CMD check.
Pro's and con's for (1):
Pros:
- Easy to find overview information on a package, that is, you know
*where* to find it.
- Allows a packages to link to another package.
- Shows up in the HTML index page.
- The pkg.package.html can be included on the CRAN package overview.
This can then also become the author's webpage (kiosk?) for the
package including installation instructions, license, future plans etc.
Searchable on the web (==you can get information before trying to
download/install, which sometimes fails; catch 22.)
Cons:
- Conflicts with other topic of the same name.
- Just another vignette (?)
Pro's and con's for (2):
Pros:
- Guarantees that a package can link to another package.
- Standard immediately adopted.
Cons:
- Requires more maintainance.
- Without automatic tools, redundancy is introduced (more maintainance).
My comments:
I think it is hard to argue that a standard similar to (1) is unwanted.
Also, I don't think anyone has objected on this. The objection has been
on (2). So my suggestion is that one writes up a standard on (1) and
*ask* developers to follow it.
If enforcement by R CMD check (2) was implemented too, then I think it
only requires a single \alias{pkg.package} in any of the Rd files,
because as far as I understand it at least one is required. This would
not require much work (almost cheap). This would guarantee a link at
least to something. A more advanced version is that the pkg.package.Rd
file is automatically created by R CMD build if missing (zero cost).
I really like this zero cost option. I think it addresses the main
problem with the proposal (all the work for package writers that it
creates), while keeping the main benefit (a standard place for package
help *within the help system*).
It might be tricky to implement (the build tools aren't all in R and
aren't consistent across platforms), but it seems like a reasonable
compromise to me.
Duncan Murdoch
To follow up on Gabor's suggestion to add more R CMD check granuality
than errors and warnings. Using classes and the new exception
handling, one could introduce a warning class called Suggestion
(CranSuggestion), which gives suggestions to the user, but not enforce
them (warning are not allowed on CRAN).
To extend this idea further, one could add non-enforced checks if a
package follows certain standardizations or not. I can image such
checks to be plugins to R CMD check or standalone. Other solutions may
also used. For instance, R CMD checkRCC could check a package against
the coding convention RCC (http://www.maths.lth.se/help/R/RCC/).
Supplementary or complementary standards can provide their own checks.
Such tools would be helpful for large projects to conform to the same
standards, but not enforcing them. Packages following certain standards
could then advertize this to help the user and other developers
utilizing their packages and so.
To summarize, I think it is good if you can communicate that you follow
a certain standard, and it is even better if more peoples are using the
same standard. I agree, that enforced standards are painful, if you
disagree with them (or find the unnecessary).
Cheers
Henrik
Robin Hankin wrote:
The reason I like .Rd files is that I can run the examples easily and,
as Martin points out,
one does not need to learn a new syntax.
How about adding the following to R-exts:
We encourage the package developer to include a file named
foo.package.Rd in the man
directory, to provide a terse overview of the foo package. This Rd file
is intended to be
the first port of call for a new user of the package, and should provide
(or point to)
working examples of the package's functionality. It may also provide
details or rationale
for the package's structure, if non-standard; and perhaps document other
features of
the package that might escape a new user's notice.
See package foo for an example
and package.skeleton() could be modified to write a skeleton version of
foo.package.Rd
and put it in the man directory.
best wishes everyone
rksh
Duncan writes:
My proposal (modified following the suggestions I've heard so far) is
as follows:
- to check that a couple of help topic aliases exist (pkg.package
and pkg)
- to recommend that pkg.package contain general information about
the package, and that pkg be an alias for it, if it isn't used for
some other purpose.
- to write promptPackage() to help create an initial version of
pkg.package.Rd. It can get some information from the DESCRIPTION
file; perhaps it could go looking for a vignette, or the INDEX, or
- to modify the other help system tools to make use of this (e.g. the
package:pkg heading on a page would become a link to the
pkg.package alias, etc.)
Martin:
And as much as I do like
Re: [Rd] Suggestion: help(package name)
Torsten Hothorn wrote: On Tue, 7 Jun 2005, Duncan Murdoch wrote: [...] My proposal (modified following the suggestions I've heard so far) is as follows: - to check that a couple of help topic aliases exist (pkg.package and pkg) - to recommend that pkg.package contain general information about the package, and that pkg be an alias for it, if it isn't used for some other purpose. - to write promptPackage() to help create an initial version of pkg.package.Rd. It can get some information from the DESCRIPTION file; perhaps it could go looking for a vignette, or the INDEX, or - to modify the other help system tools to make use of this (e.g. the package:pkg heading on a page would become a link to the pkg.package alias, etc.) as a package author who already provides help pages for general package descriptions (`?multcomp' and `?coin' work and, if I remember correctly, Martin suggested to include the advertisement this way) I must admit that I never say `?foo' when I'm interested in a global overview about a new package `foo'. I do occasionally, but usually it's a waste of time. This proposal is intended to address that. Instead, `library(help = foo)' gives what I want to see, namely the title and description of a package and all documented topics. One may argue that asking `library' for help is not the most obvious thing to do. But people able to recall that fitting an ANOVA model requires `aov' and comparing two models needs `anova' should be able to have `library' in mind for general package information. As I pointed out, this is okay for people who know R already, but not so good for beginners. The answer to the question how do I get help on foo? is too complex. So, for me having infrastructure for _automatically_ generated overviews is very nice, but _forcing_ package authors to provide additional meta-information would be less welcome. What do you think of Henrik's suggestion to generate a help topic giving information equivalent to library(help=pkg)? I think this would happen at install time (not build time as he said; no need to put this in the source tarballs). If the pkg.package alias wasn't defined, the installer would automatically create one. If we had this in place, I'd strengthen the advice in R-Exts not to bother with a manually created INDEX file: that information should go into a manually created pkg.package topic instead. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in help(package=) (PR#7923)
The following is a bug or mis-design in help(package=): showhelp - function(packageName) help(package=packageName) showhelp(utils) Error in .find.package(pkgName, lib.loc, verbose = verbose) : none of the packages were found The problem is that it calls library(help=) with argument packageName instead of utils. Unlike library(), it has no character.only argument to force interpretation of the packageName as a character vector. --please do not edit the information below-- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = major = 2 minor = 1.0 year = 2005 month = 04 day = 18 language = R Windows XP Professional (build 2600) Service Pack 2.0 Search Path: .GlobalEnv, package:methods, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, Autoloads, package:base __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in new() or validObject() in methods package (PR#7922)
McGehee, Robert wrote: The bug might be here: is.null(expression()) [1] TRUE But is.null(expression(NULL)) [1] FALSE So it might look to the methods package like you're passing in a NULL value for @bar. I might argue that expression() should not be NULL (and only NULL is NULL) as I have had similar trouble trying to extend language objects to S4 classes, partially because length 0 name, call and expression objects are either not available, or in this case, handled poorly. I think you've spotted it. The internal code for is.null checks for NULL or a zero length expression, not just for NULL. Changing that so it only accepts NULL fixes this bug. This code has been in place since prehistoric times, so I'm going to tread pretty carefully here before I commit a change. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: help(package name)
On 6/7/2005 11:12 AM, Robert Gentleman wrote: Robin Hankin wrote: My 0.02: I use Misc.Rd for the purpose that Duncan suggests. I put things like details and rationale for package organization, pointers to the most important function(s) in the package, and perhaps function descriptors for ubiquitous functions that don't warrant their own helppage, but need documentation [in the case of gsl, this would be strictify() and process.args(), which every user needs to know]. It would be *great* to be required to put in package.gsl.R (or should that be gsl.package.Rd?) for this purpose. Then maybe R CMD check could check for its presence and throw a wobbly if it isn't there. Hi, Well, I pretty strenuously object. That is just what vignettes are for and the last thing I need is more wobbly's from R CMD check. Function documentation should document functions. If you want to document something more substantial then please use the tools already provided to do that - and if you don't want to, and you want to make use of the tools for function documentation in some other way please don't try to impose your version of what should happen on others. The current .Rd files don't just document functions, they also document data objects and classes. But the main point here is that it's not good to have multiple disconnected sets of documentation for a package. Users should be able to say the equivalent of give me help on foo, and get help on foo, whether it's a function, a data object, a package, a method, a class, or whatever. It's a bad design to force them to ask for the same sort of thing in different ways depending on the type of thing they're asking for. If we had a way to link vignettes into the help system, then I'd think it would be perfectly acceptable for ?package to pop up a vignette for the package. However, right now we have too many different types of ways to display help, and not all of them are capable of displaying vignettes. Duncan Murdoch Best wishes Robert Some packages have so much material that it's difficult to know where the meat of the functionality lies, and Duncan's suggestion would help greatly in these circumstances. best wishes rksh On Jun 7, 2005, at 01:11 pm, Duncan Murdoch wrote: Kurt Hornik wrote: Henrik Bengtsson writes: Hi, I would like to suggest a standard where all packages provide an Rd page with the same name (or aliased) as the name of package so that help(package name) or ?package name is always here. This especially of interest to large packages with a large package index. This page could explain the package in general and gives some hints on how to start - not like extensive vignettes, but just to get started, e.g. list the most important functions. This page could typically contain information that is in the DESCRIPTION file (which contains valuable information hardly every accessed by a general user), such as who is the maintainer, how to report bugs and so on. I think this is a good idea. One minor problem is that for some packages that topic name is already in use for a function (e.g. boot). For that reason, I'd suggest that there *also* be an alias called package.package name, and the package name topic should link to it. How would this be different from the results of help(package = package name) ? 1. It would work with ?, like other help topics. 2. It would give an overview. It's possible to do that in DESCRIPTION or INDEX, but you don't get the same style as for other help files (e.g. no links to other topics, at least in Windows). We should work out what the topic headings should be and extend package.skeleton() and prompt() to write a bare-bones file that suggests the questions that need to be answered in the file. The headings I'd suggest are: \name \title \alias \description (longer than the typical entry in the DESCRIPTION file) \details (Should give a short guide to the main functions, should point out the existence of external documentation like vignettes, etc.) \author (could also describe maintainer, if different) \references \seealso (Should give references to related packages) \examples \keywords There is some duplication of material from DESCRIPTION, but usually this should be longer and more reader-friendly than that file. I'd be happy to write the description of this in R Extensions, and write the changes to prompt(), if we have agreement that this file should be mandatory in 2.2.x or 2.3.x, and you'll write the checks for it. (I think the check should just be for existence of aliases package name and package.package name, and could perhaps just give a warning in 2.2.x.) Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Robin Hankin Uncertainty Analyst National Oceanography Centre, Southampton European Way, Southampton SO14 3ZH
Re: [Rd] Suggestion: help(package name)
On 6/7/2005 11:59 AM, Robert Gentleman wrote: Duncan Murdoch wrote: On 6/7/2005 11:12 AM, Robert Gentleman wrote: Robin Hankin wrote: My 0.02: I use Misc.Rd for the purpose that Duncan suggests. I put things like details and rationale for package organization, pointers to the most important function(s) in the package, and perhaps function descriptors for ubiquitous functions that don't warrant their own helppage, but need documentation [in the case of gsl, this would be strictify() and process.args(), which every user needs to know]. It would be *great* to be required to put in package.gsl.R (or should that be gsl.package.Rd?) for this purpose. Then maybe R CMD check could check for its presence and throw a wobbly if it isn't there. Hi, Well, I pretty strenuously object. That is just what vignettes are for and the last thing I need is more wobbly's from R CMD check. Function documentation should document functions. If you want to document something more substantial then please use the tools already provided to do that - and if you don't want to, and you want to make use of the tools for function documentation in some other way please don't try to impose your version of what should happen on others. The current .Rd files don't just document functions, they also document data objects and classes. But the main point here is that it's not good to have multiple disconnected sets of documentation for a package. Users should be able to say the equivalent of give me help on foo, and get help on foo, whether it's a function, a data object, a package, a method, a class, or whatever. It's a bad design to force them to ask for the same sort of thing in different ways depending on the type of thing they're asking for. Hi Duncan and others, I think they are linked. There are tools available both in R and in Bioconductor and some pop things up and some don't. It doesn't take much work to add vignettes to the windows menu bar - as we have done in BioC for some time now - it would be nice if this was part of R, but no one seems to have been interested in achieving that. Fixing the help system to deal with more diverse kinds of help would be nice as well - but taking one part of it and saying, now everyone must do it this way is not that helpful. I respectfully disagree about the main point. My main point is, I don't want more things imposed on me; dealing with R CMD check is enough of a burden in its current version, without someone deciding that it would be nice to have a whole bunch more requirements. Folks should feel entirely free to do what they want - but a little less free to tell me what I should be doing. And I disagree pretty strenuously about that. One of the strengths of R is that it does impose standards on contributed packages, and these make them easier to use, less likely to conflict with each other, and so on. We shouldn't impose things lightly, but if they do make packages better, we should feel no reason not to tell you what you should be doing. Currently R has 3 types of help: the .Rd files in the man directory (which are converted into plain text, HTML, compiled HTML, LaTex, DVI, PDF, etc), the vignettes, and unstructured files in inst/doc. We currently require .Rd files for every function and data object. Adding a requirement to also document the package that way is not all that much of a burden, and will automatically give all those output formats I listed above. It will help to solve the often-complained about problem of packages that contain no overview at all. (Requiring a vignette and giving a way to display it would also do that, but I think requiring a .Rd file is less of a burden, and for anyone who has gone to the trouble of creating a vignette, gives a natural place for a link to it. Vignettes aren't used as much as they should be, because they are hidden away where users don't see them.) Duncan Murdoch Best wishes, Robert If we had a way to link vignettes into the help system, then I'd think it would be perfectly acceptable for ?package to pop up a vignette for the package. However, right now we have too many different types of ways to display help, and not all of them are capable of displaying vignettes. Duncan Murdoch Best wishes Robert Some packages have so much material that it's difficult to know where the meat of the functionality lies, and Duncan's suggestion would help greatly in these circumstances. best wishes rksh On Jun 7, 2005, at 01:11 pm, Duncan Murdoch wrote: Kurt Hornik wrote: Henrik Bengtsson writes: Hi, I would like to suggest a standard where all packages provide an Rd page with the same name (or aliased) as the name of package so that help(package name) or ?package name is always here. This especially of interest to large packages with a large package index. This page could explain the package in general and gives some
Re: [Rd] Suggestion: help(package name)
it if the algorithm was type ?foo, and read what you get, regardless of what foo is. The proposal above doesn't achieve that, but it gets closer. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: help(package name)
Liaw, Andy wrote: Let me add to the pot: I think Robert and Brian are against imposing additional _requirement_ on packages to provide an overview in .Rd, and I tend to agree with that sentiment. However, if such a facility is made optional (like vignettes) for package author/maintainer, then I have no problem with it. Perhaps it can work like the CITATION file: The package author/maintainer can choose to (or not to) use it. If one is not provided in the package source, then something halfway sensible is auto-generated from various files (or perhaps just runs help(package=pkg). Or perhaps yet another function can be added to the `utils' package, like packageOverview(), which can either: - open an overview vignette if one is provided - open the overview .Rd in whatever format the default help is in - run help(package=pkg) if neither is available We don't have a standard name for an overview vignette, and I don't like the idea of creating a new help function (packageOverview) that someone who doesn't know much about R will have to find before they can use, but I like the idea of the help system doing its best to help. So I'd like this better if it were modified so that ?foo tries the following - to open help alias foo - if that fails, and foo is a package name: - tries to open a vignette with some standard name (proposals?) - if that fails, then does help(package=foo) This has the disadvantage over the original proposal that help pages can't link to a standard help topic for the package, so I like the original better, but this would be better than the status quo. Duncan Murdoch Just my $0.02... Andy From: Duncan Murdoch Prof Brian Ripley wrote: I share Robert's `pretty strenuous' objections. Adding compulsory things for package writers seems to me to need very compelling arguments. Checking that a package does what it says (e.g. the code in vignettes can be run) is one thing, but checking it does things it does not say it wants to do is quite another. I don't understand your complaint. Could you explain what you meant by checking it does things it does not say it wants to do? My proposal (modified following the suggestions I've heard so far) is as follows: - to check that a couple of help topic aliases exist (pkg.package and pkg) - to recommend that pkg.package contain general information about the package, and that pkg be an alias for it, if it isn't used for some other purpose. - to write promptPackage() to help create an initial version of pkg.package.Rd. It can get some information from the DESCRIPTION file; perhaps it could go looking for a vignette, or the INDEX, or - to modify the other help system tools to make use of this (e.g. the package:pkg heading on a page would become a link to the pkg.package alias, etc.) None of these things are very much work, and I'd be happy to do them and document them. The thing that will be more work is to write the pkg.package.Rd files for every package. (I'd do it for the base packages; they'd be short.) It won't be a huge amount of work for any one package (many of them already have the basic content in various places, so for those it's mostly a matter of reformatting), but in total it will be a lot. I think the benefit of this will be that the help for a package will show up in a standard location, using the standard method for looking for it. This is not a huge benefit for any users who already know all about the current ways help can be given, but I think it would be a real benefit for users who aren't so familiar with things. It would help to unify the help system: everyone knows about ?topic, so providing a standard way for that to lead into all the rest of the documentation seems obviously beneficial to me. Making this optional would weaken it quite a bit. Packages couldn't give links to the main page in other packages if they weren't guaranteed to exist; producing the HTML would be more difficult if links worked sometimes and didn't work other times, etc. Robert Gentleman wrote: Let's see, some of us (three years ago) developed a tool to solve this problem. Do you mean vignettes? I think they solved a different problem. They provided a way to give good general documentation for a package, but they didn't provide a way to get to it through the help system. They aren't used for general introductory help for any of the standard packages except grid and Matrix, and they use different naming conventions in those two. We made it available to others to use as they saw fit. I feel no less strong than you do, but I certainly did not impose what I thought on you and I ask for the same respect. R imposes lots of things on me. I have to document every function, and I have to get the usage section right. These take work, but they make packages more useful. I think imposing one more help topic on the package
[Rd] Bug in new() or validObject() in methods package (PR#7922)
Something in new() or validObject() in the methods package is messing up. This happens in both 2.1.0 and R-devel in Windows. I'd like to have an empty expression for a slot in a class. An empty expression is an expression: is.expression(expression()) [1] TRUE is(expression(), expression) [1] TRUE class(expression()) [1] expression However, when I try to use this as the initial value, I get an error thrown back at me: setClass(foo, representation(bar = expression)) [1] foo new(foo, bar = expression()) Error in validObject(.Object) : invalid class foo object: invalid object for slot bar in class foo: got class NULL, should be or extend class expression Is it doing an extra eval or something? It looks like it: x - expression() x expression() eval(x) NULL x - quote(expression()) x expression() eval(x) expression() eval(eval(x)) NULL However, it doesn't always happen: new(foo, bar = expression(1+1)) An object of class foo Slot bar: expression(1 + 1) x - expression(1+1) x expression(1 + 1) eval(x) [1] 2 Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Re: [R] A long digression on packages
Hi. I think this discussion is more relevant to R-devel, so that's where I've sent my reply. Jim Lemon wrote: Hello again, First, thanks for the help that got the latest plotrix package finished. I had been planning to write something about packages since Scott Waichler offered the gantt.chart function. Then Ben Bolker (who helped me to write the axis.break function) asked if I would be willing to include some of his plotting functions and almost immediately after that Sander Oom kindly donated the soil texture plotting function in the same way. I could procrastinate no longer. There are now about 500 packages on CRAN. Some are focused, covering a particular area well, easy for the prospective user to discover their potential usefulness, while others are less so. I consider the plotrix package one of the former, and so as not to upset too many people, I will use the other package I contributed to CRAN as an example of the latter. When I initially wrote concord, it was intended as a package of functions dealing with concordance and reliability. Okay, but I found Kendall's W so useful that I couldn't help including it, and somehow Page's test of ordered alternatives crept in and invited the Jonckheere test to the party and at that point I realized that I had maybe forty or fifty more or less useful functions floating around my R directory. Now many of these are probably floating around other people's R directories as well. Consider Cohen's kappa. The tabular method is included in e1071, my version has Cohen's plus two additional methods, and the recently contributed psy package has yet another version. Maybe there are still more encrypted in packages that I haven't even looked at. The point of all this is that it would make many user's lives easier if there were less pandemonium in packages. The mistakes I have made in concord I have tried not to repeat in plotrix. Unless a user search of the documentation in packages materializes, it's become mighty hard to work out if the function you don't want to write has already been written. We also spend a lot of time responding to or deriding correspondents who ask about such things. Would it be an idea to have informal R periphery teams, or even individual package lords, who would bear with, or maybe welcome, other people's functions? That is, I think plotrix has been greatly enhanced by recent contributions. Conversely, I wonder if it would be possible to shrink or maybe even evaporate concord by discovering duplicate methods in other packages or by contributing concord functions or parts thereof myself. It's not that I don't like maintaining concord or think the functions are worthless, just that I am mildly embarrassed to be adding to the duplication of effort and unnecessary volume of packages. Feel free to comment upon this, although if you really want to rave, try it out on me first before clagging the list. Thanks for your attention. A difficulty with multi-author packages is that it's harder to maintain consistency within the package, and it's harder to handle maintenance. Another approach is to try to keep your packages small and focussed. The problem with this is what you mentioned above: there are already 500 packages, and it's hard to know what's there. The task views should help with this, there are 5 online so far. (See http://cran.us.r-project.org/src/contrib/Views.) There is also a need for Misc packages for things too small to be a package on their own, but I think we need better ways to expose what is in them. Of course, with disk sizes as they are now, it's not unreasonable to install all of the contributed CRAN packages on a PC. Then help.search() *will* do searches through them all. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dotcode typo? (PR#7917)
On 6/2/2005 1:27 PM, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Whoops, spoke too soon. This definitely breaks the logic, so I won't commit. With this change the check of demo(lm.glm) in package utils fails with this error message: dead - cbind(x, n - x) summary(glm(dead ~ dose, family = binomial(link = logit))) Error in .Call(logit_link, mu) : cannot resolve native routine Execution halted I'm cc'ing this to R-bugs so we don't forget it, but I'm not going to be able to fix it down myself. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel That occurs in code that I recently added so I better check that. I think it was that .Call() didn't include PACKAGE=stats in stats/R/family.R. I've fixed that; I'll look for other similar cases. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: more flexible handling of tick labels in axis.Date (PR#7913)
I think allowing the user to change the labels is a good idea, but have
some nitpicking about the details.
- Could you grab a copy of the current axis.Date source from
https://svn.r-project.org/R/trunk/src/library/graphics/R/datetime.R
and edit that, rather than what you see in R? There are some comments
in the source that shouldn't be lost. This will also mean that it's
easier to detect what changes you've made.
- I'd prefer the interpretation of the labels argument to be very
similar to what axis() does, i.e. NULL should not be treated specially.
(Actually, I think axis() treats labels=NULL as TRUE, but that's
undocumented and might be an accident.)
- axis.POSIXct() should be modified in a corresponding way.
- Your test
if (missing(labels) || labels == TRUE)
will generate warnings if a vector of labels is passed in. A better
test is identical(labels, TRUE).
- If you set the default value for labels to TRUE, then you don't need
the missing(labels) part of the test.
- Could you also edit
https://svn.r-project.org/R/trunk/src/library/graphics/man/axis.POSIXct.Rd
to reflect your changes?
If you want help with this feel free to contact me off the list; when
you're done, you can send me the files and I'll review and commit the
changes.
Duncan Murdoch
[EMAIL PROTECTED] wrote:
Full_Name: Gavin Simpson
Version: 2.1.0-patched (1-Jun-2005)
OS: Linux (Fedora Core 3)
Submission from: (NULL) (128.40.32.76)
axis.Date() insists on labelling tick marks. It could be made more flexible by
allowing the user to specify if they want the ticks to be labelled, for example,
to add un-labelled minor ticks for months, added to a plot with years
labelled. The user can not define labels = in the ... in the call to
axis.Date() as axis.Date() calls axis() with labels = labels explicitly,
resulting in:
Error in axis(side, at = z, labels = labels, ...) :
formal argument labels matched by multiple actual arguments
if you try.
One way round this would be to add labels as a named argument to axis.Date() and
to allow labels to be NULL (missing), TRUE or FALSE. A first attempt at this is
shown below:
axis.Date2 - function (side, x, at, format, labels, ...)
{
mat - missing(at)
if (!mat)
x - as.Date(at)
else x - as.Date(x)
range - par(usr)[if (side%%2)
1:2
else 3:4]
range[1] - ceiling(range[1])
range[2] - floor(range[2])
d - range[2] - range[1]
z - c(range, x[is.finite(x)])
class(z) - Date
if (d 7)
if (missing(format))
format - %a
if (d 100) {
z - structure(pretty(z), class = Date)
if (missing(format))
format - %b %d
}
else if (d 1.1 * 365) {
zz - as.POSIXlt(z)
zz$mday - 1
zz$mon - pretty(zz$mon)
m - length(zz$mon)
m - rep.int(zz$year[1], m)
zz$year - c(m, m + 1)
z - .Internal(POSIXlt2Date(zz))
if (missing(format))
format - %b
}
else {
zz - as.POSIXlt(z)
zz$mday - 1
zz$mon - 0
zz$year - pretty(zz$year)
z - .Internal(POSIXlt2Date(zz))
if (missing(format))
format - %Y
}
if (!mat)
z - x[is.finite(x)]
z - z[z = range[1] z = range[2]]
z - sort(unique(z))
# if labels is missing or TRUE generate labels for ticks
if (missing(labels) || labels == TRUE)
labels - format.Date(z, format = format)
# else rep to suppress labelling
else labels - rep(, length(z))
axis(side, at = z, labels = labels, ...)
}
An example of using this with the Date example from ?plot.Date :
random.dates - as.Date(2001/1/1) + 70*sort(runif(100))
plot(random.dates, 1:100, xaxt=n)
axis.Date2(1, at=seq(as.Date(2001/1/1), max(random.dates)+6, weeks))
axis.Date2(1, at=seq(as.Date(2001/1/1), max(random.dates)+6, days),
labels = FALSE, tcl = -0.2)
The function should perhaps enforce NULL/TRUE/FALSE for labels, or could be
enhanced to allow labels = explicitly or to allow user defined vector for
labels that is of length(at).
Thanks,
Gavin
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: more flexible handling of tick labels in axis.Date (PR#7914)
I think allowing the user to change the labels is a good idea, but have
some nitpicking about the details.
- Could you grab a copy of the current axis.Date source from
https://svn.r-project.org/R/trunk/src/library/graphics/R/datetime.R
and edit that, rather than what you see in R? There are some comments
in the source that shouldn't be lost. This will also mean that it's
easier to detect what changes you've made.
- I'd prefer the interpretation of the labels argument to be very
similar to what axis() does, i.e. NULL should not be treated specially.
(Actually, I think axis() treats labels=NULL as TRUE, but that's
undocumented and might be an accident.)
- axis.POSIXct() should be modified in a corresponding way.
- Your test
if (missing(labels) || labels == TRUE)
will generate warnings if a vector of labels is passed in. A better
test is identical(labels, TRUE).
- If you set the default value for labels to TRUE, then you don't need
the missing(labels) part of the test.
- Could you also edit
https://svn.r-project.org/R/trunk/src/library/graphics/man/axis.POSIXct.Rd
to reflect your changes?
If you want help with this feel free to contact me off the list; when
you're done, you can send me the files and I'll review and commit the
changes.
Duncan Murdoch
[EMAIL PROTECTED] wrote:
Full_Name: Gavin Simpson
Version: 2.1.0-patched (1-Jun-2005)
OS: Linux (Fedora Core 3)
Submission from: (NULL) (128.40.32.76)
axis.Date() insists on labelling tick marks. It could be made more flexible by
allowing the user to specify if they want the ticks to be labelled, for
example,
to add un-labelled minor ticks for months, added to a plot with years
labelled. The user can not define labels = in the ... in the call to
axis.Date() as axis.Date() calls axis() with labels = labels explicitly,
resulting in:
Error in axis(side, at = z, labels = labels, ...) :
formal argument labels matched by multiple actual arguments
if you try.
One way round this would be to add labels as a named argument to axis.Date()
and
to allow labels to be NULL (missing), TRUE or FALSE. A first attempt at this
is
shown below:
axis.Date2 - function (side, x, at, format, labels, ...)
{
mat - missing(at)
if (!mat)
x - as.Date(at)
else x - as.Date(x)
range - par(usr)[if (side%%2)
1:2
else 3:4]
range[1] - ceiling(range[1])
range[2] - floor(range[2])
d - range[2] - range[1]
z - c(range, x[is.finite(x)])
class(z) - Date
if (d 7)
if (missing(format))
format - %a
if (d 100) {
z - structure(pretty(z), class = Date)
if (missing(format))
format - %b %d
}
else if (d 1.1 * 365) {
zz - as.POSIXlt(z)
zz$mday - 1
zz$mon - pretty(zz$mon)
m - length(zz$mon)
m - rep.int(zz$year[1], m)
zz$year - c(m, m + 1)
z - .Internal(POSIXlt2Date(zz))
if (missing(format))
format - %b
}
else {
zz - as.POSIXlt(z)
zz$mday - 1
zz$mon - 0
zz$year - pretty(zz$year)
z - .Internal(POSIXlt2Date(zz))
if (missing(format))
format - %Y
}
if (!mat)
z - x[is.finite(x)]
z - z[z = range[1] z = range[2]]
z - sort(unique(z))
# if labels is missing or TRUE generate labels for ticks
if (missing(labels) || labels == TRUE)
labels - format.Date(z, format = format)
# else rep to suppress labelling
else labels - rep(, length(z))
axis(side, at = z, labels = labels, ...)
}
An example of using this with the Date example from ?plot.Date :
random.dates - as.Date(2001/1/1) + 70*sort(runif(100))
plot(random.dates, 1:100, xaxt=n)
axis.Date2(1, at=seq(as.Date(2001/1/1), max(random.dates)+6, weeks))
axis.Date2(1, at=seq(as.Date(2001/1/1), max(random.dates)+6, days),
labels = FALSE, tcl = -0.2)
The function should perhaps enforce NULL/TRUE/FALSE for labels, or could be
enhanced to allow labels = explicitly or to allow user defined vector for
labels that is of length(at).
Thanks,
Gavin
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: more flexible handling of tick labels in axis.Date (PR#7914)
[EMAIL PROTECTED] wrote: I think allowing the user to change the labels is a good idea... ... If you want help with this feel free to contact me off the list; when you're done, you can send me the files and I'll review and commit the changes. Gavin was very fast with this, and his changes are now committed to R-devel (which will become version 2.2.0). Thanks! Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dotcode typo?
Huntsinger, Reid wrote:
Sorry, I was looking at 2.0.1 when I meant to be looking at 2.1.0. The line
numbers for the latter are 161-179 and line 164 is the one with what I think
is a typo.
Reid Huntsinger
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Huntsinger, Reid
Sent: Thursday, June 02, 2005 12:33 PM
To: r-devel@stat.math.ethz.ch
Subject: [Rd] dotcode typo?
I ran across the following in the R-2.0.1 source, src/main/dotcode.c, in the
function resolveNativeRoutine(), lines 146-163. Line 152 looks like a typo:
here are lines 149-155
if(!*fun) {
if(dll.type != FILENAME) {
*fun = R_FindNativeSymbolFromDLL(buf, dll, symbol);
if(!fun) {
errorcall(call, cannot resolve native routine);
}
}
and I think the if(!fun) should be if(!*fun).
I think you're right about the typo.
In the current code, !fun is known to be false, so the cannot resolve
native routine error message is not even compiled in. Putting in !*fun
means that
.C(foo)
produces cannot resolve native routine, rather than function name not
in load table from the test a few lines down.
I'll commit this change after testing, but I hope Duncan TL has time to
look at it and make sure the logic is okay.
Duncan Murdoch
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dotcode typo? (PR#7917)
Duncan Murdoch wrote:
Huntsinger, Reid wrote:
Sorry, I was looking at 2.0.1 when I meant to be looking at 2.1.0. The line
numbers for the latter are 161-179 and line 164 is the one with what I think
is a typo.
Reid Huntsinger
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Huntsinger, Reid
Sent: Thursday, June 02, 2005 12:33 PM
To: r-devel@stat.math.ethz.ch
Subject: [Rd] dotcode typo?
I ran across the following in the R-2.0.1 source, src/main/dotcode.c, in the
function resolveNativeRoutine(), lines 146-163. Line 152 looks like a typo:
here are lines 149-155
if(!*fun) {
if(dll.type != FILENAME) {
*fun = R_FindNativeSymbolFromDLL(buf, dll, symbol);
if(!fun) {
errorcall(call, cannot resolve native routine);
}
}
and I think the if(!fun) should be if(!*fun).
I think you're right about the typo.
In the current code, !fun is known to be false, so the cannot resolve
native routine error message is not even compiled in. Putting in !*fun
means that
.C(foo)
produces cannot resolve native routine, rather than function name not
in load table from the test a few lines down.
I'll commit this change after testing, but I hope Duncan TL has time to
look at it and make sure the logic is okay.
Whoops, spoke too soon. This definitely breaks the logic, so I won't
commit. With this change the check of demo(lm.glm) in package utils
fails with this error message:
dead - cbind(x, n - x)
summary(glm(dead ~ dose, family = binomial(link = logit)))
Error in .Call(logit_link, mu) : cannot resolve native routine
Execution halted
I'm cc'ing this to R-bugs so we don't forget it, but I'm not going to be
able to fix it down myself.
Duncan Murdoch
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] format.data.frame (was: [R] sink() within a function?)
Jon Stearley wrote: On Jun 1, 2005, at 11:22 AM, Duncan Murdoch wrote: These functions convert their first argument to a vector (or array) of character strings which have a common format (as is done by 'print'), fulfilling 'length(format*(x, *)) == length(x)'. The trimming with 'trim = TRUE' is useful when the strings are to be used for plot 'axis' annotation. i saw this but class(x)# [1] data.frame y-format(x) class(y)# [1] data.frame confused me, let alone y-as.character(format(x)). i'm still an R newbie... I'll try to make it clearer. I think you've got a right to be confused, newbie or not. format.data.frame() doesn't seem to follow the documentation, either before or after my change to the docs. The result of format(x) is not a vector or array or even a data.frame of character strings, it's a data.frame of factors. I'm not sure this is a reasonable thing to do. Does anyone else have an opinion on this? My initial feeling is that format() on a data.frame should return a data.frame of character vectors, it shouldn't convert them to factors. One should be able to expect that format(x)[1,1] gives a character value, rather than the underlying factor encoding as it does in this example: x - data.frame(a=rnorm(5), b=rnorm(5)) y - format(x, digits=3) y a b 1 -1.007 -0.525 2 -0.570 1.128 3 0.162 1.729 4 -1.642 -0.485 5 0.381 0.621 cat(y[1,1],\n) 2 Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Windows/7706 (PR#7889)
James W. MacDonald wrote: Philippe Grosjean wrote: According to the link you cite (http://r-bugs.biostat.ku.dk/cgi-bin/R/Windows?id=7706), it seems it is related to an AMD Athlon processor. Mine is an Intel Pentium IV HT 3.0Ghz processor, which could explain, why I cannot reproduce this bug. I don't think it is AMD specific, because I can reproduce this bug using R-2.1.0 patched on a P4 HT processor. I get the same result as Andy using both png(foo.png) plot(1:10, main=foo) dev.off() and plot(1:10, main=foo) savePlot(foo,png) Best, Jim platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status Patched major2 minor1.0 year 2005 month05 day 14 I think this is likely related to bug 7860, which I fixed right around May 14. Does your CHANGES file include these lines: For some operations on windows() and related devices the first text drawn could be improperly sized. (PR#7860). If not, please download a newer copy of R-patched, and see if you can still reproduce the bug. I can't reproduce it in a recent build. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Windows/7706 (PR#7889)
James W. MacDonald wrote: Philippe Grosjean wrote: According to the link you cite (http://r-bugs.biostat.ku.dk/cgi-bin/R/Windows?id=7706), it seems it is related to an AMD Athlon processor. Mine is an Intel Pentium IV HT 3.0Ghz processor, which could explain, why I cannot reproduce this bug. I don't think it is AMD specific, because I can reproduce this bug using R-2.1.0 patched on a P4 HT processor. I get the same result as Andy using both png(foo.png) plot(1:10, main=foo) dev.off() and plot(1:10, main=foo) savePlot(foo,png) Best, Jim platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status Patched major2 minor1.0 year 2005 month05 day 14 I think this is likely related to bug 7860, which I fixed right around May 14. Does your CHANGES file include these lines: For some operations on windows() and related devices the first text drawn could be improperly sized. (PR#7860). If not, please download a newer copy of R-patched, and see if you can still reproduce the bug. I can't reproduce it in a recent build. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Getting ... without evaluating it?
I'd like a function to get an unevaluated copy of its argument list,
including ... . That is, I'd like
f - function(...) {
args - what goes here??
args
}
when called as
f(a = 1+1, b = foo)
to return something like list(a = quote(1+1), b = quote(foo)). If I use
args - list(...) then it tries to evaluate the arguments and dies
(because foo doesn't exist). If I use args - substitute(...) then it
gives just 1+1, it doesn't keep the names or give the whole list.
Is this possible?
Duncan Murdoch
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Getting ... without evaluating it?
Prof Brian Ripley wrote:
On Thu, 19 May 2005, Duncan Murdoch wrote:
I'd like a function to get an unevaluated copy of its argument list,
including ... . That is, I'd like
f - function(...) {
args - what goes here??
args
}
when called as
f(a = 1+1, b = foo)
to return something like list(a = quote(1+1), b = quote(foo)). If I use args
- list(...) then it tries to evaluate the arguments and dies (because foo
doesn't exist). If I use args - substitute(...) then it gives just 1+1, it
doesn't keep the names or give the whole list.
f - function(...) as.list(match.call())[-1]
f(a = 1+1, b = foo)
$a
1 + 1
$b
foo
(which is what list(a = quote(1+1), b = quote(foo)) prints as).
Thanks!
Duncan Murdoch
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] locator() (PR#7873)
[EMAIL PROTECTED] wrote: Full_Name: Sascha Frydman Version: 2.1.0 OS: Windows XP Submission from: (NULL) (147.66.131.10) when Esc is pressed while a plot with locator running has the focus, R crashes. eg. plot(1) locator(1) I am running in SDI mode I see this too. I'll track it down. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] locator() (PR#7873)
[EMAIL PROTECTED] wrote: Full_Name: Sascha Frydman Version: 2.1.0 OS: Windows XP Submission from: (NULL) (147.66.131.10) when Esc is pressed while a plot with locator running has the focus, R crashes. eg. plot(1) locator(1) I am running in SDI mode Thanks for the report. This is fixed now in the patched version. It should show up in the snapshot builds on CRAN by tomorrow. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with limmaGUI (PR#7877)
[EMAIL PROTECTED] wrote: Full_Name: Edoardo Giacopuzzi Version: 2.0.1 OS: Windows XP Home Submission from: (NULL) (80.181.65.157) I have some problem with this new version of R GUI. I've used limmaGUI package with an older version of R and it works perfectlly, but now with the last version R 2.0.1.0 two error boxs appear every time I try to launch this package: 1. Error in list.files(path, pattern, all.files, full.names, recursive): regular expressione 'pattern' not valid 2. Error in try(expr, TRUE): oggetto source.files not found The package correctly load the grapich interface anyway, but I've experimented some problems when I try to load my .gpr files for analysis: the program often crash! You should report problems with contributed packages to the maintainer. Most often they are caused by incompatibilities with something new in R. limmaGUI isn't a package on CRAN, so that's what I'd expect in this case. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in axis labels (PR#7860)
This is fixed now, in R-patched and R-devel. Duncan Murdoch [EMAIL PROTECTED] wrote: Bob O'hara wrote: I'm a bit reluctant to call anything a bug: I know it's usually my incompetence instead. In this case, I can't see what else it is, although it may be a bug in Windows. The problem comes from trying to create a .png of a figure in Windows XP, with R2.1.0. On the screen it looks OK, but in the .png the text for the x label is smaller than for the y label. The problem seems to be created by using axes=F in plot(). Here's some code to demonstrate the problem: XX=1:5; YY=1:5 png(thing.png) par(mfrow=c(2,1)) plot(XX, YY, axes=F, xlab=X label, ylab=Y label) plot(XX, YY, xlab=X label, ylab=Y label) dev.off() I get a similar problem with bmp() and jpeg(), but not postscript() or pdf(). If I draw the figure in the window in R and then save it as a .png from the menu, the png looks fine. Everything works fine in R1.5.1 (I know, I know!) on Debian Linux, which is why I'm reporting this as a Windows problem. I see the problem in the first figure, and it's still there in a recent r-devel build. My test was also on Windows. Since png() uses the Windows graphics driver, it does look like an R bug in the Windows graphics driver, but I'd like to hear from someone on a different platform... Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] PR$7706, png device plot on athlon 64 processor
A later bug report (#7860) had to do with inappropriate sizing of the first text drawn on a png() device, and I've now fixed the bug that caused that. Could you please check whether you still see your bug on today's build? It will be available on CRAN tomorrow (May 15), in http://cran.r-project.org/bin/windows/base/rpatched.html Thanks! Duncan Murdoch From: [EMAIL PROTECTED] Subject: png device plot on athlon 64 processor Date: Fri, 25 Feb 2005 15:52:40 +0100 (CET) Full_Name: Emiel Ver Loren van Themaat Version: 2.0.1 OS: windows XP Submission from: (NULL) (145.117.31.248) On our computers, which have windows xp sp2 installed and have a 64 bit amd/athlon processor, the following simple code png(test.png) plot(1:10,main=hello) dev.off() results in a plot in which the main title is not visible at all. For 32-bit computers with XP sp2 this bug does not occur. Hopefully this bug can be fixed. (may be the png library is not up to date) __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in axis labels (PR#7860)
Bob O'hara wrote: I'm a bit reluctant to call anything a bug: I know it's usually my incompetence instead. In this case, I can't see what else it is, although it may be a bug in Windows. The problem comes from trying to create a .png of a figure in Windows XP, with R2.1.0. On the screen it looks OK, but in the .png the text for the x label is smaller than for the y label. The problem seems to be created by using axes=F in plot(). Here's some code to demonstrate the problem: XX=1:5; YY=1:5 png(thing.png) par(mfrow=c(2,1)) plot(XX, YY, axes=F, xlab=X label, ylab=Y label) plot(XX, YY, xlab=X label, ylab=Y label) dev.off() I get a similar problem with bmp() and jpeg(), but not postscript() or pdf(). If I draw the figure in the window in R and then save it as a .png from the menu, the png looks fine. Everything works fine in R1.5.1 (I know, I know!) on Debian Linux, which is why I'm reporting this as a Windows problem. I see the problem in the first figure, and it's still there in a recent r-devel build. My test was also on Windows. Since png() uses the Windows graphics driver, it does look like an R bug in the Windows graphics driver, but I'd like to hear from someone on a different platform... Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug in modulus operator %% (PR#7852)
[EMAIL PROTECTED] wrote: Yes, you are correct. I had only checked one of my platforms. Linux works as you suggest. But for me on Windows,=20 Certainly looks like a bug on Windows to me. I'm going offline for a day very soon now, but I'll try to remember to look into it. Duncan Murdoch x - 1 y - 0.2 x %/% y [1] 5 ## I get a 4 in Linux version _ =20 platform i386-pc-mingw32 arch i386 =20 os mingw32 =20 system i386, mingw32 =20 status =20 major2 =20 minor1.0 =20 year 2005 =20 month04=20 day 18=20 language R =20 -Original Message- From: Peter Dalgaard [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 11, 2005 4:14 PM To: McGehee, Robert Cc: [EMAIL PROTECTED]; Peter Dalgaard; [EMAIL PROTECTED]; [EMAIL PROTECTED]; r-devel@stat.math.ethz.ch Subject: Re: [Rd] bug in modulus operator %% (PR#7852) McGehee, Robert [EMAIL PROTECTED] writes: Yes, but from ?%%: It is guaranteed that 'x =3D=3D (x %% y) + y * (x %/% y)' (up to = rounding error) ... =20 (R 2.1.0) x - 1 y - 0.2 x %% y [1] 0.2 (x %% y) + y * (x %/% y) [1] 1.2 =20 Certainly 1 does not equal 1.2 as the documentation would suggest, and these seem like large enough numbers to not be effected by rounding errors or lack of precision. Now that looks a bit odd, but it isn't universal: x - 1 y - 0.2 x %% y [1] 0.2 x %/% y [1] 4 (x %% y) + y * (x %/% y) [1] 1 So what platform was that happening on? --=20 O__ Peter Dalgaard Blegdamsvej 3 =20 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N =20 (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] big bug with edit(data.frame(a)) (PR#7846)
[EMAIL PROTECTED] wrote:
Full_Name: RICHARD Maxime
Version: R2.1.0
OS: Windows XP
Submission from: (NULL) (195.25.74.233)
I creat a file datafile2.txt with that
sujet groupe score
s1 exp 3
s2 exp 4
s3 exp 6
s4 cont7
s5 cont8
and i write
a - read.table('datafile2.txt',header=T)
a
scores - edit(data.frame(a))
After that i try to move with my third click on my mouse and
big bug and i'm ejected
I think this has been fixed. Could you please try the R-patched
version, available on CRAN mirrors, to confirm?
Duncan Murdoch
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to understand packages, namespaces, environments
Prof Brian Ripley wrote: On Mon, 9 May 2005 [EMAIL PROTECTED] wrote: [Alexander Stoddard] Subject: Re: [Rd] How to understand packages, namespaces, environments Does saying the following load package 'foo' into its own environment ? library(foo) [Duncan Murdoch] This loads some of the (name, object) pairs from the package into two environments: the public one the user can see, and the namespace one that the code in the package can see. They're related, you don't get two copies of the objects. That's interesting-- I thought there really were two copies. In my debug package, I've taken the approach of changing both copies. Is one of the copies a master, and the other one something like an activeBinding? Can I get away with changing just one of them? Duncan is wrong here (or misquoted). Wrong, not misquoted. Sorry about that. Thanks for the correct description. Duncan Murdoch Loading a package with a namespace loads all the objects in the package (possibly as promises) into the namespace environment. Then some are copied (using assign) to the package environment. Since like most R copies this is really copy-on-change you do not get a real copy (nor force a promise) until use. See ?fixInNamespace for explicit statements about this. There can be more than two copies, since importing also `copies', as does S3 method registration (the latter does sometimes force promises). __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to understand packages, namespaces, environments
Alexander Stoddard wrote:
I would be very glad of pointers to information on how the concepts of
packages, namespaces and environments are interrelated in R.
I don't think that documentation exists yet, but I did update the
documentation on environments for 2.1.0. Look in the section (2.1.10 I
think) on Environment Objects in the R language definition manual.
Basically environments are things where you can ask to look up names and
R will return R objects to you. They're a bit more complicated than
just a list of (name, object) pairs, but can (almost) be used as that
(and I'm hoping will be able to be used that way in 2.2.0, but that
remains to be seen).
I am trying to get a handle on this both so I can delve further into
understanding other people's code and so I can organize my own in a more
coherent manner.
From my reading about environments it seems they function as what I
would intuitively call namespaces. However, the documentation for the
'library' function implies that namespace has a specific meaning in R
that I have so far failed to grasp. What is that meaning (or where
should I look to read up on it) ?
A namespace is a more abstract concept, which happens to be implemented
in R using environments. Exactly how is a bit of a mystery to me, I'm
afraid! However, the basic idea is that a namespace defines a fixed set
of meanings for names, which the code in a package can assume won't
change. It may also hide some names from outsiders.
I can think of the following more specific questions. Perhaps they may
most usefully serve to reveal my misconceptions, so corrections would be
very helpful.
Does saying the following load package 'foo' into its own environment ?
library(foo)
This loads some of the (name, object) pairs from the package into two
environments: the public one the user can see, and the namespace one
that the code in the package can see. They're related, you don't get
two copies of the objects.
Do environments have names?
They are R objects, so some of them have names, and some of them are
anonymous parts of other objects.
Of what does the list returned by search() actually consist? Is it a
list of environments, a list that may include environments, or something
else?
It's a list of strings that can be used to get corresponding
environments. You don't get the actual environments.
What is actually designated by a character vector of form package:foo?
That string is used by the as.environment() function to go through the
search list and obtain the environment. For instance, you can do
x - as.environment(package:foo)
and x will be a reference to the environment. Then
ls(x)
will list all the objects there, get('bar', envir=x) will extract the
object named 'bar' from it, etc.
In what ways can I use the character vector package:foo when
interacting with R?
I can't think of any other uses than in as.environment(), but there
might be some, or some automatic calls to it. I'd have to check the man
pages to be sure, but perhaps some functions that accept envir=x type
arguments would automatically call as.environment on x first.
Many thanks,
Alex Stoddard
P.S. It took me a long time of flailing about to discover the 'search'
function. Perhaps it could be included in the See Also section of the
help for 'ls'.
That's a good suggestion. Could you do me a favour, and as you're
reading up on this stuff identify a whole list of deficiencies in the
documentation and suggested fixes for them? Making a change to a man
page has a certain fixed overhead (making sure there are no syntax
errors, committing, possibly porting the change to the patch branch), so
batching them is efficient.
Duncan Murdoch
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] documenation for arrows() is backwards (PR#7839)
Peter Dalgaard wrote: [EMAIL PROTECTED] writes: Full_Name: Michael Hoffman Version: 2.1.0 OS: Linux (Fedora Core 3, kernel 2.6.11-1.14_FC3) Submission from: (NULL) (193.62.199.8) help(arrows) says: arrows(x0, y0, x1, y1, length = 0.25, angle = 30, code = 2, col = par(fg), lty = NULL, lwd = par(lwd), xpd = NULL) ... If 'code=2' an arrowhead is drawn at '(x0[i],y0[i])' and if 'code=1' an arrowhead is drawn at '(x1[i],y1[i])'. If 'code=3' a head is drawn at both ends of the arrow. Unless 'length = 0', when no head is drawn. If you do: plot(c(-1, 1), c(-1, 1), col=0) arrows(x0=0, y0=0, x1=0, y1=1, code=2) it is pretty clear that the arrowhead is drawn at x1, y1 with code=2. If you switch to code=1, the arrowhead is drawn at x0, y0. Either the documentation or the function is incorrect. One way to decide is to compare with Splus. Now that doesn't have a 'code' argument and the arguments are named x1,y1,x2,y2 (I wonder why R wanted to be different here?), but they do put the arrowheads at the *to* end, which does seem to be the sensible thing to do. Arguably, using 'code=2' as the default is a bit weird, An argument for the current encoding is that it encodes arrowhead end in the bits of code: 00 = no arrowhead, 01 = arrowhead at origin, 10 = arrowhead at destination, 11 = arrowhead at both. but changing it could be quite painful. I.e., we should fix the docs. Yes, definitely. BTW, the docs also might say that code=0 makes arrows behave like segments(). It is also a bit strange that the code argument isn't vectorized, which might have been useful. Yes, that would be a reasonable change. Duncan __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] documenation for arrows() is backwards (PR#7839)
Peter Dalgaard wrote: [EMAIL PROTECTED] writes: Full_Name: Michael Hoffman Version: 2.1.0 OS: Linux (Fedora Core 3, kernel 2.6.11-1.14_FC3) Submission from: (NULL) (193.62.199.8) help(arrows) says: arrows(x0, y0, x1, y1, length = 0.25, angle = 30, code = 2, col = par(fg), lty = NULL, lwd = par(lwd), xpd = NULL) ... If 'code=2' an arrowhead is drawn at '(x0[i],y0[i])' and if 'code=1' an arrowhead is drawn at '(x1[i],y1[i])'. If 'code=3' a head is drawn at both ends of the arrow. Unless 'length = 0', when no head is drawn. If you do: plot(c(-1, 1), c(-1, 1), col=0) arrows(x0=0, y0=0, x1=0, y1=1, code=2) it is pretty clear that the arrowhead is drawn at x1, y1 with code=2. If you switch to code=1, the arrowhead is drawn at x0, y0. Either the documentation or the function is incorrect. One way to decide is to compare with Splus. Now that doesn't have a 'code' argument and the arguments are named x1,y1,x2,y2 (I wonder why R wanted to be different here?), but they do put the arrowheads at the *to* end, which does seem to be the sensible thing to do. Arguably, using 'code=2' as the default is a bit weird, An argument for the current encoding is that it encodes arrowhead end in the bits of code: 00 = no arrowhead, 01 = arrowhead at origin, 10 = arrowhead at destination, 11 = arrowhead at both. but changing it could be quite painful. I.e., we should fix the docs. Yes, definitely. BTW, the docs also might say that code=0 makes arrows behave like segments(). It is also a bit strange that the code argument isn't vectorized, which might have been useful. Yes, that would be a reasonable change. Duncan __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cost of method dispatching: was: when can we expect Prof Tierney's compiled R?
Vadim Ogranovich wrote: -Original Message- From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 27, 2005 1:13 AM To: Vadim Ogranovich Cc: Luke Tierney; r-devel@stat.math.ethz.ch Subject: Re: [Rd] RE: [R] when can we expect Prof Tierney's compiled R? On Tue, 26 Apr 2005, Vadim Ogranovich wrote: ... The arithmetic shows that x[i]- is still the bottleneck. I suspect that this is due to a very involved dispatching/search for the appropriate function on the C level. There might be significant gain if loops somehow cached the result of the initial dispatching. This is what you probably referred to as additional improvements in the engine itself. I'd be surprised if dispatching were the issue: have you (C-level) profiled to find out? Please do so: these statements do tend to get perpetuated as fact. For the record, I didn't profile the dispatching, so it is only my guess and is not verified by C-level profiling. The guess is based on reading the code and on the following timing on R level: n = 1e6; iA = seq(2,n); x = double(n); f1 - function(x, iA) for (i in iA) x[i] = c(1.0) f2 - function(x, iA) for (i in iA) x = c(1.0) last.gc.time = gc.time(TRUE) system.time(f1(x, iA), gcFirst=TRUE) [1] 3.50 0.01 3.52 0.00 0.00 print(gc.time() - last.gc.time); last.gc.time = gc.time() [1] 1.25 0.82 1.24 0.00 0.00 system.time(f2(x, iA), gcFirst=TRUE) [1] 0.76 0.00 0.77 0.00 0.00 print(gc.time() - last.gc.time); last.gc.time = gc.time() [1] 0.25 0.18 0.23 0.00 0.00 f1 and f2 are identical except that the first assigns to an element in the vector (and thus goes through the method dispatching). Originally I had thought that the number of allocations in f1 and in f2 must be the same, the c(1.0) call. But gc.time() shows that the number of allocations in f1 is indeed, as Prof. Ripley suggests, bigger than in f2. It is not clear to me where these extra allocations come from and whether they are necessary. All x[i] = c(1.0) needs to do is to create a new vector c(1.0), which is a step common between f1 and f2, and then copy from the vector into x[i]. However even after discounting for gc.time the assignment to x[i] seems to be heavy. You cannot cache the result, as [- can change the class of x, as could other operations done by the rhs (e.g. if it were x[i] - g(x, i) the function g could change its argument). Yes, however R may try to use the last method found and only when that fails go for the full dispatch. This should give a lot of gain in a typical case when the vars. types do not change. There are probably efficiency improvements available, but they need to be done very carefully. For example, the default method of [- could be called in one step, and as a side effect create a more specific method. So for the second call we should call the more specific one, but the default call will still be valid in the sense that the arguments match the signature (S4) or the class matches the name (S3), but not in the sense that it is the method that should be called. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Re: [R] strange behaviour of importFrom directive in name space
This is really an R-devel question, and I've moved it there. Florian Hahne wrote: Dear listers, After activating the name space for my bioconductor package (prada) I successfully ran R CMD check. However when loading the package in R and running the examples the imported function brewer.pal from package RColorBrewer is not found. I can directly call brewer.pal from the RColorBrewer name space typing RColorBrewer::brewer.pal, but it is not imported into my prada name space. When I attach RColorBrewer, the example runs fine. For several other function from different packages the import works without problems. I'm quite puzzled how this import can work with R CMD check but not when attaching the package in a regular R session. And if the importFrom directive was corrupted, shouldn't there be an error message? This is not realy a problem, since I can load RColorBrewer by putting it into the dependent field in my DESCRIPTION file as I did before, but none the less I wanted to mention this strange behaviour. Could it be a bug? Could you be more specific about the bug? Which example fails? Is it run by the R CMD check tests? Generally, I wouldn't expect importFrom to be sufficient to make an example using the import work, either during Rcmd CHECK or in the console. It makes the import available from within your package, but examples are run in the global environment. Duncan Murdoch Regards, Florian Here is my NAMESPACE file: export(analysePlate, as.all, barploterrbar, combineFrames, csApply, ddCt, densCols, eListWrite, fitNorm2, getPradaPar, histStack, plotNorm2, plotPlate, readCytoSet, readFCS, readSDM, removeCensored, setPradaPars, smoothScatter, thresholds) importFrom(KernSmooth, bkde2D) importFrom(RColorBrewer, brewer.pal) importFrom(utils, getFromNamespace, assignInNamespace) importFrom(MASS, cov.rob) S3method($, cytoFrame) exportClasses(cytoFrame, cytoSet) exportMethods(colnames, colnames-, description, description-, exprs, exprs-, length, [, [[, [[-, pData, phenoData, phenoData-, show) System: R 2.1.0 on Suse9.2 Linux box __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Speeding up library loading
Ali - wrote: Lazy loading just converts an object into a small instruction to load the object. If the object was already small, there's no advantage to that. It's mainly designed to avoid memory use (some rarely used objects can be gigantic). From a design point of view the reason is that this isn't the problem lazy loading is trying to solve. We didn't have a problem with packages that have huge number of small objects, but we did have a problem with packages that had a moderate number of moderately large objects. In addition, trying to optimize performance is not usually a good idea unless you can measure the performance of different implementations on real applications, and we didn't have applications like that. Assume 100 C++ classes each class having 100 member functions. After wrapping these classes into R, if the wrapping design is class-oriented we should have like 100 objects. At the same time, if the wrapping design is function-oriented we have like 10`000 objects which are too lazy for lazy loading. I have tried wrapping exactly the same classes by R.oo based on S3 and the outcome package was much faster in both installation and loading. The package went slow once I tried it with S4. I guess R.oo makes the package more class-oriented while S4 object-orientation is really function-oriented causing all this friction in installation and loading. Is there any way to ask R to lazy-load each object as a 'bundle of S4 methods with the same class'? I don't think so. There are ways to load a bundle of objects all at once (put them in an environment, attach the environment), but S4 methods aren't self-contained, they need to be registered with the system. You could probably write a function to load them and register them all at once, but I don't think it exists now. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Speeding up library loading
Ali - wrote: Assume 100 C++ classes each class having 100 member functions. After wrapping these classes into R, if the wrapping design is class-oriented we should have like 100 objects. At the same time, if the wrapping design is function-oriented we have like 10`000 objects which are too lazy for lazy loading. I have tried wrapping exactly the same classes by R.oo based on S3 and the outcome package was much faster in both installation and loading. The package went slow once I tried it with S4. I guess R.oo makes the package more class-oriented while S4 object-orientation is really function-oriented causing all this friction in installation and loading. Is there any way to ask R to lazy-load each object as a 'bundle of S4 methods with the same class'? I don't think so. There are ways to load a bundle of objects all at once (put them in an environment, attach the environment), but S4 methods aren't self-contained, they need to be registered with the system. You could probably write a function to load them and register them all at once, but I don't think it exists now. Duncan Murdoch (1) What is the difference between loading and registering objects in R? Loading just creates the object. Registering it is what setMethod() and such calls do. They allow the system to know that it should call that function in response to a call to the generic with a certain signature, and so on. (2) You are talking about 'loading and registering at once'. Isn't this 'at once' the cause of slow loading? I haven't done any profiling, but I would guess the registering is the slow part. (3) Doesn't having many environments mean lose of efficiency again? Yes, I'd guess that looking things up in a chain of 100 environments is slower than looking them up in one gigantic environment. Again, I haven't done any profiling, but I'd guess it would come close to being 100 times worse, i.e. in practice order N time instead of order 1 time (but I'm sure these aren't the theoretical limits). But you were asking about delayed loading, so I was assuming that in most cases you would only load a small subset of those 100 environments. I haven't tried any big problems like yours, but I would be willing to guess that registering is slower than O(N), so cutting down on the number of things you register will give a big improvement on loading speed. But you do have to remember the two pieces of advice you've been given in this thread: - nobody else has written a package with ten thousand methods, so you're likely to find things out that nobody else knows about. - The S4 object model is quite different from that of C++, so it probably doesn't make sense to have a direct correspondence between C++ classes and methods and R classes and methods. There are probably much more efficient ways to get access to the functionality of your C++ library. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Speeding up library loading
Ali - wrote: Is it possible to break the package into multiple parts, perhaps like a bundle? Then you could only load the parts that you need at any particular time. It could be done, but the question is, what if one of the packages in the bundle depends on all of the rest? And the bigger question is, why lazy loading is not efficient when it comes to many small functions? Lazy loading just converts an object into a small instruction to load the object. If the object was already small, there's no advantage to that. It's mainly designed to avoid memory use (some rarely used objects can be gigantic). Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Objects in R
the
internal state of the object in unexpected ways; only the object's own
internal methods are allowed to access its state. Each object exposes an
interface that specifies how other objects may interact with it.
Neither of these properties holds in S4.
Duncan Murdoch
But the hindrances faced by our friend Ali are
common, and even in packages maintained by experienced
R developers, S4 is implemented shall we say curiously
as per the specs.
Clearly OOP and R.oo are not the final answer. But
some serious discussion about why packages like R.oo
which layer onto the standard functional R are
inappropriate is in order.
It would be great to see R emerge from its niche
audience. I believe that would aid statisticians and
programmers. However, a little bit more transparency
and something beyond a categorical we just don't like
that way of doing things would go a long way towards
growing the base community of R.
Cheers,
Nathan Whitehouse
Formerly of Baylor College of Medicine.
Ali, maybe we R-core members are not decent enough.
But we strongly believe that we don't want to advocate
yet
another object system additionally to the S3 and S4
one,
and several of us have given talks and classes, even
written
books on how to do decent object oriented
programming
`just' with the S3 and/or S4 object system.
No need of additional oo in our eyes.
Your main problem is that you assume what oo means
{which may
well be true} but *additionally* you also assume that
OO has to
be done in the same way you know it from Python, C++,
or Java..
Since you are new, please try to learn the S4 way,
where methods belong to (generic) functions more than
to classes in some way, particularly if you compare
with other
OO systems where methods belong entirely to classes.
This is NOT true for R (and S-plus) and we don't want
this to
change {and yes, we do know about C++, Python,
Java,... and
their way to do OO}.
Please also read in more details the good advice given
by Tony
Plate and Sean Davis.
Martin Maechler,
ETH Zurich
Nathan Whitehouse
[EMAIL PROTECTED]
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
---
Byron Ellis ([EMAIL PROTECTED])
Oook -- The Librarian
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Objects in R
Seth Falcon wrote: Duncan Murdoch [EMAIL PROTECTED] writes: What S4 is missing is encapsulation. Wikipedia's article on object-oriented programming gives a good definition: Encapsulation - Ensures that users of an object cannot change the internal state of the object in unexpected ways; only the object's own internal methods are allowed to access its state. Each object exposes an interface that specifies how other objects may interact with it. Neither of these properties holds in S4. I don't like the definition of encapsulation in the Wikipedia. If nothing else, I think the second part about objects exposing an interface specifying how to interact with them should come first --- and S4 provides that. I agree the second part is more important. If you have the second part, you can handle the first part by convention, e.g. by exposing ways to do things with the internals through a public interface, and adopting the convention that you should never go in and meddle directly. But I don't think S4 does the second part. S4 fixes the representation of an object, but it doesn't specify how other objects should interact with it. That's done in other languages through the methods of the class, but S4 classes don't have any methods, S4 generics have methods. Generics can be created independently of the class, and the author of the class will not know to create methods for them. In my experience, the ability to create obvious interfaces to classes is the important part of encapsulation. Python's object system, for example, does not (easily) provide protections against abuse, but other than some initial misgivings, I've not missed it. I don't know Python, but a quick look at the reference manual online makes it look class-oriented like Java rather than generic-oriented like S4. I think this would be relatively easy to add to R. I'd do it as follows: Put the class methods in an environment, and put the class slots in a different one. There would only be one method environment for the class, but a separate one for each instance. Set the methods environment to be the parent of each instance's slot environment. Single inheritance could work by setting the ancestor's method environment as the parent of the method environment, but it's harder to handle multiple inheritance. However, since there's only one copy of the method environment needed, making copies of the methods for each declared class wouldn't be a big deal. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tclServiceMode: stop Tcl/Tk from updating
In Windows, Tcl/Tk programs running under the tcltk package can update too frequently: for exmaple, we might go through a long sequence of operations to construct a complex display, and in Windows each addition will be shown separately. To work around this, I've added a function tclServiceMode which serves as an R interface to the Tcl_SetServiceMode function in the TCL API. Calling tclServiceMode(on = FALSE) will stop Tcl/Tk from responding to any events (redraws in particular) until tclServiceMode(on = TRUE) is called. As far as I know, events are queued, not lost, when handling is turned off. So far this function is only in R-devel, but I'll commit it to R-patched the next chance I get. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in Version 2010 (PR#7807)
[EMAIL PROTECTED] wrote: Dr. Michael Breuer 22.04.05 Ökologiezentrum der Universität Kiel Olshausenstraße 75 24118 Kiel Dear Ladies and Sirs, After updating the R-Windows-program (binary) by the latest version (2010), the R-Scripts that I want to execute are not shown in the File-Window anymore. In the former version it worked correct. However, if I call a script by command line, it will be found and intepreted. I tried it on two PCs wirh Windows XP Home and Windows XP Professional SP2. This is not enough information to allow us to try to duplicate your error. Tell us where you keep your scripts, how you start R (the starting directory is likely important), and the exact steps you take to try to show your scripts. Without that information your report is too vague to act on. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: hexadecimal constants and decimal points
On Sun, 17 Apr 2005, Jan T. Kim wrote: On Sun, Apr 17, 2005 at 12:38:10PM +0100, Prof Brian Ripley wrote: These are some points stimulated by reading about C history (and related in their implementation). 1) On some platforms as.integer(0xA) [1] 10 but not all (not on Solaris nor Windows). We do not define what is allowed, and rely on the OS's implementation of strtod (yes, not strtol). It seems that glibc does allow hex: C99 mandates it but C89 seems not to allow it. I think that was a mistake, and strtol should have been used. Then C89 does mandate the handling of hex constants and also octal ones. So changing to strtol would change the meaning of as.integer(011). I think interpretation of a leading 0 as a prefix indicating an octal representation should indeed be avoided. People not familiar to C will have a hard time understanding and getting used to this concept, and in addition, it happens way too often that numeric data are provided left- padded with zeros. I agree with this: 011 should be 11, it should not be 9. Proposal: we handle this ourselves and define what values are acceptable, namely for as.integer: [+|-][0-9]+ NA 0[x|X][0-9A-fa-f]+ It can be a somewhat mixed blessing if the string representation of numeric values contain information about their base, in the form of the 0x prefix in this case. The base argument (#3) of C's strtol function can be set to to a base explicitly or to 0, which gives the prefix-based auto-selection behaviour. On the R level, such a base argument (to as.integer) could be included and a default could be set. A lot of this is internal, not at R level. Personally, I would be equally happy with the default being 0 (auto-select) or 10. Considering the perhaps limited spread of familiarity with C's 0x idiom, I somewhat favour a consistent and stubborn decimal behaviour (base defaults to 10), though. Some people already rely on it, and those who don't know about it are unliekly to ever enter what they think is an illegal value, surely? As long as we document it, I think the 0x prefix is fine. We should provide a way to use other bases on input and output. This could be through format specifiers, but it would be enough to have a pair of dedicated functions to do the conversions. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A 'true' R-wrapper for C++ classes
Hello I am trying to wrap some C++ classes into R. (1) Comparing the OOP and methods packages, I have came to this conclusion that OOP works much better for this wrapper -- please correct me if I am wrong. The methods package using a different conceptual model of object-oriented programming than C++ uses, one based on generic functions rather than methods being defined within classes. You should also look at the R.oo package for another way to do what you want. One question is why this useful package (OOP) is not included in the official release of R? There are a lot of useful packages that aren't in R. They can't all be. Another question is why OOP is not on CRAN. This would be because its author (John Chambers) thought Omegahat.org was a better place to put it (assuming you're talking about that OOP). The rest of your message contained a lot of repeated copies of the same text. I didn't read it all, so might have missed something new hidden in there. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RE: A 'true' R-wrapper for C++ classes
Sorry about the mistake in the previous post, here is the corrected version: And I've just added responses to part of it: (3) The above model lacks something like an 'environment' for the pointer to the C++ object to live in it. Assume we create the foo class in R like: obj - foo$new() Now, the following would return an error: obj$fun() and the reason is that the pointer created in the initialize method is lost. (4) The question is how to assign an environment to the pointers. A well described answer, rather than some abstract hints, is well-appreciated. I think you'll have to ask the OOP author this one. Generally R doesn't have pointers, so when a package provides them, it needs to do a lot of low level support for them. Also I am curious to know why there is no standard method for R to wrap C++ classes, something like JNI. I think it would be harder to write such a thing, in that R and C++ are more different than Java and C++ are. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Poblem while build a package (PR#7798)
[EMAIL PROTECTED] wrote: Full_Name: Justin Bem Version: 1.9.1 OS: Windows XP Home Submission from: (NULL) (196.202.235.48) I am a R new user ! I have writed procedure that i wantto transform as a package but with RCMD build packageName [...] I have 'sh' is not a recognized command in the dos promp I have Active Perl 5.8 ! Does I need to have another software or it is a Perl problem ? I hope you will find a solution for me You are missing several tools. Upgrade to R 2.1.0, it has a (hopefully) better description of the process in the R Installation and Administration manual. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dealing with empty actual arguments matched by '...' formals
Tony Plate wrote: I'm trying to write some functions to deal with empty actual arguments that are picked up by '...' formals. Such actual arguments are common (and very useful) in calls to subsetting functions, e.g., x[1:2,]. It seems that R and S-PLUS treat these arguments differently: in S-PLUS list(...) will return a list containing just the non-empty arguments, whereas in R list(...) stops with an error: # In R: f - function(x, ...) list(...) f(1,2) [[1]] [1] 2 f(1,2,) Error in f(1, 2, ) : argument is missing, with no default So it seems that quite different methods must be used in S-PLUS and R to detect and process the arguments of a function that can have empty arguments matched to '...'. Can you give an example where it's useful to do this, i.e. to have a call like f(1,2,)? I've never used that construction as far as I can recall. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] one suggestion for R-admin
Liaw, Andy wrote:
Just one minor point about building bitmap.dll on Windows in
doc/manual/R-admin.texi:
In lines 601-605:
@item
You need @code{libpng} and @code{jpeg} sources (available, e.g., from
@url{http://www.libpng.org}, @url{ftp://ftp.uu.net/graphics/}[png,jpeg].
You will need files @file{libpng-1.2.8.tar.gz} and
@file{jpegsrc.v6b.tar.gz} or later.
and lines 699-707:
The file @[EMAIL PROTECTED]/bin/Rbitmap.dll} is not built automatically:
instructions on how to build it are in the file @file{bitmap/INSTALL}.
If everything is set up in directory @file{bitmap},
@example
make bitmapdll
@end example
@noindent
will work from this directory.
Why not just add the instruction in src/gnuwin32/bitmap/INSTALL into these
places? It seems like unnecessary work to go find the few lines of
instruction in a different file... (Especially in the first part quoted
above: It tells what to get the files, but not where to put them.)
Good suggestion; I've just done it. I think the only reason I didn't do
it before was laziness.
Duncan Murdoch
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] IAB (PR#7788)
[EMAIL PROTECTED] wrote: Full_Name: Doris Söhnlein Version: 1.8.1 OS: XP Submission from: (NULL) (212.204.77.23) It is not possible to save workspace image and the following error messages appear: help.start() updating HTML package listing updating HTML search index Error in file(f.tg, open = w) : unable to open connection In addition: Warning messages: 1: cannot update HTML package index in: make.packages.html(.libPaths()) 2: cannot open file `C:\Programme\R_rw1081/doc/html/search/index.txt' If nothing happens, you should open ` C:\Programme\R_rw1081\doc\html\rwin.html ' yourself q() Error in file(file, wb) : unable to open connection In addition: Warning message: cannot open file `.RDataTmp' Was the installation not correct?' Version 1.8.1 is a couple of years old; please upgrade. In general we don't fix bugs in older versions, and you shouldn't submit bug reports about them. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] patch to add a menu item in Rgui for RSiteSearch
Prof Brian Ripley wrote: On Tue, 12 Apr 2005, Liaw, Andy wrote: Please consider adding the following to the next R release (I understand that it's too late for R-2.1.0). It adds the menu item `Search R Site' in the `Help' menu in Rgui (which calls RSiteSearch() on the input string). Can you or someone else think of a better name? That sounds like it searches www.r-project.org. I think even 'R Sites Search' would be better. Yes, it is too late: we need lead time for the translators these days. (RGui has Chinese, German, Italian and Japanese menus available.) I'd suggest R help online After the release, I think this should go into R-patched. Do we have tools to tell the translators all the new strings that need translating, or should they be explicitly informed about such a thing? Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] patch to add a menu item in Rgui for RSiteSearch
Prof Brian Ripley wrote: On Wed, 13 Apr 2005, Duncan Murdoch wrote: Prof Brian Ripley wrote: On Tue, 12 Apr 2005, Liaw, Andy wrote: Please consider adding the following to the next R release (I understand that it's too late for R-2.1.0). It adds the menu item `Search R Site' in the `Help' menu in Rgui (which calls RSiteSearch() on the input string). Can you or someone else think of a better name? That sounds like it searches www.r-project.org. I think even 'R Sites Search' would be better. Yes, it is too late: we need lead time for the translators these days. (RGui has Chinese, German, Italian and Japanese menus available.) I'd suggest R help online But, it is not 'help online': it is searching docs and past help. That's help in the Windows Help-menu sense, but the important word is online. Some alternatives: R online... (sounds like it runs R online, but maybe the context is enough) Search online... (easily confused with a general Google search) R sites online... In any case, the 2 or 3 words in the menu aren't going to be the only clue to the user: the dialog box should give a line or two describing what will happen when you do the search. Duncan Murdoch After the release, I think this should go into R-patched. Do we have tools to tell the translators all the new strings that need translating, or should they be explicitly informed about such a thing? Yes, msgmerge/msgfmt tells them. The message catalogues change almost daily as people add features. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] patch to add a menu item in Rgui for RSiteSearch
Adaikalavan Ramasamy wrote: While on the subject, may I also suggest that a menu item to search the BioConductor archives be added. Archives : https://stat.ethz.ch/pipermail/bioconductor/ Search-able archives : http://files.protsuggest.org/cgi-bin/biocond.cgi I hope this is not an unreasonable request considering that there is menu item to select repositories to include BioConductor in R-2.1.0beta. I think this would make more sense as an enhancement to search.r-project.org (the site where RSiteSearch sends the search request) than to Rgui. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C Interface to R?
Alexander Schinner wrote: Hi, can somebody tell me, if there is a C or C++ Interface to the R? Reading the documentation, FAQ, CRAN etc. I found nothing. But as i am very new to R, I might have not searched in the right place. Yes, there is. You want to look in the Writing R Extensions manual. The easiest thing is to write C routines to be called from R, but you can also call some R functions or R itself from a C program. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] docu buglet
Kjetil Brinchmann Halvorsen wrote: ?oneway.test contains: |var.equal| a logical variable indicating whether to treat the variances in the samples as equal. If |TRUE|, then a simple F test for the equality of means in a one-way analysis of variance is preformed. If |FALSE|, an approximate method of Welch (1951) is used, which generalizes the commonly known 2-sample Welch test to the case of arbitrarily many samples. I guess preformed should read performed Thanks, I'll fix it. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems with predict.lm: incorrect SE estimate (PR#7772)
On Mon, 4 Apr 2005 18:01:05 +0200 (CEST), [EMAIL PROTECTED] wrote : Full_Name: Marek Ancukiewicz Version: 2.01 OS: Linux Submission from: (NULL) (132.183.12.87) It seems that the the standard error of prediction of the linear regression, caclulated with predict.lm is incorrect. Consider the following example where the standard error is first calculated with predict.lm, then using delta method. and finally, using the formula rms*sqrt(1+1/n+(xp-x0)^2/Sxx). Your formula is incorrect. You've got the formula for the so called prediction error (i.e. the stddev of the difference between the prediction and a new observation) rather than the standard error (i.e. the stddev of the prediction). Duncan Murdoch Marek Ancukiewicz n - 10 x - 1:n y - x y[c(2,4,6)] - y[c(2,4,6)] + 0.1 y[c(3,5,7)] - y[c(3,5,7)] - 0.1 a - lm(y~x) rms - sqrt(sum(a$residuals^2)/(n-2)) s - covmat(a)*rms^2 xp - 3 xm - mean(x) summary(a) Call: lm(formula = y ~ x) Residuals: Min 1Q Median 3Q Max -0.10909 -0.07500 0.01091 0.06955 0.10182 Coefficients: Estimate Std. Error t value Pr(|t|) (Intercept) 0.02 0.058621 0.3410.742 x 0.996364 0.009448 105.463 7.3e-14 *** --- Signif. codes: 0 `***' 0.001 `**' 0.01 `*' 0.05 `.' 0.1 ` ' 1 Residual standard error: 0.08581 on 8 degrees of freedom Multiple R-Squared: 0.9993, Adjusted R-squared: 0.9992 F-statistic: 1.112e+04 on 1 and 8 DF, p-value: 7.3e-14 print(predict(a,new=data.frame(x=xp),se.fit=T)) $fit [1] 3.009091 $se.fit [1] 0.0359752 $df [1] 8 $residual.scale [1] 0.08581163 print(se.delta.method - sqrt(s[1,1]+xp^2*s[2,2]+2*xp*s[1,2] + rms^2)) [1] 0.09304758 print(se.ss.formula - rms*sqrt(1+1/n+(xp-xm)^2/sum((x-xm)^2))) [1] 0.09304758 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] acf segfault (PR#7771)
On Mon, 4 Apr 2005 17:15:29 +0200 (CEST), [EMAIL PROTECTED] wrote : Test case: z - ts(matrix(rnorm(200),10,20), start=c(1961,1)) acf(z,lag.max=1) This segfaults for me. Maybe it shouldn't? Not for me in a recent alpha build on Windows. Could you try it in the latest R-alpha from CRAN? Duncan Murdoch cheers dave --please do not edit the information below-- Version: platform = i386-pc-linux-gnu arch = i386 os = linux-gnu system = i386, linux-gnu status = major = 2 minor = 0.1 year = 2004 month = 11 day = 15 language = R Search Path: .GlobalEnv, package:methods, package:stats, package:graphics, +package:grDevices, package:utils, package:datasets, Autoloads, package:base __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] acf segfault (PR#7771)
David emailed me his dataset, and I get a segfault crash with it. This happens in an R memory allocation routine after the C function acf() in src/library/stats/src/filter.c has returned, so it looks to me as though acf() is writing somewhere it shouldn't. I'll try to track it down... Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] acf segfault (PR#7771)
On Mon, 4 Apr 2005 17:15:29 +0200 (CEST), [EMAIL PROTECTED] wrote : Test case: z - ts(matrix(rnorm(200),10,20), start=c(1961,1)) acf(z,lag.max=1) This segfaults for me. Maybe it shouldn't? This was a bug in the memory allocation in the C code, now fixed. I've committed the fix to the beta and to the 2.0.1 patch version. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error: cannot set length of non-vector
On Sat, 2 Apr 2005 23:50:24 -0600, Charles Geyer [EMAIL PROTECTED] wrote : The subject line says it all. How can I find what Error: cannot set length of non-vector means? RTFS is no help. I can find out of course that it comes from lengthgets, but who called that? Not me! I think the error comes from your second chunk where you have read.table(logit.txt, header=T). I don't think CHECK is running in the right directory to find the file. Whether this is your bug or CHECK's bug, I don't know. It certainly would be nice if CHECK errors were easier to diagnose. I'm not sure my diagnosis is right, because I was just trying to manually duplicate bits of the CHECK script, and I might have missed a setwd somewhere. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RGUI font problem (PR#7749)
On Sun, 27 Mar 2005 14:18:27 -0500, Christos Hatzis [EMAIL PROTECTED] wrote : It is running on MDI mode (default). It appears that if I save the preferences in the default (My Documents) folder after I make the change, the problem disappears. I was just Apply-ing the changes and then OK without saving the new preferences first. As a result, I did not have an Rconsole file in My Documents. This might be the reason why the problem was not reproducible by the development team. I think there's still something else: I don't see it when I follow your instructions above. Duncan Murdoch Thanks for you time. -Christos -Original Message- From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] Sent: Saturday, March 26, 2005 2:24 AM To: [EMAIL PROTECTED] Cc: r-devel@stat.math.ethz.ch; [EMAIL PROTECTED] Subject: Re: [Rd] RGUI font problem (PR#7749) This would appear to be the same as PR#7277. That too is not really reproducible. One possible crucial piece of missing information: is RGui being run in SDi or MDI mode? On Sat, 26 Mar 2005 [EMAIL PROTECTED] wrote: Full_Name: Christos Hatzis Version: 2.0.1 patched (2005-02-18) OS: WinXP SP2 Submission from: (NULL) (24.61.19.101) I had encountered a similar problem when changing the font in the R Console and then then open the graphics device by plot(), the console window whites out. this might be related to bug report 7271. I mentioned it sometime back and was told is was not reproducible. Now I have encountered a similar problem that does not appear to relate to the graphics device. I started an R session, changed the font to size 8, Apply/OK. Then I opened a help page by typing ?plot the R help page opened in a different (system?) font and the font in the console also changed to the same bold-face, non-proportional font. Then when I typed another help command, the console completely blanked out. It is almost certainly not blank, just using the wrong foreground colour. There seems to be some strange interaction going on between new windows opened by the system and the font setting in the GUI preferences. Yes, and that is PR#7277. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RGUI font problem (PR#7749)
On Sun, 27 Mar 2005 14:18:27 -0500, Christos Hatzis [EMAIL PROTECTED] wrote : It is running on MDI mode (default). It appears that if I save the preferences in the default (My Documents) folder after I make the change, the problem disappears. I was just Apply-ing the changes and then OK without saving the new preferences first. As a result, I did not have an Rconsole file in My Documents. This might be the reason why the problem was not reproducible by the development team. I think there's still something else: I don't see it when I follow your instructions above. Duncan Murdoch Thanks for you time. -Christos -Original Message- From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] Sent: Saturday, March 26, 2005 2:24 AM To: [EMAIL PROTECTED] Cc: r-devel@stat.math.ethz.ch; [EMAIL PROTECTED] Subject: Re: [Rd] RGUI font problem (PR#7749) This would appear to be the same as PR#7277. That too is not really reproducible. One possible crucial piece of missing information: is RGui being run in SDi or MDI mode? On Sat, 26 Mar 2005 [EMAIL PROTECTED] wrote: Full_Name: Christos Hatzis Version: 2.0.1 patched (2005-02-18) OS: WinXP SP2 Submission from: (NULL) (24.61.19.101) I had encountered a similar problem when changing the font in the R Console and then then open the graphics device by plot(), the console window whites out. this might be related to bug report 7271. I mentioned it sometime back and was told is was not reproducible. Now I have encountered a similar problem that does not appear to relate to the graphics device. I started an R session, changed the font to size 8, Apply/OK. Then I opened a help page by typing ?plot the R help page opened in a different (system?) font and the font in the console also changed to the same bold-face, non-proportional font. Then when I typed another help command, the console completely blanked out. It is almost certainly not blank, just using the wrong foreground colour. There seems to be some strange interaction going on between new windows opened by the system and the font setting in the GUI preferences. Yes, and that is PR#7277. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] rw2010alpha
On Thu, 24 Mar 2005 16:33:24 + (UTC), Gabor Grothendieck [EMAIL PROTECTED] wrote : Until recently R 2.1.0 was called rw2010dev. I just visited http://cran.r-project.org/bin/windows/base/rdevel.html and noticed its now called rw2010alpha, not rw2010dev. I would like to use it without downloading all the libraries over again. Can I - just rename my rw2010dev folder (Windows XP) to rw2010alpha and then install rw2010alpha to that? or - install it in a separate rw2010alpha folder, distinct from the rw2010dev folder and then somehow copy the libraries from one to the other? or - do I have to download the libraries all over again? or - some other solution? I suspect renaming the folder would not work because the install registers the DCOM server. Copying the libraries might be okay, if you then did a regular install of a package to update all the indices, but there might be some other detail I missed. Probably the easiest thing to do is to install the new one on top of the old rw2010dev, by changing the default install directory when you run rw2010alpha.exe. The safest thing is to install to a new folder and download all the packages again, because then you won't have any files installed which shouldn't be there. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] interp.surface() error (PR#7745)
On Wed, 23 Mar 2005 22:16:30 +0100 (CET), [EMAIL PROTECTED] wrote : R version: 2.001 OS: Windows XP SP2 When I use the interp.surface() function, on occasion I have encountered the following error message: Error in interp.surface(a, loc) : subscript out of bounds Since it is somewhat dependent on the data set, I cannot say exactly in which cases these occur, but I believe I have found the problem and a solution for it: The scaling calculations in the code, lx - ((nx - 1) * (loc[, 1] - xa))/xr + 1 ly - ((ny - 1) * (loc[, 2] - ya))/yr + 1 can lead to numerical error, so in the following lines lx1 - ifelse(lx == nx, nx - 1, trunc(lx)) ly1 - ifelse(ly == ny, ny - 1, trunc(ly)) the equality statements which are the first arguments to the IF-ELSE statements return false when they are supposed to be true. I believe the remedy is to simply avoid absolute equalities, as in the following example (which has worked for my problem): lx1 - ifelse(abs(lx - nx) 1e-10, nx - 1, trunc(lx)) ly1 - ifelse(abs(ly - ny) 1e-10, ny - 1, trunc(ly)) I hope this is an appropriate posting for an error report. Thank you very much for your hard work, I think ifelse(lx = nx, nx - 1, trunc(lx)) ifelse(ly = ny, ny - 1, trunc(ly)) would probably be a better fix, but I'd really like to see an example of this in action. Could you email me a dataset where you see it? Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] trouble building r-devel
On Tue, 22 Mar 2005 10:09:30 +1100, [EMAIL PROTECTED] wrote : I haven't been able to build yesterday's R-devel (or, as a test, R-devel_2005-03-11) on Windows XP. The error message I'm getting is to do with 'arithmetic.c', as shown below. Current R-patched seems to build fine, and I've built previous R-devels from source fairly often in the past-- though I have no understanding whatsoever of what's going on. FWIW the only changes I made to MkRules are (i) WINHELP=NO and (ii) TCL_HOME=C:/R/Tcl, which are the same ones I always make. Any help appreciated! Mark C:\R\R-devel\src\gnuwin32 make some OK bits of output, to help show where the problem is ... making vfonts.d from vfonts.c gcc -O2 -Wall -pedantic -DLEA_MALLOC -I../include -DHAVE_CONFIG_H -DR_DLL_BUILD -c CConverters.c -o CConverters.o gcc -O2 -Wall -pedantic -DLEA_MALLOC -I../include -DHAVE_CONFIG_H -DR_DLL_BUILD -c CommandLineArgs.c -o CommandLineArg s.o gcc -O2 -Wall -pedantic -DLEA_MALLOC -I../include -DHAVE_CONFIG_H -DR_DLL_BUILD -c Rdynload.c -o Rdynload.o gcc -O2 -Wall -pedantic -DLEA_MALLOC -I../include -DHAVE_CONFIG_H -DR_DLL_BUILD -c Renviron.c -o Renviron.o gcc -O2 -Wall -pedantic -DLEA_MALLOC -I../include -DHAVE_CONFIG_H -DR_DLL_BUILD -c RNG.c -o RNG.o gcc -O2 -Wall -pedantic -DLEA_MALLOC -I../include -DHAVE_CONFIG_H -DR_DLL_BUILD -c apply.c -o apply.o gcc -O2 -Wall -pedantic -DLEA_MALLOC -I../include -DHAVE_CONFIG_H -DR_DLL_BUILD -c arithmetic.c -o arithmetic.o arithmetic.c: In function `do_math1': arithmetic.c:887: `acosh' undeclared (first use in this function) arithmetic.c:887: (Each undeclared identifier is reported only once arithmetic.c:887: for each function it appears in.) arithmetic.c:888: `asinh' undeclared (first use in this function) arithmetic.c:889: `atanh' undeclared (first use in this function) make[4]: *** [arithmetic.o] Error 1 make[3]: *** [rlibs] Error 2 make[2]: *** [../../bin/R.dll] Error 2 make[1]: *** [rbuild] Error 2 make: *** [all] Error 2 My guess would be that you are using bad headers, or perhaps an out of date compiler. I just recompiled today's arithmetic.c with no error, using $ gcc --version gcc.exe (GCC) 3.4.2 (mingw-special) Copyright (C) 2004 Free Software Foundation, Inc. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trouble debugging with gdb, R on Windows
On Fri, 18 Mar 2005 09:49:28 -0800, Seth Falcon [EMAIL PROTECTED] wrote : I'm trying to follow the example in the R for Windows FAQ on running gdb and am getting stuck because gdb tells me Cannot access memory at address Here's what my gdb session looks like (This one from a cygwin shell, but same results from plain Windows CMD shell): $ cd R-devel/src/gnuwin32 $ gdb ../../bin/Rgui.exe GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-mingw32... I'm using the same version as you, but I don't see what you're seeing. You got (gdb) break WinMain Breakpoint 1 at 0x401296: file ../graphapp/graphappmain.c, line 59. (gdb) run Starting program: y:\falcon\src\R-devel\src\gnuwin32/../../bin/Rgui.exe Breakpoint 1, WinMain (Instance=0x40, PrevInstance=0x0, CmdLine=0x261f26 , CmdShow=10) at ../graphapp/graphappmain.c:59 59 startgraphapp(Instance, PrevInstance, CmdShow); (gdb) break R_ReadConsole Cannot access memory at address 0x23e17 (gdb) info symbol 0x23e17 R_ReadConsole in section .text and I get (gdb) b WinMain Breakpoint 1 at 0x401296: file ../graphapp/graphappmain.c, line 59. (gdb) run Starting program: f:\R\svn\r-devel\R\src\gnuwin32/../../bin/Rgui.exe Breakpoint 1, WinMain (Instance=0x40, PrevInstance=0x0, CmdLine=0x251f13 , CmdShow=10) at ../graphapp/graphappmain.c:59 59 startgraphapp(Instance, PrevInstance, CmdShow); (gdb) break R_ReadConsole Breakpoint 2 at 0x1001d5e6 (gdb) info symbol 0x1001d5e6 R_ReadConsole + 6 in section .text The only thing I can see is that your address for R_ReadConsole looks suspiciously low: normally code gets loaded at addresses above 0x40. I have no idea what would cause this, and am not even sure it's not perfectly reasonable. A workaround that might help would be to use the R menu item Misc|Break to debugger to break out of R once it is running, and set your breakpoints then, but I don't know that it will make any difference. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] function-like macros undefined
On Tue, 15 Mar 2005 18:58:32 -0800, Vadim Ogranovich [EMAIL PROTECTED] wrote : Hi, Somehow function-like macros from Rinternals.h are not defined when I include the file. foo.c ## #include R.h #include Rinternals.h #ifndef NILSXP #error(NILSXP) #endif #ifndef INTEGER #error(INTEGER) #endif ### When compiled: vor/src% gcc -I/usr/local/lib/R/include -g -O2 -c foo.c -o foo.o foo.c:11:2: #error (INTEGER) Note that NILSXP is defined. This is true for some other function-like macros, e.g. RAW() The definition of INTEGER is wrapped in #ifdef USE_RINTERNALS and there's this comment in Defn.h: /* To test the write barrier used by the generational collector, define TESTING_WRITE_BARRIER. This makes the internal structure of SEXPRECs visible only inside of files that explicitly define USE_RINTERNALS, and all uses of SEXPREC fields that do not go through the appropriate functions or macros will become compilation errors. Since this does impose a small but noticable performance penalty, code that includes Defn.h (or code that explicitly defines USE_RINTERNALS) can access a SEXPREC's fields directly. */ To read about the reasons for the write barrier, see http://www.stat.uiowa.edu/~luke/R/barrier.html Duncan Murdoch Did anyone come across such a problem? version _ platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status major2 minor0.1 year 2004 month11 day 15 language R OS: suse.9.2_64 Note also that R doesn't recognize this is Suse, it says x86_64-unknown-linux-gnu. Hope this is not a problem. Thanks, Vadim [[alternative HTML version deleted]] __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Quirk with as.function(..., envir = NULL) and body(..., envir = NULL) -
I've been doing some looking through the environment code lately, and noticed that both as.function(..., envir = NULL) and body(..., envir = NULL)- treat the NULL as .GlobalEnv, even though NULL is the environment of the base package. The code that does this is very deep in the guts of R and affects all sorts of things, so I'm not planning to change it for 2.1.0, but I expect it will be fixed in 2.2.0 this fall. In the meantime, I'd advise people to avoid using envir = NULL, and instead use envir = globalenv() or envir = .GlobalEnv (which are equivalent). If you want to set base as the environment for a function, you should use environment(f) - NULL for now. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] delay() has been deprecated for 2.1.0
After a bunch of discussion in the core group, we have decided to
deprecate the delay() function (which was introduced as experimental
in R 0.50). This is the function that duplicates in R code the
delayed evaluation mechanism (the promise) that's used in evaluating
function arguments.
The problem with delay() was that it was handled inconsistently (e.g.
sometimes you would see an object displayed as promise:...,
sometimes it would be evaluated); it tended to be error-prone in usage
(e.g. this was the cause of the bug that makes the curve() function
create a pu object in the global environment); and it was generally
difficult to figure out exactly what the semantics of it should be in
order to be consistent.
delay() has been replaced with delayedAssign(). This new function
creates a promise and assigns it into an environment. Once one more
set of changes is made and delay() is gone, there should be no way to
see a promise: ... object in R: as soon as the object is accessed,
it will be evaluated and you'll see the value.
A few packages made use of delay(). I have replaced all of those uses
with delayedAssign(). The most common usage was something like the QA
code uses:
assign(T, delay(stop(T used instead of TRUE)),
pos = .CheckExEnv)
This translates to
delayedAssign(T, stop(T used instead of TRUE), eval.env =
.GlobalEnv, assign.env = .CheckExEnv)
In most cases the eval.env = .GlobalEnv argument is not necessary
(and in fact it is often a bug, as it was in curve()). The
environment where the promise is to be evaluated now defaults to the
environment where the call is being made, rather than the global
environment, and this is usually what you want.
Package writers who use delay() will now get a warning that it has
been deprecated. They should recode their package to use
delayedAssign instead.
Examples from CRAN of this (I am not sure if this list is exhaustive):
exactRankTests, genetics, g.data, maxstat, taskPR, coin
I have cc'd the maintainers of those packages.
If you want a single code base for your package that works in both the
upcoming R 2.1.0 and older versions, this presents a problem: older
versions don't have delayedAssign. Here is a workalike function that
could be used in older versions:
delayedAssign - function(x, value,
eval.env = parent.frame(),
assign.env = parent.frame()) {
assign(x, .Internal(delay(substitute(value), eval.env)),
envir = assign.env)
}
Because this function calls the internal delay() function directly, it
should work in R 2.1.0+ as well without a warning, but the internal
function will eventually go away too, so I don't recommend using it in
the long term.
Sorry for any inconvenience that this causes.
Duncan Murdoch
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Does cat(\a) ring a bell?
I've now added a function called alarm() to ring a bell. It's documented to work on some platforms, but not all. If it truly is easy to support this, you might as well, but I can't see this as a high priority. Duncan Murdoch On Mon, 7 Mar 2005 21:12:17 +0100, stefano iacus [EMAIL PROTECTED] wrote : no, on Mac OS X, but could be easily implemented. stefano On 07/mar/05, at 21:02, Duncan Murdoch wrote: Under GUIs other than Windows (Mac OS X, ESS, etc.) does cat(\a) still make a bell (or some other) sound? If so, I'll add a bell() function to utils. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in handling of promises?
I'm working on a function that does adaptive sampling, and I thought
it would be handy to return the function's environment as part of the
result so that I could re-use local variables in a subsequent run. My
first try didn't work, and it came down to code like this:
f - function( H, prevEnv = NULL) {
+ if (!is.null(prevEnv)) H - prevEnv$H
+ cat('Evaluate H to get ', H(1), '\n')
+ return(environment(NULL))
+ }
I thought that evaluating H would force it, so that H would be
available in the environment returned by the function. But this is
not so:
env - f( function(x) x^2 )
Evaluate H to get 1
env$H
promise: 012094D8
env$H(1)
Error: attempt to apply non-function
So I tried to explicitly force it:
g - function( H, prevEnv = NULL) {
+ if (!is.null(prevEnv)) H - prevEnv$H
+ force(H)
+ return(environment(NULL))
+ }
but this still doesn't work:
env - g( function(x) x^2 )
env$H
promise: 01206FC0
env$H(1)
Error: attempt to apply non-function
It seems that I need to do an assignment to convert H from a promise
to an evaluated object:
h - function( H, prevEnv = NULL) {
+ if (!is.null(prevEnv)) H - prevEnv$H
+ H - H
+ return(environment(NULL))
+ }
env - h( function(x) x^2 )
env$H
function(x) x^2
env$H(1)
[1] 1
Is this a bug, or just the way things are?
I get the same results in both R-patched and R-devel.
Duncan Murdoch
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in handling of promises?
On Tue, 8 Mar 2005 17:44:41 + (GMT), Prof Brian Ripley
[EMAIL PROTECTED] wrote :
The following note in ?force may help
Note:
'force' does not force the evaluation of promises.
It is there because people have been confused before.
Yes, but it also says that it forces the evaluation of a function
argument, which is what I was trying to do.
But mainly what may be a bug is the fact that H was available in env
but its value was not, even though it had already been evaluated in
that environment.
My examples were unnecessarily complicated last time, because they
were too much like the original. Here are simpler versions:
f - function( H ) {
+ cat('Evaluate H to get ', H, '\n')
+ return(environment())
+ }
env - f( 1 )
Evaluate H to get 1
env$H
promise: 0118BF1C
g - function( H ) {
+ force(H)
+ return(environment())
+ }
env - g( 2 )
env$H
promise: 0118A148
h - function( H ) {
+ H - H
+ return(environment())
+ }
env - h( 3 )
env$H
[1] 3
Duncan Murdoch
On Tue, 8 Mar 2005, Duncan Murdoch wrote:
I'm working on a function that does adaptive sampling, and I thought
it would be handy to return the function's environment as part of the
result so that I could re-use local variables in a subsequent run. My
first try didn't work, and it came down to code like this:
f - function( H, prevEnv = NULL) {
+ if (!is.null(prevEnv)) H - prevEnv$H
+ cat('Evaluate H to get ', H(1), '\n')
+ return(environment(NULL))
+ }
I thought that evaluating H would force it, so that H would be
available in the environment returned by the function. But this is
not so:
env - f( function(x) x^2 )
Evaluate H to get 1
env$H
promise: 012094D8
env$H(1)
Error: attempt to apply non-function
So I tried to explicitly force it:
g - function( H, prevEnv = NULL) {
+ if (!is.null(prevEnv)) H - prevEnv$H
+ force(H)
+ return(environment(NULL))
+ }
but this still doesn't work:
env - g( function(x) x^2 )
env$H
promise: 01206FC0
env$H(1)
Error: attempt to apply non-function
It seems that I need to do an assignment to convert H from a promise
to an evaluated object:
h - function( H, prevEnv = NULL) {
+ if (!is.null(prevEnv)) H - prevEnv$H
+ H - H
+ return(environment(NULL))
+ }
env - h( function(x) x^2 )
env$H
function(x) x^2
env$H(1)
[1] 1
Is this a bug, or just the way things are?
I get the same results in both R-patched and R-devel.
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in handling of promises?
A followup: doing an assignment of the value works even after the
return:
f
function( H ) {
cat('Evaluate H to get \n')
print(H)
return(environment())
}
env - f( function(x) x^2 )
Evaluate H to get
function(x) x^2
env$H
promise: 0117C2D0
env$H(1)
Error: attempt to apply non-function
H - env$H
H(1)
[1] 1
So the oddity is that I can evaluate H within f() without any problem,
but outside of f() I need extra work before I can do it.
Duncan Murdoch
On Tue, 08 Mar 2005 18:00:10 +, Duncan Murdoch
[EMAIL PROTECTED] wrote :
On Tue, 8 Mar 2005 17:44:41 + (GMT), Prof Brian Ripley
[EMAIL PROTECTED] wrote :
The following note in ?force may help
Note:
'force' does not force the evaluation of promises.
It is there because people have been confused before.
Yes, but it also says that it forces the evaluation of a function
argument, which is what I was trying to do.
But mainly what may be a bug is the fact that H was available in env
but its value was not, even though it had already been evaluated in
that environment.
My examples were unnecessarily complicated last time, because they
were too much like the original. Here are simpler versions:
f - function( H ) {
+ cat('Evaluate H to get ', H, '\n')
+ return(environment())
+ }
env - f( 1 )
Evaluate H to get 1
env$H
promise: 0118BF1C
g - function( H ) {
+ force(H)
+ return(environment())
+ }
env - g( 2 )
env$H
promise: 0118A148
h - function( H ) {
+ H - H
+ return(environment())
+ }
env - h( 3 )
env$H
[1] 3
Duncan Murdoch
On Tue, 8 Mar 2005, Duncan Murdoch wrote:
I'm working on a function that does adaptive sampling, and I thought
it would be handy to return the function's environment as part of the
result so that I could re-use local variables in a subsequent run. My
first try didn't work, and it came down to code like this:
f - function( H, prevEnv = NULL) {
+ if (!is.null(prevEnv)) H - prevEnv$H
+ cat('Evaluate H to get ', H(1), '\n')
+ return(environment(NULL))
+ }
I thought that evaluating H would force it, so that H would be
available in the environment returned by the function. But this is
not so:
env - f( function(x) x^2 )
Evaluate H to get 1
env$H
promise: 012094D8
env$H(1)
Error: attempt to apply non-function
So I tried to explicitly force it:
g - function( H, prevEnv = NULL) {
+ if (!is.null(prevEnv)) H - prevEnv$H
+ force(H)
+ return(environment(NULL))
+ }
but this still doesn't work:
env - g( function(x) x^2 )
env$H
promise: 01206FC0
env$H(1)
Error: attempt to apply non-function
It seems that I need to do an assignment to convert H from a promise
to an evaluated object:
h - function( H, prevEnv = NULL) {
+ if (!is.null(prevEnv)) H - prevEnv$H
+ H - H
+ return(environment(NULL))
+ }
env - h( function(x) x^2 )
env$H
function(x) x^2
env$H(1)
[1] 1
Is this a bug, or just the way things are?
I get the same results in both R-patched and R-devel.
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R crashes using the em function of package mclust (PR#7719)
On Mon, 7 Mar 2005 09:35:39 +0100 (CET), [EMAIL PROTECTED] wrote : Hi, I got the same problem like http://tolstoy.newcastle.edu.au/R/devel/04/11/1204.html R crashes when I use the em function from the mclust package on univariate data and on a special case on bivariate data (when the matrix is not provided as written in the manual). It seems as if the problem is the format of the data to be analyzed. Operating System: Windows XP (SP2) R version: R-2.0.1 The following example causes a crash of R: # univariate example require(mclust) X - c(rnorm(100, mean=1), rnorm(100, mean=5)) # I also tried: X - as.matrix(c(rnorm(100, mean=1), rnorm(100, mean=5))) Xmap - cbind(c(rep(1, 100), rep(0, 100)), c(rep(0, 100), rep(1, 100))) Xm - mstep(modelName=V, data=X, z=Xmap) # CRASH: em(modelName=Xm$modelName, data=X, mu=Xm$mu, sigmasq=Xm$sigmasq, pro=Xm$pro) Which version of mclust? I just installed 2.1-8 and ran your code in R-2.0.1 with no problem. In any case, this looks more like an mclust problem than an R problem; if you're using the current version, you should follow up with the maintainer, Ron Wehrens [EMAIL PROTECTED]. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Does cat(\a) ring a bell?
Under GUIs other than Windows (Mac OS X, ESS, etc.) does cat(\a) still make a bell (or some other) sound? If so, I'll add a bell() function to utils. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Does anyone care about wait in Windows bug.report()?
Since the internal editor was added in 2.0.0, the bug.report() function has failed to run properly with it (and it's the default editor on a new install). The fix for this is simple (use file.edit() instead of constructing a system call to call the editor), but file.edit() doesn't support the wait parameter that bug.report() currently has on Windows. Rather than adding wait to file.edit(), I'd rather remove it from bug.report(). Will anyone object if I do this? Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug report for as.function (PR#7702)
On Thu, 24 Feb 2005 15:59:13 +0100 (CET), [EMAIL PROTECTED] wrote : Hi, I got the following message in R: Error in as.function.default(pdfs[1]) : invalid body argument for function Should NEVER happen; please bug.report() [mkCLOSXP] A simpler version is as follows: x1 - list(function() 1) x1 [[1]] function() 1 as.function(x1) Error in as.function.default(x1) : invalid body argument for function Should NEVER happen; please bug.report() [mkCLOSXP] The problem is that as.function doesn't know how to handle an object of mode function as the body of a function. It expects a function definition to be a call instead: x2 - as.list(function() function() 1) x2 [[1]] function() 1 as.function(x2) # no problem this time function () function() 1 mode(x1) [1] list mode(x1[[1]]) [1] function mode(x2) [1] list mode(x2[[1]]) # notice the difference from x1[[1]] [1] call These tests were done in platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status Under development (unstable) major2 minor1.0 year 2005 month02 day 24 language R Could someone else please deal with this? I have trouble with test builds right now. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug? quantile() can return decreasing sample quantiles for increasing probabilities
On Tue, 22 Feb 2005 13:43:47 -0700, Tony Plate [EMAIL PROTECTED] wrote : Is it a bug that quantile() can return a lower sample quantile for a higher probability? # quantile returns decreasing results with increasing probs (data at the end of the message) quantile(x2, (0:5)/5) 0% 20% 40% 60% 80% -0.0014141174 -0.0009041968 -0.0009041968 -0.0007315023 -0.0005746115 100% 0.2905596324 # the 40% quantile has a lower value than the 20% quantile diff(quantile(x2, (0:5)/5)) 20% 40% 60% 80% 100% 5.099206e-04 -1.084202e-19 1.726945e-04 1.568908e-04 2.911342e-01 This only happens for type=7: for (type in 1:9) cat(type, any(diff(quantile(x2, (0:5)/5, type=type))0), \n) 1 FALSE 2 FALSE 3 FALSE 4 FALSE 5 FALSE 6 FALSE 7 TRUE 8 FALSE 9 FALSE I know this is at the limits of machine precision, but it still seems wrong. Curiously, S-PLUS 6.2 produces exactly the same numerical result on my machine (according to the R quantile documentation, the S-PLUS calculations correspond to type=7). I'd say it's not a bug in that rounding error is something you should expect in a calculation like this, but it does look wrong. And it isn't only restricted to type 7. If you make a vector of copies of that bad value, you'll see it in more cases: x - rep(-0.00090419678460984, 602) for (type in 1:9) cat(type, any(diff(quantile(x, (0:5)/5, + type=type))0), \n) 1 FALSE 2 FALSE 3 FALSE 4 FALSE 5 TRUE 6 TRUE 7 TRUE 8 FALSE 9 TRUE (at least on Windows). What's happening is that R is doing linear interpolation between two equal values, and not getting the same value back, because of rounding. The offending line appears to be this one: qs[i] - ifelse(h == 0, qs[i], (1 - h) * qs[i] + h * x[hi[i]]) The equivalent calculation in the approx function (which doesn't appear to have this problem) is qs[i] + (x[hi[i]] - qs[i]) * h Can anyone think of why this would not be better? (The same sort of calculation shows up again later in quantile().) Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug? quantile() can return decreasing sample quantiles for increasing probabilities
On Tue, 22 Feb 2005 21:36:20 +, Duncan Murdoch [EMAIL PROTECTED] wrote : On Tue, 22 Feb 2005 13:43:47 -0700, Tony Plate [EMAIL PROTECTED] wrote : Is it a bug that quantile() can return a lower sample quantile for a higher probability? # quantile returns decreasing results with increasing probs (data at the end of the message) quantile(x2, (0:5)/5) 0% 20% 40% 60% 80% -0.0014141174 -0.0009041968 -0.0009041968 -0.0007315023 -0.0005746115 100% 0.2905596324 # the 40% quantile has a lower value than the 20% quantile diff(quantile(x2, (0:5)/5)) 20% 40% 60% 80% 100% 5.099206e-04 -1.084202e-19 1.726945e-04 1.568908e-04 2.911342e-01 This only happens for type=7: for (type in 1:9) cat(type, any(diff(quantile(x2, (0:5)/5, type=type))0), \n) 1 FALSE 2 FALSE 3 FALSE 4 FALSE 5 FALSE 6 FALSE 7 TRUE 8 FALSE 9 FALSE I know this is at the limits of machine precision, but it still seems wrong. Curiously, S-PLUS 6.2 produces exactly the same numerical result on my machine (according to the R quantile documentation, the S-PLUS calculations correspond to type=7). I'd say it's not a bug in that rounding error is something you should expect in a calculation like this, but it does look wrong. And it isn't only restricted to type 7. If you make a vector of copies of that bad value, you'll see it in more cases: x - rep(-0.00090419678460984, 602) for (type in 1:9) cat(type, any(diff(quantile(x, (0:5)/5, + type=type))0), \n) 1 FALSE 2 FALSE 3 FALSE 4 FALSE 5 TRUE 6 TRUE 7 TRUE 8 FALSE 9 TRUE (at least on Windows). What's happening is that R is doing linear interpolation between two equal values, and not getting the same value back, because of rounding. The offending line appears to be this one: qs[i] - ifelse(h == 0, qs[i], (1 - h) * qs[i] + h * x[hi[i]]) The equivalent calculation in the approx function (which doesn't appear to have this problem) is qs[i] + (x[hi[i]] - qs[i]) * h Can anyone think of why this would not be better? (The same sort of calculation shows up again later in quantile().) Just looked at the history of this line, and it appears the code is the way it is to avoid an error if the value of the vector is infinite. For example, we now get the right answer x - rep(Inf, 100) quantile(x, 0:5/5) 0% 20% 40% 60% 80% 100% Inf Inf Inf Inf Inf Inf but with my modification above we wouldn't: quantile(x, 0:5/5) 0% 20% 40% 60% 80% 100% Inf NaN NaN NaN NaN Inf Duncan __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] bug? quantile() can return decreasing sample quantiles for increasing probabilities
On Tue, 22 Feb 2005 15:14:00 -0700, Tony Plate [EMAIL PROTECTED] wrote : Thanks for the diagnosis. The reason I came across this was that I use both S-PLUS and R and I often use the results of quantile() as the breaks for cut(). In S-PLUS, cut() stops with an error if breaks has any decreasing values. Thus this example caused an S-PLUS function to unexpectedly stop with an error. However, cut() in R behaves differently: it sorts its breaks and thus does not object to decreasing values in breaks. Another difference is that cut() in R stops with an error if any breaks are duplicated, which, I guess, means that in R I should use findInterval() instead of cut() for this task. Except that findInterval() in R stops with an error if its breaks are unsorted... findInterval(x2, quantile(x2, (0:5)/5)) Error in findInterval(x2, quantile(x2, (0:5)/5)) : 'vec' must be sorted non-decreasingly I guess you'll just have to use sort(quantile(...)). It makes the labels look sort of funny, but is hopefully harmless: x - rep(-0.00090419678460984, 602) sort(quantile(x, 0:5/5)) 0% 40% 60% 80% 100% -0.0009041968 -0.0009041968 -0.0009041968 -0.0009041968 -0.0009041968 20% -0.0009041968 Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Translation Teams
R version 2.1.0 and later will support translations of program messages into different languages (largely through the efforts of Brian Ripley; thanks!) A number of translation projects are already underway or completed. I've put up a web page at http://developer.r-project.org/TranslationTeams.html listing the current languages I know about and the contacts for each. To offer your help with one of these, contact a team on the list. To list your own translation project there, contact me or another member of R-core with the details. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Documentation typos (PR#7693)
On Thu, 17 Feb 2005 20:37:36 +0100 (CET), [EMAIL PROTECTED] wrote : There's a harmless typo in screen.Rd where coner should be corner. Nitpicking to the extreme, ie. should be i.e. in plotformula.Rd and screen.Rd. I'll fix these in R-devel. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] german translation
On Thu, 17 Feb 2005 21:21:18 -0200, Fernando Henrique Ferraz P. da Rosa [EMAIL PROTECTED] wrote : I think it would be useful to set up a list (even in static html on the R-developer page perhaps) of who is working on each translation, with the respectives e-mail addresses. This way we would avoid duplication of efforts and make it easier to group teams: anyone interested on working on a particular language would look up that list for someone already working on it and contact him. That sounds like a good idea. The pointer could consist of an email address of one of the group members, and/or a link to a web page for the group. I'd do it right now, but I seem to be having problems contacting the repository to update the web pages... I for one I'm working on the translation of the .pot files to Portuguese-BR (right now I'm on 80% of the R.pot). By the way, I'm using the ISO8559-1 encoding (which was the recommended* option by the Brazilian Team on the gettext page) - I still didn't get around to converting my system to UFT-8, but I hope that isn't a problem. Anyways I'll try to see if there's a way to convert it from ISO8559-1 to UTF-8. The iconv utility is supposed to do this. If you're on Windows: I have a copy of iconv for Windows on www.murdoch-sutherland.com/Rtools, but you might not need it. Lots of editors (e.g. Windows notepad) can also do this conversion. Duncan Murdoch Duncan __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Environment with no parent?
On 09 Feb 2005 00:29:37 +0100, Peter Dalgaard
[EMAIL PROTECTED] wrote :
Duncan Murdoch [EMAIL PROTECTED] writes:
(a) efficiency. Is it expensive no longer to have the base functions
bound directly to their symbol? (My gut feeling is that with suitable
hashing and cacheing, the penalty is minimal.)
(b) you can *only* use get and simple variable retrieval in a non-base
environment with a NULL parent (eval(x - 1, envir=foo) would give
'couldn't find function -' or so). This could cause some confusion.
(b) means that the default should stay the way it is, but I think
there should be a way to set up a truly empty environment. We have a
fair number of cases where envir=NULL is used, so it would be safest
to make it a different value -- even if NULL is the obvious value for
an empty environment.
Not necessarily. It just means that you should think about it. It is
not a given that envir=NULL really means what the author expected, and
fixing them up to read envir=.BaseEnv is probably quite doable.
For the benefit of the archives:
Setting the NULL environment to contain nothing is nontrivial; even
creating a new magic environment that appeared to be empty would
require a surprising number of low-level changes. So, rather than
take this on, I've decided on this R-only solution to my problem: a
version of exists() that treats NULL as if it were empty:
# Modified exists function: like exists(x, envir, inherits = TRUE),
except that a
# NULL parent is considered empty
myexists - function(x, envir) {
result - FALSE
while (!result !is.null(envir)) {
result - exists(x, envir=envir, inherits = FALSE)
envir - parent.env(envir)
}
result
}
Duncan Murdoch
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] link to an alias in another package
On Tue, 8 Feb 2005 07:18:28 + (GMT), Prof Brian Ripley
[EMAIL PROTECTED] wrote :
On Mon, 7 Feb 2005, Paul Gilbert wrote:
In some documentation for a package I am working on I have
\code{\link[stats]{varimax}}
\code{\link[stats]{promax}}
The link to varimax works, but not the one to promax. Promax is an alias
under \name{varimax}. This kind of link works within a package, but I'm not
sure if it is suppose to work when it is a link to another package. Is this
a
known limitation or bug, or something I should explore more carefully?
Definitely the latter! Don't include [stats] (why are you including it?),
or do read the documentation in R-exts:
There are optional arguments specified as \link[pkg]{foo} and
\link[pkg:bar]{foo} to link to the package pkg with topic (file?)
foo and bar respectively.
so you need \code{\link[stats:varimax]{promax}}. Note the difference
between `topic' and `alias' here.
This is not a bug, but is it a design flaw? The problem is that Paul
wants to refer to the documentation for promax. Currently that's in
the varimax topic, but if someone were to split the topics, that
wouldn't be true any more: and then Paul's link would point to the
wrong place.
It is inconsistent that \link{foo} looks for the alias foo, but
\link[pkg]{foo} and \link[pkg:foo]{bar} look for the topic foo.
It is probably impossible to implement links to aliases perfectly
(e.g. if pkg is unavailable at the time the .html file for Paul's
topic is being built, it's not clear what the link should be), but
doing at least as well as \link{foo} does would take very little work.
The algorithm could be:
- attempt to look up the alias foo in pkg. If that succeeds, use the
resulting topic in the link.
- if pkg exists but the lookup fails, that's an error.
- if the lookup fails because pkg does not exist, print a warning,
and create a link as though the alias is a topic.
This would mean \link[stats]{promax} would be fine, and would survive
the addition of a promax topic to another package, or the splitting of
promax out of the varimax topic.
You only need the [] to disambiguate crossreferences, or to refer to
packages that might not yet be installed, which does not apply to [stats].
Duncan Murdoch
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] link to an alias in another package
On Tue, 8 Feb 2005 12:21:05 + (GMT), Prof Brian Ripley
[EMAIL PROTECTED] wrote :
On Tue, 8 Feb 2005, Duncan Murdoch wrote:
On Tue, 8 Feb 2005 07:18:28 + (GMT), Prof Brian Ripley
[EMAIL PROTECTED] wrote :
On Mon, 7 Feb 2005, Paul Gilbert wrote:
In some documentation for a package I am working on I have
\code{\link[stats]{varimax}}
\code{\link[stats]{promax}}
The link to varimax works, but not the one to promax. Promax is an alias
under \name{varimax}. This kind of link works within a package, but I'm not
sure if it is suppose to work when it is a link to another package. Is
this a
known limitation or bug, or something I should explore more carefully?
Definitely the latter! Don't include [stats] (why are you including it?),
or do read the documentation in R-exts:
There are optional arguments specified as \link[pkg]{foo} and
\link[pkg:bar]{foo} to link to the package pkg with topic (file?)
foo and bar respectively.
so you need \code{\link[stats:varimax]{promax}}. Note the difference
between `topic' and `alias' here.
This is not a bug, but is it a design flaw? The problem is that Paul
wants to refer to the documentation for promax. Currently that's in
Not a design flaw, just a rather more carefully researched design that
actually works.
Unless the package is present, you have no idea in what file the help for
promax is, and you need to know to generate hyperlinks (or you don't need
to use this notation).
Now, hyperlinks to other packages are no real use in current PDF (unless
you merge PDF files), and HTML help will if java/javascript is enabled
resolve the references at run time, BUT neither HTML without the search
engine nor CHTML can do that.
Since two packages can cross-reference each other, you cannot assume that
the one you want to reference is currently installed without a potential
deadlock.
the varimax topic, but if someone were to split the topics, that
wouldn't be true any more: and then Paul's link would point to the
wrong place.
It is inconsistent that \link{foo} looks for the alias foo, but
\link[pkg]{foo} and \link[pkg:foo]{bar} look for the topic foo.
Not in my understanding. That's the whole (and documented) point of the
notation, to tell Rdconv where to look when aliases are not
known/available.
It is probably impossible to implement links to aliases perfectly
(e.g. if pkg is unavailable at the time the .html file for Paul's
topic is being built, it's not clear what the link should be), but
However, that is the only common reason to use this form of link.
doing at least as well as \link{foo} does would take very little work.
The algorithm could be:
- attempt to look up the alias foo in pkg. If that succeeds, use the
resulting topic in the link.
- if pkg exists but the lookup fails, that's an error.
- if the lookup fails because pkg does not exist, print a warning,
and create a link as though the alias is a topic.
The last is the only time you really need this, and what is done now is
better than your suggestion. We set up a mechanism for precisely this
case, and to break it would be a design flaw.
I only see two differences between the current scheme and the last
case:
- now no warning is printed, which does seem reasonable, given that
there exist mutual cross-references.
- my scheme would require that a topic name be repeated as an alias
if both the first and last type of lookups were possible.
Alternatively, we could allow lookups by topic name as well as alias
for back-compatibility.
Other than these, I don't see how the current scheme is better. In
the current system:
- If I use an unadorned \link{promax}, I run the risk of having it go
to the wrong place if someone defines a promax alias in some other
package that is installed before mine.
- If I use \link[stats:varimax]{promax}, then I run the risk of
having it go to the wrong place if someone splits promax.Rd out of
varimax.Rd in the stats package.
- If I have a spelling error in the link (e.g.
\link[stats:varmax]{promax}), then neither INSTALL nor CHECK will tell
me about it.
None of these would be a problem if I used \link[stats]{promax} under
my proposal, unless my package were being installed before stats was,
in which case the link would fail.
But if that's a possibility (e.g. we're talking about a core package,
or a package with mutual dependencies with the referenced one so that
we can't be sure which will be installed first), then we could simply
document that references to aliases might fail. Two packages with
mutual dependencies are presumably being maintained together, so the
second problem above wouldn't be an issue.
Have I missed some advantages of the current scheme over the one I
proposed? There's the obvious one of the fact that it exists, whereas
mine will take a bit of work to do, but if I don't hear of some fatal
flaw, I'll volunteer to do the work. I don't think it will be hard.
Duncan Murdoch
[Rd] Environment with no parent?
Is it possible to create an environment that has no parent (or an
empty parent)? I would have thought
e - new.env(parent=NULL)
would work, but it acts as though the parent is the base namespace:
get(close, envir = e)
function (con, ...)
UseMethod(close)
environment: namespace:base
I can use inherits = FALSE in this case:
get(close, envir = e, inherits = F)
Error in get(x, envir, mode, inherits) : variable close was not
found
but what I want to do is to create my own hierarchy of environments
that allow inheritance from their parents, but which stop when they
get to e, and don't continue on into base. For example
assign('x', 1, envir = e)
f - new.env(parent = e)
assign('y', 2, envir = f)
# The first two of these work as desired, but I'd like a not found error
from the last:
get('y', envir=f)
[1] 2
get('x', envir=f)
[1] 1
get('close', envir=f)
function (con, ...)
UseMethod(close)
environment: namespace:base
Looking in envir.c, I see this:
/* env is now R_NilValue, the base environment */
which doesn't give me much hope, but maybe there's a trick
If not, would it be reasonable to install a magic EmptyEnv to use as
a parent in this sort of situation?
Duncan Murdoch
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] compiling and making R-2.0.1 for windows XP
On Fri, 28 Jan 2005 15:37:41 + (GMT), Prof Brian Ripley [EMAIL PROTECTED] wrote : On Fri, 28 Jan 2005, Uwe Ligges wrote: John Marsland wrote: I am having no luck compiling R-2.0.1 on a Windows XP platform. I have not had these problems when compliling previous versions of R. I've installed all the recommended software and tools. But I cannot get round this error message: make make[1]: `Rpwd.exe' is up to date. make -f Makefile.docfiles make[3]: Nothing to be done for `docfiles'. Building ../../../library/base/R/Rprofile from ../../library/profile/Common.R ../../library/profile/Rprofile.windows mkdir -p ../../../library/base/R cat: not found cat should be among the tools, looks like Duncan's latest release of tools.zip is missing cat (and I have tested the new release by overwriting older files, so I haven't noticed at least one file is missing this time). It is in the list mentioned in INSTALL, which is worth checking I accidentally put cal in instead of cat; it was fixed just yesterday. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows tools updated
I've just updated the Windows build instructions and the files in the Rtools collection (on www.murdoch-sutherland.com/Rtools). Most of the tools are now up to current release versions. I'd appreciate hearing from anyone if I've missed anything, or there are incompatibilities that I didn't notice. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows build hiatus
There have been a lot of changes recently in R-devel, so I've been uploading frequent Windows builds to CRAN. I'm heading out to a conference this week, so it's unlikely there will be any more builds until Jan 18 or later. (I've just done one today; it may not show up until tomorrow). If you were unaware of these builds, they are available at your favourite CRAN mirror (list here: http://cran.r-project.org/mirrors.html) in the bin/windows/base directory. Follow the link to the r-devel release or the r-patched release. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Broken Link for gregmisc_2.0.0.zip
On Thu, 6 Jan 2005 13:06:51 +0100, [EMAIL PROTECTED] wrote Not really ... we had the webmaster address on almost all pages of CRAN until 2 or 3 years ago. I removed it deliberately from most places because way too many people confused it with r-help. How about a Contact Us link on each page, which goes to a page that lists the various possible contact addresses, with r-help first? We wouldn't want to put in the r-help submission address there; it should be a link to http://www.stat.math.ethz.ch/mailman/listinfo/r-help or some other page that tells people what to expect, and lets them search the archives. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-intro
On Sat, 01 Jan 2005 17:24:33 +0100, Uwe Ligges [EMAIL PROTECTED] wrote: Gorjanc Gregor wrote: The problem is that there is no file morley.tab. I belive that for first impression or example session, things should work. Have you read from the beginning in Appendix A? It says: Login, start your windowing system. You should also have the file morley.tab in your working directory. If not, seek the local expert (or get it yourself from the datasets/data subdirectory of the default R library tree). If you have, proceed. The point is that we cannot get the file anymore from datasets/data, because since the days of R-2.0.0 we have the data in package datasets lazy loaded and the file morley.tab is not available in binary installations. Hence it is a bug. Possible solution: We could copy the file to something like .../src/library/datasets/inst/intro/morley.tab It would also make sense to simplify the Appendix A stuff in R-intro, because this is (well, has been) a more or less frequently asked question (I wonder why nobody has asked during the last 3 months ): filename - file.path(.find.package(datasets), intro, morley.tab)) filename file.show(filename) mm - read.table(filename) Uwe Ligges Good suggestions. I'll make the changes in R-patched. Duncan Murdoch __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: [R] Is k equivalent to k:k ?
On Fri, 10 Dec 2004 09:32:14 +0100, Martin Maechler [EMAIL PROTECTED] wrote : RichOK If you want to pass seq(length=n) to a .C or RichOK .Fortran call, it's not helpful that you can't tell RichOK what the type is until you know n! It would be nice RichOK if seq(length=n) always returned the same type. I RichOK use seq(length=n) often instead of 1:n because I'd RichOK like my code to work when n == 0; it would make life RichOK simpler if seq(length=n) and 1:n were the same type. now if that really makes your *life* simpler, what does that tell us about your life ;-) :-) But yes, you are right. All should return integer I think. Yes, it should be consistent, and integer makes sense here. However, as a matter of defensive programming, one should almost always explicitly set the type (using as.integer for example) in a .C or .Fortran call: those languages care quite a bit about the storage mode, and give bizarre and hard to debug errors when it is wrong. If you did this, you wouldn't care that seq(length=n) returns mode double. It might waste a few cpu cycles, but programmer debugging cycles are much more expensive. Duncan Murdoch __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C access to R libraries
On Fri, 10 Dec 2004 18:27:19 +0100, Jul [EMAIL PROTECTED] wrote : Hi all, I'm used to code in C and I'm wondering if access to internal R compiled libraries with C is an easy job under linux. Is anyone has experience with that ? Some headers seems rather clear and interesting, but binding may not be so easy Actually, my question is: will I have to manipulate complex R objects in C to access to raw statistic functions ? No, a lot of the functionality doesn't need R objects. See the R API chapter in the Writing R Extensions manual. I've had no experience with using it in Linux, but I think it's pretty straightforward. Duncan Murdoch __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Typos in 'R Language Definition' 2.0.1 Draft 2004-11-15 (PR#7412)
On Fri, 10 Dec 2004 17:08:10 +0100 (CET), [EMAIL PROTECTED] wrote : Full_Name: Mike Kay Version: 2.0.1 OS: Linux Submission from: (NULL) (137.75.70.37) Hi, Here are some typos/grammatical errors that I found while reading the doc. referenced in the subject line. Hope this helps. Thanks, I'll fix these (if they haven't been fixed already). Duncan Murdoch -mike Page 4, first paragraph of 2.1.4: 'objects which they contain' - 'objects which contain' Page 5, second paragraph of 2.1.10 'environment can be accesses' - 'environment can be accessed' Page 13, second paragraph of 3.3.4 'There is one cases' - 'There is one case' Page 16, First line of 3.4.4 'of a general mechanisms for' - 'of a general mechanism for' Further down in that section there's the line 'and so to' which I believe should be 'and so too' Page 17, section 3.5.1 'An assignment operation from command line' - 'An assignment operation from the command line' Page 18, first paragraph of 3.5.3 'during the computation the the currently' - 'during the computation the currently' Further down on the same page: sys.call Get the call for the specified context -- missing trailing period to match all other sys.* entries __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pausing between plots - waiting for graphics input
On Wed, 01 Dec 2004 10:32:57 +1300, Paul Murrell [EMAIL PROTECTED] wrote : Hi Duncan Murdoch wrote: On Wed, 01 Dec 2004 08:55:27 +1300, Paul Murrell [EMAIL PROTECTED] wrote : This sounds like the general problem of being able to capture keyboard input on a graphics device (a key-stroke equivalent of dev_locator). Robert has been keen on this for a while too. I've now committed the getGraphicsEvent function with mouse and keyboard support. So far only the windows screen device knows how to work with it, because that's all I've got. It's in the R-devel build I just uploaded, which should be downloadable by tomorrow. If someone wants to write support for other platforms, I'd be happy to help. I imagine the implementation will change a bit when we do the first one, because I don't know the other platforms at all, and have probably made some Windows-centric assumptions. But at least it's a starting point. Here's a quick summary of how it currently looks: The device is assumed to be based on the NewDevDesc structure. There are new fields canGenXXX to indicate that it can generate mouse or keyboard events; getGraphicsEvent aborts if you try to set an event on a device that doesn't support them. When getGraphicsEvent is active, it sets a gettingEvent field to TRUE, saves its environment into eventRho, and calls the getEvent callback. This callback is supposed to run an event loop, looking for user input. When it sees an event that it is supposed to handle, it calls a doMouseXXX or doKeybd function, and those translate the message into an R call to call the handler, and put the result in eventResult. The whole process can be aborted if the user interrupts (e.g. by hitting Esc in Rgui); in that case, another callback called onExit is called to clean up. Comments are welcome. Duncan Murdoch __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pausing between plots - waiting for graphics input
On Sat, 04 Dec 2004 20:13:01 +0100, Uwe Ligges [EMAIL PROTECTED] wrote : Duncan, I'm a bit late on this topic, but I'd like to bring up two points that I find inconvenient / buggy in the current behaviour of R-devel: 1) I'm never looking at the windows()'s title, hence I don't see that I should press/klick anything. Also, I'm almost never looking at the status line (and in SDI mode there is no status line anyway). So, I'd like to see a message in the Console as well. A fix for this one has been committed now. 2) Let's enter par(ask = TRUE) plot(1:10) and now switch back to the console and hit Esc (instead of going to the next plot) leaves the Windows device in the state asking for user interaction, but it does not respond to any interaction (as expected). Still working on this... Duncan __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist: simple legend options (PR#7400)
On Fri, 3 Dec 2004 03:08:11 + (UTC), Gabor Grothendieck [EMAIL PROTECTED] wrote : epurdom at stanford.edu writes: : : Full_Name: Elizabeth Purdom : Version: 1.9.1 : OS: Windows XP : Submission from: (NULL) (171.64.102.199) : : It would be nice if legend had the option of some default locations you could : choose instead of entering specific coordinates, like topleft, : topright,topcenter, etc. based on par(usr) coordinates. I know I've wanted : it so often I've made my own simple non-robust wrap-around, so I don't have to : remember or parse the xjust and yjust options necessary to make it work. Of : course there should be the option of entering in your own coordinates. Check out smartlengend in package gtools which is part of the gregmisc bundle. I agtee its a useful feature and it would be nice if that feature migrated to the base graphics. I've put both the title and keyword placement of the legend into legend() now, in R-devel. I was unaware of the smartlegend() function (which is actually in gplots); I've just now added an inset parameter like it has. The specification for the location is slightly different than smartlegend() uses. Because legend() handles the second parameter in a strange way and I didn't want to fiddle with that, I put the specification entirely in the first parameter: you say you want the legend at one of bottomright, bottom, bottomleft, left, topleft, top, topright, right, or center. This should be downloadable tomorrow from the CRAN mirrors. Duncan Murdoch __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RCmdr on Linux with R 2.0.0 over VNC can't use GLX
On Thu, 02 Dec 2004 10:06:56 -0500, Bob Kinney [EMAIL PROTECTED] wrote : Hello, I'm a admin over at Harvard University and I have quite a few users that use R predominately over VNC. In the past this has not been an issue, but after upgrading to R 2.0.0 they can no longer use RCmdr over VNC. When trying to use the package, they see the following: library(Rcmdr) Loading required package: tcltk Loading required package: zoo Loading required package: strucchange Loading required package: sandwich Loading required package: rgl RGL: GLX extension missing on server Error in firstlib(which.lib.loc, package) : error rgl_init Segmentation fault (core dumped) The same commands work fine when using a non-VNC display. Is it at all possible to modify RCmdr to not use GLX when it is unavailable? This looks like a problem with the rgl package rather than Rcmdr per se. I think it's probably not possible to modify rgl to do anything useful when GLX is unavailable, so what is needed is for rgl to fail more gracefully, or for it to be possible to load Rcmdr without rgl. For future reference: with most packages it's best to start by contacting the package maintainer, rather than posting to R-help or R-devel. I've cc'd the Rcmdr and rgl maintainers on this. You can see the maintainer listed by using library(help=Rcmdr) library(help=rgl) Duncan Murdoch __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
