Re: [Rd] Speeding up matrix multiplies
On 2010-08-24 05:37, Kasper Daniel Hansen wrote: On Mon, Aug 23, 2010 at 10:39 PM, Radford Neal wrote: On Aug 23, 2010, at 7:39 PM, Radford Neal wrote: In particular, all matrix x vector and vector x matrix products will in this version be done in the matprod routine, not the Fortran routine. And this is the right thing to do, since the time for the ISNAN check before calling the Fortan routine will be comparable to the time for the matrix multiply. So avoiding it will be desirable unless the Fortran routine is really, really faster than the C code in matprod. It is, many times in fact, if you use threaded BLAS on a multi-core machine and large matrices. Well, it can't get any faster than taking zero time. And even in that case, using the C code in matprod will slow the program down (compared to the existing version of R) by only about a factor of two. Of course, the real solution is to change the Fortran routine (which seems to be in src/extra/blas/blas.f, and isn't all that complicated) Nope - it can be external and BLAS standard doesn't handle NAs. OK. I see the problem if people can link in their own version of BLAS. I wonder if there is any way of telling whether they did that? Presumably many people will use the BLAS routine supplied with R, which could be made safe for NAs. Radford: this is highly platform dependent. For example, all OS X users use a multithreaded BLAS supplied by Apple. And I believe a multithreaded BLAS is used by Revolution R (all platforms). Allowing a plugin BLAS is (in my opinion) an essential advantage of R and is used by many people who care about high performance. How do I best achieve this on Ubuntu (10.04)? Göran Note that the BLAS version can be swapped after R has been compiled, so even if there is a way to tell what BLAS you are using (and I don't know if there is), it has to be a run-time check. Kasper __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Speeding up matrix multiplies
On 24 August 2010 at 09:13, Göran Broström wrote: | | On 2010-08-24 05:37, Kasper Daniel Hansen wrote: | > On Mon, Aug 23, 2010 at 10:39 PM, Radford Neal wrote: | >>> On Aug 23, 2010, at 7:39 PM, Radford Neal wrote: | >> | In particular, all matrix x vector and vector x matrix products will | in this version be done in the matprod routine, not the Fortran routine. | And this is the right thing to do, since the time for the ISNAN check | before calling the Fortan routine will be comparable to the time for | the matrix multiply. So avoiding it will be desirable unless the Fortran | routine is really, really faster than the C code in matprod. | >>> | >>> It is, many times in fact, if you use threaded BLAS on a multi-core machine | >>> and large matrices. | >> | >> Well, it can't get any faster than taking zero time. And even in that | >> case, using the C code in matprod will slow the program down (compared | >> to the existing version of R) by only about a factor of two. | >> | Of course, the real solution is to change the Fortran routine (which | seems to be in src/extra/blas/blas.f, and isn't all that complicated) | >>> | >>> Nope - it can be external and BLAS standard doesn't handle NAs. | >> | >> OK. I see the problem if people can link in their own version of BLAS. | >> I wonder if there is any way of telling whether they did that? Presumably | >> many people will use the BLAS routine supplied with R, which could be | >> made safe for NAs. | > | > Radford: this is highly platform dependent. For example, all OS X | > users use a multithreaded BLAS supplied by Apple. And I believe a | > multithreaded BLAS is used by Revolution R (all platforms). Allowing | > a plugin BLAS is (in my opinion) an essential advantage of R and is | > used by many people who care about high performance. | | How do I best achieve this on Ubuntu (10.04)? i) General answer: See Appendix 3.1 of the R Admin + Inst manual. ii) More specific answer: On Ubuntu, you get the 'revolution-mkl' package which gets you the otherwise commercial Intel MKL for free. iii) Even more specific answer: You get Goto BLAS via the gotoblas2-helper package by Ei-ji Nakama who also detailed how to use it on a recent r-sig-hpc post. Hth, Dirk | Göran | | > | > Note that the BLAS version can be swapped after R has been compiled, | > so even if there is a way to tell what BLAS you are using (and I don't | > know if there is), it has to be a run-time check. | > | > Kasper | > | > __ | > R-devel@r-project.org mailing list | > https://stat.ethz.ch/mailman/listinfo/r-devel | | __ | R-devel@r-project.org mailing list | https://stat.ethz.ch/mailman/listinfo/r-devel -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R forge : svn + ssh without key
Hi the list, I am trying to use R forge. I created an account. I put my project on R forge. I installed TortoiseSVN on my computer (windows). Then I did not manage to go through all the key process but I see in the R-Forge Manual that there is another option: "2. it is sufficient to use password authentication to write to the project repository (if you decided to do so please go to step 5)." So I try this new (for me) way. I create a folder on my computer. I successfully manage to update my local repository. But I do not manage to do a commit. Each time, I get the message Commit fail (details follow): authorization failed Any idea of what goes wrong? Christophe __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] No RTFM?
At 01:08 20/08/2010, Spencer Graves wrote:
What do you think about adding a "No RTFM"
policy to the R mailing lists? Per, "http://en.wikipedia.org/wiki/RTFM":
Spencer,
You raise an interesting point but the responses
to your post remind us that people (and indeed
whole cultures) are not all situated at the same
point on the continuum of directness between
"It's a cow, stupid" and "From this side it looks
not unlike a cow". The issue of what is offensive
is even more complex, I remember being taken to
task on another list for referring to a "rule of thumb".
The thing I find most rude on the list is not the
occasional abrupt postings by people who are
obviously having a bad day but the number of
fairly long exchanges which end unresolved as the
OP never bothers to post a conclusion and we
never know whether we solved his/her problem.
I am not asking for thanks but we would all
benefit from knowing how it all turned out.
The Ubuntu Forums and LinuxQuestions.org, for
instance, have instituted "no RTFM" policies to
promote a welcoming atmosphere.[8][9].
RTFM [and] "Go look on google" are two
inappropriate responses to a question. If you
don't know the answer or don't wish to help,
please say nothing instead of brushing off
someone's question. Politely showing someone how
you searched or obtained the answer to a
question is acceptable, even encouraged.
...
If you wish to remind a user to use search tools
or other resources when they have asked a
question you feel is basic or common, please be
very polite. Any replies for help that contain
language disrespectful towards the user asking
the question, i.e. "STFU" or "RTFM" are
unacceptable and will not be tolerated. Ubuntu Forums
Gavin Simpson and I recently provided examples
answering a question from "r.ookie" that had
previously elicited responses, ""You want us to
read the help page to you?" and "It yet again
appears that you are asking us to read the help pages for you."
I can appreciate the sentiment in
fortunes('rtfm'). In this case, however,
"r.ookie" had RTFM (and said so), but evidently
the manual was not sufficiently clear.
Best Wishes,
Spencer Graves
Michael Dewey
http://www.aghmed.fsnet.co.uk
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] small syntax suggestion
On August 23, 2010 01:27:24 pm Philippe Grosjean wrote: > They have to write such a code like this: > > if (x < -3) do_something > > That way, there is no ambiguity. Don't you think it's important to > write clear code, including by using spaces where it makes it easier > to read,... and less ambiguous, as you just realize? I fully agree, and I'm sure nobody here would dispute your advice. But we all sometimes make typos, and the point here is that the grammar's ambiguity makes for hard-to-find bugs. So, if I may focus us back on the OP's suggestion: "that R simply warn about an ambiguity" in 'if' statement's comparison involving '<-[0-9]'. It doesn't seem like an unreasonable suggestion. For comparison, GCC will do the same thing with C code when the '-Wparentheses' switch if assignment is used in a context where a truth value is expected. (E.g., 'if (x = 3)'.) It's been a very long time since I looked at Yacc and Lex source, but it looks like function 'xxif' in gram.y is the earliest place where we have a whole IF statement. AFAICT, this is evaluated in 'do_if' function of eval.c. There, the condition is evaluated via 'asLogicalNoNA'. Could 'do_if' instead use a function similar to 'asLogicalNoNA' but which issues a warning if the condition is an assignment? Davor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] small syntax suggestion
hi ted, philippe, and others---I agree with everything you write about good coding practice.none of us would be writing x<-3, even when we want to assign 3. we know better. we would at least use a space, if not a paren. alas, my suggestion is not so much for you. It is trying to spare novices that are just beginning to use R some unnecessary frustration. I bet that most of us have made this mistake at least once. to the extent that it requires a token "<-[0-9]" to recognize this, it could be an easy special case/warning/error. to the extent that it requires more, it is probably not worth the hassle. [I am a great fan of syntax checking. I am not a great fan of many but the simplest recycling rules (from 1 to N) BY DEFAULT. It's just asking for trouble.] regards, /iaw Ivo Welch (ivo.we...@brown.edu, ivo.we...@gmail.com) On Mon, Aug 23, 2010 at 4:27 PM, Philippe Grosjean wrote: > I tell to my students that it is very important (not only for legibility) to > place spaces between operands. They have to write such a code like this: > > if (x < -3) do_something > > That way, there is no ambiguity. Don't you think it's important to write > clear code, including by using spaces where it makes it easier to read,... > and less ambiguous, as you just realize? > > Best, > > Philippe Grosjean > > On 23/08/10 19:06, Davor Cubranic wrote: >> >> On 2010-08-23, at 6:15 AM, Barry Rowlingson wrote: >> >>> On Sun, Aug 22, 2010 at 4:33 PM, ivo welch wrote: I have found that my students often make the mistake of mixing up comparisons and assignments with negative numbers: if (x<-3) do_something; >>> >>> If you tell your students not to use '<-' for assignment, then they >>> can't make this mistake, because = for assignment has additional >>> restrictions on it: >> >> The students are trying to *compare* to a negative number, and trip on R's >> parsing of "<-". They could use '=' for assignment all they want (which I >> thought is being discouraged as a code style these days, BTW), and they'll >> still run into this problem. >> >> Davor >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] small syntax suggestion
On 24-Aug-10 14:42:11, Davor Cubranic wrote:
> On August 23, 2010 01:27:24 pm Philippe Grosjean wrote:
>> They have to write such a code like this:
>>
>> if (x < -3) do_something
>>
>> That way, there is no ambiguity. Don't you think it's important to
>> write clear code, including by using spaces where it makes it easier
>> to read,... and less ambiguous, as you just realize?
>
> I fully agree, and I'm sure nobody here would dispute your advice. But
> we all sometimes make typos, and the point here is that the grammar's
> ambiguity makes for hard-to-find bugs.
>
> So, if I may focus us back on the OP's suggestion: "that R simply warn
> about an ambiguity" in 'if' statement's comparison involving '<-[0-9]'.
> It doesn't seem like an unreasonable suggestion. For comparison, GCC
> will do the same thing with C code when the '-Wparentheses' switch if
> assignment is used in a context where a truth value is expected. (E.g.,
> 'if (x = 3)'.)
>
> It's been a very long time since I looked at Yacc and Lex source, but
> it looks like function 'xxif' in gram.y is the earliest place where we
> have a whole IF statement. AFAICT, this is evaluated in 'do_if'
> function of eval.c. There, the condition is evaluated via
> 'asLogicalNoNA'. Could 'do_if' instead use a function similar to
> 'asLogicalNoNA' but which issues a warning if the condition is an
> assignment?
>
> Davor
I'm a bit doubtful about the suggestion to "trap" this kind of
thing and issue warnings afterwards. It's not just in if() statements,
but anywhere where a logical value (as "x< -3") can validly be placed
and an assignment (as "x<-3") can validly be placed.
E.g.:
if(x<-3) print("yes") else print("no")
# [1] "yes"
because:
as.logical(x<-3)
# [1] TRUE
as.logical(x<-0)
# [1] FALSE
Or:
x <- -5
y <- c(5,4,3,2,1)
y[x<-3]
# [1] 3
x <- -5
y[x< -3]
# [1] 5 4 3 2 1
It may be all very well to say that such examples look silly
(in what context might anyone mean them seriously?), but
remember that the context of this discussion is precisely
where someone has written something they didn't mean, so
"might mean them seriously" is not a criterion.
As illustrated above, "x<-3" is valid in all sorts of syntactic
contexts.
The upshot is that, if such warnings are to be implemented
in any context -- not just "if()" -- where one wanted to
protect the innocent from their own fingers, then they would
be triggered *every time* the expression "x<-3" (or the like)
occurred! Of course one would need to be able to turn this
warning off, but if (e.g. as a precaution in a class of
beginnners) it were turned on, then there would be a huge
number of false positives filling up the screen in almost
any normal program. Reassuring for beginners!
So, on those grounds, I doubt its wisdom (and would prefer
giving the advice to bracket things, as in "x<(-3)". It's
a potential syntactic trap, but it's only one of many which
can be avoided in similar ways, and I think it's better to
teach avoidance rather than warning after the event.
Ted.
E-Mail: (Ted Harding)
Fax-to-email: +44 (0)870 094 0861
Date: 24-Aug-10 Time: 16:18:27
-- XFMail --
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] small syntax suggestion
On Tue, Aug 24, 2010 at 4:18 PM, Ted Harding wrote: > So, on those grounds, I doubt its wisdom (and would prefer > giving the advice to bracket things, as in "x<(-3)". It's > a potential syntactic trap, but it's only one of many which > can be avoided in similar ways, and I think it's better to > teach avoidance rather than warning after the event. Actually I think its better to teach _testing_ since it is hard to teach all the things to avoid - they're not all listed in Patrick Burns' R Inferno! (This particular problem *is* listed on page 49 of said marvellous tome). Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How do you make a formal "feature" request?
I can claim some responsibility for 3 sets of functions that are in "core R", well they are in packages, but then so is the plot function, but packages that are loaded automatically in a default installation of R. My piece of the responsibility is probably more the blame than credit (the credit goes to the R Core members who implemented the actual functions), but I will tell you the process, maybe it will work for you as well. In my case, all the functions started with me writing my own version of the function(s) and putting them into one of my packages. This included actual working code that did the basics of what I wanted and help pages detailing the goal/intent of the function(s) along with examples showing what it should do. Others started using some of these functions as well until they came to the attention of a member of the R core group. The fact that my functions were being used (or similar functionality) showed that there was interest beyond myself, the help pages showed clearly what was desired and the examples showed how it should work. But in each of those cases (I have many other functions that have not inspired anything in core R, but are still useful in my packages) there was something about my code or implementation that the R come member saw could be improved (a phrase along the lines of "ugliest I've seen" was used in one case) and generally in less than a week from when the! discussion started, there was a new function or functions in R-devel that did what my original functions tried to do, only better. In one case the R core function did everything that I had stated in the help file, ran all the examples correctly, but did not do one of the other things that I had tried privately, but never publicized (no bug, it did what the help page said, ran all my public examples). A bit later I presented the other situation and asked if it could be expanded to do that as well, and in just a few days the R-devel version (now in the regular version) worked for the new example as well. So, here is a success story of what you are trying to accomplish, I think the key elements were/are: Show that you are willing to put in some effort Clear documentation of what you want the function(s) to do Examples Enough usability that others use or are interested as well Hope this helps, -- Gregory (Greg) L. Snow Ph.D. Statistical Data Center Intermountain Healthcare greg.s...@imail.org 801.408.8111 > -Original Message- > From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r- > project.org] On Behalf Of Donald Winston > Sent: Saturday, August 21, 2010 9:41 AM > To: R Devel List > Subject: [Rd] How do you make a formal "feature" request? > > Who decides what features are in R and how they are implemented? If > there is someone here who has that authority I have this request: > > A report() function analogous to the plot() function that makes it easy > to generate a report from a table of data. This should not be in some > auxiliary package, but part of the core R just like plot(). As a long > time SAS user I cannot believe R does not have this. Please don't give > me any crap about Sweave, LaTex, and the "power" of R to roll your own. > You don't have to "roll your own" plot do you? Reports are no > different. If you don't agree do not bother me. If you agree then > please bring this request to the appropriate authorities for > consideration or tell me how to do it. > > Thanks. > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] No RTFM?
On Tue, Aug 24, 2010 at 3:28 PM, Michael Dewey wrote: > The thing I find most rude on the list is not the occasional abrupt postings > by people who are obviously having a bad day but the number of fairly long > exchanges which end unresolved as the OP never bothers to post a conclusion > and we never know whether we solved his/her problem. > I am not asking for thanks but we would all benefit from knowing how it all > turned out. The elephant in the room is, I think, the idea that maybe mailing lists have had their day - if R-help was a web-based forum then threads could be moderated by a group of privileged individuals, or rated by users. Basically, stackoverflow.com For anyone who has never visited: http://stackoverflow.com/questions/tagged/r Good answers get modded up, bad ones slide off. I'm considering unsubbing from r-help, and adding the R feed from stackoverflow to my RSS reader... Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] including DLL in a package
loosmart wrote: > > Good afternoon! > > It may seem trivial to some/most of You, but I found it difficult to > properly include a C++-based .dll into a package that I want to build for > usage in R. I read through the "Writing R extensions..." & "R > administration ..." instructions, but it seems I did not grasp the bigger > picture. > > The way I figured out to use the .dll in my package finally worked for > using that package from the R console, but it gives multiple error and > warning messages when running the RCMD check pkg command in the shell. > > What I did: I created the package skeleton via package.skeleton() > including a function that makes (1) a > library.dynam() call to a .dll and (2) a .C() call including the name of > the function in that DLL. Next, I run RCMD INSTALL pkg to install the > package and then created a /lib folder in the installed package containing > the .dll file. > I tried alternatives, e.g., (a) containing a /src folder in may package > skeleton with the .dll in it and/or (b) including zzz.R with a .First.lib > function including the library call but nothing worked out when > running the package check. > > help! thank You very much, MArtin > Hi Martin, I wrote a detailed example to a similar question on R-help. It can be viewed at: http://r.789695.n4.nabble.com/Writing-own-simulation-function-in-C-td1580190.html#a1580423 The source code mentioned in the post can be obtained from: http://gist.github.com/323498 The example was for C and not C++, but maybe it can help you get the package building correctly. Basically: 1) Write your C functions and put them in the /src directory of the package. 2) Write R wrappers for the C functions and put them in the /R directory along with a zzz.R that includes a .First.Lib() which calls library.dynam(). With these requirements satisfied both R CMD INSTALL and R CMD build --binary should be able to produce working packages. Example files that satisfy the points above are included in the source code I linked to. Hope this helps! -Charlie - Charlie Sharpsteen Undergraduate-- Environmental Resources Engineering Humboldt State University -- View this message in context: http://r.789695.n4.nabble.com/including-DLL-in-a-package-tp2336420p2336992.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] small syntax suggestion
In the mean time you could have student run the following code each time (put
it into .Rprofile or something) until they learn good coding practices:
testfunc <- function(expr, value, ok, visible) {
tmp <- deparse(expr)
if( grepl( '<- *[0-9.]+ *[])&|]', tmp ) ) {
warning(' You used "<-" in the above expression,\nit was
interpreted as an assignment\nif you wanted a comparison, use a space between
the "<" and the "-"')
}
TRUE
}
addTaskCallback( testfunc )
you might want to change the warning to cat (and add \n), or extend the regular
expression logic to other cases, or ...
But if nothing else getting the warning will reinforce that parens/spaces are a
good idea if only to avoid the computer complaining. The problem is I can
think of some false positives that I have not worked out yet how to avoid.
--
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111
> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> project.org] On Behalf Of ivo welch
> Sent: Tuesday, August 24, 2010 9:03 AM
> To: phgrosj...@sciviews.org
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] small syntax suggestion
>
> hi ted, philippe, and others---I agree with everything you write about
> good coding practice.none of us would be writing x<-3, even when
> we want to assign 3. we know better. we would at least use a space,
> if not a paren. alas, my suggestion is not so much for you. It is
> trying to spare novices that are just beginning to use R some
> unnecessary frustration. I bet that most of us have made this
> mistake at least once.
>
> to the extent that it requires a token "<-[0-9]" to recognize this, it
> could be an easy special case/warning/error. to the extent that it
> requires more, it is probably not worth the hassle.
>
> [I am a great fan of syntax checking. I am not a great fan of many
> but the simplest recycling rules (from 1 to N) BY DEFAULT. It's just
> asking for trouble.]
>
> regards,
>
> /iaw
>
> Ivo Welch (ivo.we...@brown.edu, ivo.we...@gmail.com)
>
>
>
>
> On Mon, Aug 23, 2010 at 4:27 PM, Philippe Grosjean
> wrote:
> > I tell to my students that it is very important (not only for
> legibility) to
> > place spaces between operands. They have to write such a code like
> this:
> >
> > if (x < -3) do_something
> >
> > That way, there is no ambiguity. Don't you think it's important to
> write
> > clear code, including by using spaces where it makes it easier to
> read,...
> > and less ambiguous, as you just realize?
> >
> > Best,
> >
> > Philippe Grosjean
> >
> > On 23/08/10 19:06, Davor Cubranic wrote:
> >>
> >> On 2010-08-23, at 6:15 AM, Barry Rowlingson wrote:
> >>
> >>> On Sun, Aug 22, 2010 at 4:33 PM, ivo welch
> wrote:
>
> I have found that my students often make the mistake of
> mixing up comparisons and assignments with negative numbers:
>
> if (x<-3) do_something;
> >>>
> >>> If you tell your students not to use '<-' for assignment, then they
> >>> can't make this mistake, because = for assignment has additional
> >>> restrictions on it:
> >>
> >> The students are trying to *compare* to a negative number, and trip
> on R's
> >> parsing of "<-". They could use '=' for assignment all they want
> (which I
> >> thought is being discouraged as a code style these days, BTW), and
> they'll
> >> still run into this problem.
> >>
> >> Davor
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >>
> >
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] save() object w/o all of the loaded environment
I have two packages, one that does the actual work (SC) and the other
a Tcl/Tk UI (SCUI) that invokes methods within the former. Within the
SCUI's invocation method, I save an object returned from SC, the
results of a long-running method.
Now the object is completely described by the SC package. Unfortunately,
any attempt to load the object (in a fresh R session) fails as below.
R> library(SC)
R> setwd("/path/to/results/")
R> load("sc-results.rda")
Loading Tcl/Tk interface ... done
Error: .onLoad failed in loadNamespace() for 'SCUI', details:
call: optiondb_add("*Notebook.borderWidth", 2, "widgetDefault")
error: could not find function "tcl"
That call (which adds resource to Tcl resource database) is made
inside SCUI. Loading tcltk package removes the problem.
R> library(tcltk)
R> load("sc-results.rda")
R> ls()
[1] "results"
But I would really prefer not to need to load tcltk at all just to
inspect/use the object, which contains nothing from SCUI anyway. Is
there a way to strip the unwanted UI prerequisite (tcltk and SCUI)
packages from the environment of the object prior/during save()?
R version 2.11.1 Patched (2010-06-03 r52201)
x86_64-apple-darwin9.8.0
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] require is to suggests as what is to imports?
Hi all, If a package suggests another package in its description, you can check it at runtime with requires. How do you do check if a package is available without loading it, if you only want to access one function in the package namespace. Thanks, Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] require is to suggests as what is to imports?
On Tue, 24 Aug 2010, Hadley Wickham wrote: Hi all, If a package suggests another package in its description, you can check it at runtime with requires. How do you do check if a package Well, not really as requires() can give an error, at least until 2.12.0 is out. So you need to wrap it in a try/tryCatch construct. is available without loading it, if you only want to access one function in the package namespace. You could use try/tryCatch on pkg::fun (which is what you need to do with require). It is difficult (and would be fragile since the details of metadata are definitely subject to change without notice) to ascertain what a namespace will contain/export without loading it. Thanks, Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] require is to suggests as what is to imports?
On 24 August 2010 at 15:40, Hadley Wickham wrote:
| Hi all,
|
| If a package suggests another package in its description, you can
| check it at runtime with requires. How do you do check if a package
| is available without loading it, if you only want to access one
| function in the package namespace.
I needed this a few days ago for a small package and resorted to this:
.packages <- as.character(installed.packages()[,1])
[...]
hasGputools <- function() {
any( "gputools" == .packages )
}
That way I get around Depends, Suggests and other thing that may impact the
running of 'R CMD check' and friends.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] require is to suggests as what is to imports?
isPackageInstalled <- function(package, ...) {
path <- system.file(package=package);
(path != "");
}
taken from R.utils (which also has a isPackageLoaded()).
/Henrik
On Tue, Aug 24, 2010 at 1:51 PM, Dirk Eddelbuettel wrote:
>
> On 24 August 2010 at 15:40, Hadley Wickham wrote:
> | Hi all,
> |
> | If a package suggests another package in its description, you can
> | check it at runtime with requires. How do you do check if a package
> | is available without loading it, if you only want to access one
> | function in the package namespace.
>
> I needed this a few days ago for a small package and resorted to this:
>
> .packages <- as.character(installed.packages()[,1])
>
> [...]
>
> hasGputools <- function() {
> any( "gputools" == .packages )
> }
>
> That way I get around Depends, Suggests and other thing that may impact the
> running of 'R CMD check' and friends.
>
> Dirk
>
> --
> Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Correction to section 1.1.2 of R Internals doc, on NAMED
I think the explanation of the NAMED field in the R Internals document is incorrect. In Section 1.1.2, it says: The named field is set and accessed by the SET_NAMED and NAMED macros, and take values 0, 1 and 2. R has a `call by value' illusion, so an assignment like b <- a appears to make a copy of a and refer to it as b. However, if neither a nor b are subsequently altered there is no need to copy. What really happens is that a new symbol b is bound to the same value as a and the named field on the value object is set (in this case to 2). When an object is about to be altered, the named field is consulted. A value of 2 means that the object must be duplicated before being changed. (Note that this does not say that it is necessary to duplicate, only that it should be duplicated whether necessary or not.) A value of 0 means that it is known that no other SEXP shares data with this object, and so it may safely be altered. A value of 1 is used for situations like dim(a) <- c(7, 2) where in principle two copies of a exist for the duration of the computation as (in principle) a <- `dim<-`(a, c(7, 2)) but for no longer, and so some primitive functions can be optimized to avoid a copy in this case. The implication of this somewhat confusing explanation is that values of variables may have NAMED of 0, and that NAMED will be 1 only briefly, during a few operations like dim(a) <- c(7,2). But from my reading of the R source, this is wrong. It seems to me that NAMED will quite often be 1 for extended periods of time. For instance, after a <- c(7,2), the value stored in a will have NAMED of 1. If at this point a[2] <- 0 is executed, no copy is made, because NAMED is 1. If b <- a is then executed, the same value will be in both a and b, and to reflect this, NAMED is incremented to 2. If a[2] <- 0 is executed at this point, a copy is made, since NAMED is 2. Essentially, NAMED is a count of how many variables reference a value, except it's not necessarily accurate. First, once NAMED reaches 2, it doesn't get incremented any higher. Second, no attempt is made to decrement NAMED when a variable ceases to refer to a value. So the end result is that a copy needs to be made when changing a variable whose value has NAMED of 2, since it's possible that some other variable references the same value. There seems to be some confusion in the R source on this. In the do_for procedure, the value for the for loop variable is set up with NAMED being 0, though according to my explanation above, it ought to be set up with NAMED of 1. A bug is avoided here only because the procedures for getting values from variables check if NAMED is 0, and if so fix it up to being 1, which is the minimum that it ought to be for a value that's stored in a variable. Is my understanding of this correct? Or have I missed something? Radford Neal __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RCMD CHECK and non-methods
I recently moved a function 'subset.with.warning' into the 'mvbutils' package
(a version not yet on CRAN). When I tried RCMD CHECK, I got this warning:
* checking S3 generic/method consistency ... WARNING
subset:
function(x, ...)
subset.with.warning:
function(x, cond, mess.head, mess.cond, row.info, sub)
See section 'Generic functions and methods' of the 'Writing R
Extensions'
manual.
I know that S3 method arguments need to be compatible with arguments of the
generic. However, 'subset.with.warning' is deliberately not a registered S3
method, and its USAGE section doesn't include a \method{generic}{class}
statement. I couldn't see anything in "R Extensions" that says "don't do this",
so I'm wondering:
- should this really be a NOTE not a WARNING (or nothing at all)?
- if not, shouldn't there be a more explicit statement to the effect that "if
R decides it's a method, then it damned well is a method, whether you think it
is or not"?
- and if so, should there also be a check for functions that look like methods
but aren't registered and declared as such?
My preference would be for the first, FWIW. Admittedly, just because I didn't
register 'subset.with.warning' as an S3 method, that won't stop 'subset' from
trying to use it if it ever encounters an object of class "with.warning". It's
a risk that I'm happy to take, though CRAN might not be...
I made the warning go away by adding a '...' argument to the end of
'subset.with.warning', but that's not pretty.
Mark Bravington
CSIRO
Hobart
Australia
> sessionInfo()
R version 2.11.1 Patched (2010-06-30 r52418)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_Australia.1252 LC_CTYPE=English_Australia.1252
LC_MONETARY=English_Australia.1252 LC_NUMERIC=C
[5] LC_TIME=English_Australia.1252
attached base packages:
[1] grDevices tools tcltk stats graphics utils methods base
other attached packages:
[1] ad_1.0 chstuff_1.0handy2_1.2 tweedie_2.0.2 statmod_1.4.1
handy_1.1 debug_1.2.3mvbutils_2.5.2
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
