Re: [Rd] matrix multiplication speed R
On Mon, 9 May 2011, Sharpie wrote: aftar wrote: Hi Can we use BLAS in R X64 for windows? Regards Aftar You are already using BLAS in R as R includes its own BLAS library. On Windows the 64-bit DLL is located at R_HOME\bin\x64\Rblas.dll. If you are asking about swapping that out for an optimized BLAS, you will probably have to: 1. Obtain and build an optimized BLAS such as ATLAS, Goto BLAS or Intel MKL 2. Build your own copy of R from source that links against this new blas. If there is a simpler way, I'm sure someone will correct me. All you need is a copy of Rblas.dll containing the BLAS you wish to use. You do not need to rebuild anything else in R. Some (not recent) such Rblas.dll are made available: see the R for Windows documentation. In addition, Ei-ji Nakama has posted (on this list) how to use the Goto BLAS on x64 Windows. - Charlie Sharpsteen Undergraduate-- Environmental Resources Engineering Humboldt State University -- View this message in context: http://r.789695.n4.nabble.com/matrix-multiplication-speed-R-tp3217257p3510979.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 -- 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] matrix multiplication speed R
Hi Can we use BLAS in R X64 for windows? Regards Aftar -- View this message in context: http://r.789695.n4.nabble.com/matrix-multiplication-speed-R-tp3217257p3509596.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
[Rd] Which higher-order function
Would it be appropriate to add a Which higher-order function?
Which <- function(f, x) {
ind <- vapply(x, f, logical(1))
!is.na(ind) & ind
}
Then Filter would be:
Filter <- function(f, x) x[Which(f, x)]
I think the use of vapply is slightly better than the current
as.logical(sapply(x, f)) because it will return a more informative
error message if the predicate doesn't return a logical vector of the
correct length.
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
[Rd] Debugging warnings
Hi all,
One thing that's currently a little tricky in R is debugging warnings.
One solution is to turn them into errors and then use the usual error
tracking mechanisms (e.g. options(error = recover)). But it should be
possible to use withCallingHandlers to provide more flexibility. The
function below works, but I'm wondering if there's a more elegant way
to figure out the correct frame to evaluate the action in - I'm
currently counting back one from where warning was called.
on_warning <- function(action, code) {
q_action <- substitute(action)
withCallingHandlers(code, warning = function(c) {
for(i in seq_len(sys.nframe())) {
f <- as.character(sys.call(i)[[1]])
if (f == "warning") break;
}
eval(q_action, sys.frame(i - 1))
})
}
x <- 1
f <- function() {
x <- 2
g()
}
g <- function() {
x <- 3
warning("Leaving g")
}
on_warning(browser(), f())
on_warning(print(ls()), f())
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
[Rd] Time-machine typo
Just noticed this in R 2.13.0, it is also still present in R-devel in SVN: %%% Rd.sty ... Style for printing the R manual %%% Part of the R package, http://www.R-project.org %%% Copyright (C) 2003-20010 The R Foundation ^ Very forward-looking ... Dirk -- Gauss once played himself in a zero-sum game and won $50. -- #11 at http://www.gaussfacts.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Time-machine typo
Indeed, Dirk, but realistic, I might add! BTW, I enjoyed some of the "Gaussian Facts". My favorite: It only takes Gauss 4 minutes to sing "Aleph-Null Bottles of Beer on the Wall". Best, Ravi. --- Ravi Varadhan, Ph.D. Assistant Professor, Division of Geriatric Medicine and Gerontology School of Medicine Johns Hopkins University Ph. (410) 502-2619 email: rvarad...@jhmi.edu -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Dirk Eddelbuettel Sent: Tuesday, May 10, 2011 11:27 AM To: R-devel org Subject: [Rd] Time-machine typo Just noticed this in R 2.13.0, it is also still present in R-devel in SVN: %%% Rd.sty ... Style for printing the R manual %%% Part of the R package, http://www.R-project.org %%% Copyright (C) 2003-20010 The R Foundation ^ Very forward-looking ... Dirk -- Gauss once played himself in a zero-sum game and won $50. -- #11 at http://www.gaussfacts.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
Re: [Rd] cerr and cout not working calling c++ from R
Just a short follow up to the list.
It turns out that the strange behavior I was experiencing had nothing to do
with cout and cerr, but ostreams in general. For some reason, at a minimum,
the operators:
ostream& operator<< (long& val );
ostream& operator<< (double& val );
were not functioning properly and were causing my problem.
To get around this, I simply had to convert types like these to strings
before passing them into the ostreams with << operators.
I don't know if this was due to a mistake in which libraries I linked to or
which headers are being read when I make my project. However, it seems that
I have ruled out the possibility of this being unique to 64-bit longs as the
doubles are standard types on any machine. Anyway, I appreciate everyone's
help, and if anyone has trouble with this type of thing in the future, a
simple couple of functions I used to convert the long or double values to
strings were:
string getStringFromDouble(double d)
{
char*doubleValue = (char*)calloc(1000,sizeof(char));
sprintf(doubleValue,"%f",d);
string returnValue(doubleValue);
free(doubleValue);
return(returnValue);
}
string getStringFromLong(long i)
{
char*intValue = (char*)calloc(1000,sizeof(char));
sprintf(intValue,"%ld",i);
string returnValue(intValue);
free(intValue);
return(returnValue);
}
I'm not sure why this was necessary, but it solves my issue.
Thanks again for all the help--I learned a lot about streams and stream
buffers in the process.
Thanks,
Sean
On 5/8/11 12:56 AM, "Sean Robert McGuffee" wrote:
> Thanks, Simon,
> That link may prove to be very useful. I think what I can do is make a
> similar version of a buffer to one in that example and then have it
> conditionally write to Rprintf or cout and/or REprintf or cerr,
> depending on whether I'm running a c++ program from the command line
> or launching a function from R. Then I can just replace all of my cout
> and cerr terms with this new buffer or two in global space. Before I
> call those functions in R, I'll set them to write to R before I launch
> any code that uses it. This should allow me to leave all my code
> exactly how it is with a minor replacement of one or two terms for
> another. So, if the errors in my performance are only caused by
> writing to cout and/or cerr from R, then they can be completely
> avoided by all of those substitutions writing to Rprintf and REprintf.
> This seems like it is going to work exactly as I'm hoping.
> Thanks again,
> Sean
>
> On Sat, May 7, 2011 at 6:13 PM, Simon Urbanek
> wrote:
>> Sean,
>>
>> just to clarify - this is not about something "not working" or any leaks.
>> cout/cerr do exactly what they are supposed to, it's just in most cases not
>> what you want. The main reason is that R does not necessarily use
>> stdin/stdout so cout/cerr may have nothing to do with the R console output.
>> The effects of using cout/cerr vary by the actual setup in which you run R as
>> I was explaining earlier. In the most complex setup (default for interactive
>> R on OS X, actually) you have:
>>
>> 1) stdin/stdout/stderr - those are entirely independent of the R console
>> 2) ReadConsole/WriteConsole - this is how R interacts with the console
>> 3) C++ cin/cout/cerr - by default a buffered link to stdin/out/err
>>
>> So as you see the reason for cout being strongly discouraged is simply
>> because it has no relationship with R and produces no output in R itself.
>> What makes things seemingly puzzling is that some UI implementations in R use
>> stdin/out/err in Read/WriteConsole, so suddenly you are dealing with three
>> independent streams and buffers (e.g., cout, WriteCondole and stdout all
>> eventually ending in the same place but at different times). If your final
>> output is a tty then they all get synchronized at the end into the same tty,
>> but since each of them has a buffer, the result is random at the best.
>>
>> Due to the interactions, you must be careful not to mess things up with any
>> additional low-level stream manipulations. For example, the R.app GUI doesn't
>> use stdout/err for console at all, since it is driven by text views instead,
>> so it uses exclusively Read/WriteConsole (and so does the Windows GUI).
>> However, it also monitors stdout/err for external output (e.g. from system())
>> and uses two separate pipes to merge that output into the console with
>> different colors. So if you were to start to mess with the descriptors for
>> stdout/err you could break that setup.
>>
>> That said, if you want a solution for C++ you should simply write a stream or
>> buffer that uses Rprintf/REprintf for output. I was assuming that others have
>> done that before, but Dirk's response suggests that it is not as common. If
>> you choose to do it, you may find this link helpful:
>> http://groups.google.com/group/comp.lang.c++/msg/1d941c0f26ea0d81
>>
>> Cheers,
>> Simon
>>
>>
>> On May 7, 2011, at 12:42 AM, Sean Robert McGuffee wrote:
>>
>>> This is
Re: [Rd] Fortran Symbol Name not in Load Table
vioravis wrote: > > I used the DLL export viewer to what is the table name being exported. It > is showing as VALUEAHROPTIMIZE_. This is the name of the function we have > used plus the underscore. > > Is there any other reason for the function not getting recognized??? > Thanks. > Which compiler are you using? Which version of R? - Charlie Sharpsteen Undergraduate-- Environmental Resources Engineering Humboldt State University -- View this message in context: http://r.789695.n4.nabble.com/Fortran-Symbol-Name-not-in-Load-Table-tp3508719p3513005.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] anova.lm fails with test="Cp"
For unknown sigma^2, a version that is a modification of AIC may be preferred, i.e. n log(RSS/n) + 2p - n I notice that this is what is given in Maindonald and Braun (2010) Data Analysis & Graphics Using R, 3rd edition. Cf: Venables and Ripley, MASS, 4th edn, p.174. V&R do however stop short of actually saying that Cp should be modified in the same way as AIC when sigma^2 has to be estimated. Better still, perhaps, give the AIC statistic. This would make the output consistent with dropterm(), drop1() and add1(). Or if Cp is to stay, allow AIC as a a further "test". John Maindonald email: john.maindon...@anu.edu.au phone : +61 2 (6125)3473fax : +61 2(6125)5549 Centre for Mathematics & Its Applications, Room 1194, John Dedman Mathematical Sciences Building (Building 27) Australian National University, Canberra ACT 0200. http://www.maths.anu.edu.au/~johnm On 08/05/2011, at 6:15 PM, peter dalgaard wrote: > > On May 8, 2011, at 09:25 , John Maindonald wrote: > >> Here is an example, modified from the help page to use test="Cp": >> >> >>> fit0 <- lm(sr ~ 1, data = LifeCycleSavings) >>> fit1 <- update(fit0, . ~ . + pop15) >>> fit2 <- update(fit1, . ~ . + pop75) >>> anova(fit0, fit1, fit2, test="Cp") >> Error in `[.data.frame`(table, , "Resid. Dev") : >> undefined columns selected > > Yes, the "Resid. Dev" column is only there in analysis of deviance tables. > For the lm() case, it looks like you should have "RSS". > > This has probably been there "forever". Just goes to show how often people > use these things... > > Also, now that I'm looking at it, are we calculating it correctly in any > case? We have > > cbind(table, Cp = table[, "Resid. Dev"] + 2 * scale * > (n - table[, "Resid. Df"])) > > whereas all the references I can find have Cp=RSS/MS-N+2P, so the above would > actually be scale*Cp+N. > > > -- > Peter Dalgaard > Center for Statistics, Copenhagen Business School > Solbjerg Plads 3, 2000 Frederiksberg, Denmark > Phone: (+45)38153501 > Email: pd@cbs.dk Priv: pda...@gmail.com > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Reference Classes copy(shallow=FALSE) unexpected behavior.
Dear all, I've just discovered the 'Reference Classes'. In a previous attempt ---a year ago--- to re-implement in a Object Oriented fashion the AMORE package using S4 classes I strongly felt the need of such capability. It's great to have the Reference Classes now available. Along with the discovery of the Rcpp package, this new programming paradigm has boosted my interest in rewriting that package. Nevertheless, I have found a surprising behavior in the $copy(shallow=FALSE) method. Let's have a look at the results which I believe are self-explanatories. The ".Data" field is a list which contains objects from the "Con" class ---connections for what is worth---. > p$copy(shallow=FALSE) -> k > p$.Data [[1]] An object of class "Con" [[2]] An object of class "Con" [[3]] An object of class "Con" > k$.Data [[1]] An object of class "Con" [[2]] An object of class "Con" [[3]] An object of class "Con" As you can see the elements of both lists share the memory addresses while I was expecting the shallow=FALSE to perform a deep copy and create copies of those objects as well. As I'm new with reference classes this causes me a lot of confussion. Is this a bug, is this a feature? Any insights about the matter are welcome Thanks in advance -M -- Manuel Castejón Limas University of León, Spain manuel.caste...@unileon.es [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fortran Symbol Name not in Load Table
On 11-05-09 9:28 PM, vioravis wrote: I used the DLL export viewer to what is the table name being exported. It is showing as VALUEAHROPTIMIZE_. This is the name of the function we have used plus the underscore. I believe R will be looking for the lower case version of that name, which is what gfortran would produce. Duncan Murdoch Is there any other reason for the function not getting recognized??? Thanks. -- View this message in context: http://r.789695.n4.nabble.com/Fortran-Symbol-Name-not-in-Load-Table-tp3508719p3510758.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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Fortran Symbol Name not in Load Table
Thank you Sharpie and Duncan. I am using Compaq Visual Fortran compiler on a Windows machine. I tried with all small letters for the function names and created the DLLs. But somehow the DLL created only had all CAPS. But the DLL worked when I changed the function name to myxmean. Not really sure what changed but it worked fine :) Ravi -- View this message in context: http://r.789695.n4.nabble.com/Fortran-Symbol-Name-not-in-Load-Table-tp3508719p3513909.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
