Re: [Rd] typo or stale info in qr man
> Wojciech Musial (Voitek) > on Mon, 24 Oct 2016 15:07:55 -0700 writes: > man for `qr` says that the function uses LINPACK's DQRDC, while it in > fact uses DQRDC2. which is a modification of LINPACK's DQRDC. But you are right, and I have added to the help file (and a tiny bit to the comments in the Fortran source). When this change was done > 20 years ago, it was still hoped that the numerical linear algebra community or more specifically those behind LAPACK would eventually provide this functionality with LAPACK (and we would then use that), but that has never happened according to my knowledge. Thank you for the 'heads up'. Martin Maechler ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ACM license link broken
> Ben Bolker > on Mon, 24 Oct 2016 19:26:35 -0400 writes: > The URL listed under > https://svn.r-project.org/R/trunk/share/licenses/license.db for the ACM > license, > http://www.acm.org/publications/policies/softwarecrnotice , > gives a 404 error. I think this should be replaced by > https://www.acm.org/publications/policies/software-copyright-notice > ? For what it's worth, the original page did exist as recently as 5 > April 2016: > https://web.archive.org/web/20160405100845/http://www.acm.org/publications/policies/softwarecrnotice/ > Suggestions for where/to whom to report this? R-bugzilla? > c...@r-project.org? Here? Thank you, Ben! "Here" is perfect for such a small change. I have fixed the sources, including those for 'R 3.2.2 RC' (RC := Release candidate; release in ca 5 days) (R-bugzilla would have been fine, too. It's slightly more work for you and R core, but in general things there should less easily fall between the cracks) Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] typo or stale info in qr man
And that missing functionality is that Linpack/Lapack routines do not return
rank and have a different style of pivoting? For other aspects, the
user-interface is very similar in dqrdc2 in R and in dqrdc in Linpack. Another
difference seems to be that the final pivoting reported to the user is
different: R keeps the original order except for aliased variables, but Linpack
makes either wild shuffling or no pivoting at all. I haven't looked at dqpq3 in
Lapack, but it appears to return no rank either (don't know about shuffling the
columns). It seems that using Linpack dqrdc directly is not always compatible
with dqrdc2 of R although it returns similar objects. That is, when packing up
the Linpack function to produce an object with same items as qr.default (qr,
rank, qraux, pivot, class "qr"), the result object may not yield similar
results in base::qr.fitted, base::qr.resid etc as base::qr.default result (but
I haven't had time for thorough testing).
This is how I tried to do the packing (apologies for clumsy coding):
SEXP do_QR(SEXP x, SEXP dopivot)
{
/* set up */
int i;
int nr = nrows(x), nx = ncols(x);
int pivoting = asInteger(dopivot);
SEXP qraux = PROTECT(allocVector(REALSXP, nx));
SEXP pivot = PROTECT(allocVector(INTSXP, nx));
/* do pivoting or keep the order of columns? */
if (pivoting)
memset(INTEGER(pivot), 0, nx * sizeof(int));
else
for(i = 0; i < nx; i++)
INTEGER(pivot)[i] = i+1;
double *work = (double *) R_alloc(nx, sizeof(double));
int job = 1;
x = PROTECT(duplicate(x));
/* QR decomposition with Linpack */
F77_CALL(dqrdc)(REAL(x), &nr, &nr, &nx, REAL(qraux),
INTEGER(pivot), work, &job);
/* pack up */
SEXP qr = PROTECT(allocVector(VECSXP, 4));
SEXP labs = PROTECT(allocVector(STRSXP, 4));
SET_STRING_ELT(labs, 0, mkChar("qr"));
SET_STRING_ELT(labs, 1, mkChar("rank"));
SET_STRING_ELT(labs, 2, mkChar("qraux"));
SET_STRING_ELT(labs, 3, mkChar("pivot"));
setAttrib(qr, R_NamesSymbol, labs);
SEXP cl = PROTECT(allocVector(STRSXP, 1));
SET_STRING_ELT(cl, 0, mkChar("qr"));
classgets(qr, cl);
UNPROTECT(2); /* cl, labs */
SET_VECTOR_ELT(qr, 0, x);
SET_VECTOR_ELT(qr, 1, ScalarInteger(nx)); /* not really the rank,
but no. of columns */
SET_VECTOR_ELT(qr, 2, qraux);
SET_VECTOR_ELT(qr, 3, pivot);
UNPROTECT(4); /* qr, x, pivot, qraux */
return qr;
}
cheers, Jari Oksanen
From: R-devel on behalf of Martin Maechler
Sent: 25 October 2016 11:08
To: Wojciech Musial (Voitek)
Cc: R-devel@r-project.org
Subject: Re: [Rd] typo or stale info in qr man
> Wojciech Musial (Voitek)
> on Mon, 24 Oct 2016 15:07:55 -0700 writes:
> man for `qr` says that the function uses LINPACK's DQRDC, while it in
> fact uses DQRDC2.
which is a modification of LINPACK's DQRDC.
But you are right, and I have added to the help file (and a tiny
bit to the comments in the Fortran source).
When this change was done > 20 years ago, it was still hoped
that the numerical linear algebra community or more specifically
those behind LAPACK would eventually provide this functionality
with LAPACK (and we would then use that),
but that has never happened according to my knowledge.
Thank you for the 'heads up'.
Martin Maechler
ETH Zurich
__
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] typo or stale info in qr man
On 25 Oct 2016, at 10:08 , Martin Maechler wrote: >> Wojciech Musial (Voitek) >>on Mon, 24 Oct 2016 15:07:55 -0700 writes: > >> man for `qr` says that the function uses LINPACK's DQRDC, while it in >> fact uses DQRDC2. > > which is a modification of LINPACK's DQRDC. > > But you are right, and I have added to the help file (and a tiny > bit to the comments in the Fortran source). > > When this change was done > 20 years ago, it was still hoped > that the numerical linear algebra community or more specifically > those behind LAPACK would eventually provide this functionality > with LAPACK (and we would then use that), > but that has never happened according to my knowledge. > I had some thoughts on this recently and resolved that the base issue is that R wants successive (Gram/Schmidt-type) orthogonalization of the design matrix, not really QR as such. The LINPACK QR routine happens to work by orthogonalization, but it is far from the only way of doing QR, and most likely not the "best" one (speedwise/precisionwise) if a QR decompositiion as such is the target. (Pivoting is only part of the story) lm() and associates (notably anova()) relies so much on successive terms being orthogonalized that method="qr" really is a misnomer. For much the same reason, it really is too much to expect that numerical analysts would enforce orthogonality features on a general QR-decomposer. I suppose that if we want to be free of LINPACK, we may need to step back and write our own orthogonalization routines based on other routines in LAPACK or on the BLAS directly. -pd > Thank you for the 'heads up'. > > Martin Maechler > ETH Zurich > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Support for signing R packages with GPG
Thanks Jeroen. The R Foundation has recently formed a working group to
look into package authentication. There are basically two models. One
is the GPG based model you describe; the other is to use X.509 as
implemented in the PKI package. It's not yet clear which way to go but
we are thinking about it.
Martyn
On Sun, 2016-10-23 at 18:37 +0200, Jeroen Ooms wrote:
> I would like to propose adding experimental support for including a
> PGP signature in R source packages. This would make it possible to
> verify the identity of the package author and integrity of the
> package
> sources.
>
> There are two ways to implement this. Assuming GnuPG is on the PATH,
> the CMD build script could call:
>
> gpg --clearsign MD5 -o MD5.gpg
>
> Alternatively the 'gpg' R package provides a more portable method via
> the gpgme C library. This method works on Windows / macOS as well.
>
> writeLines(gpg::gpg_sign("MD5"), "MD5.gpg")
>
> Attached is an example implementation of the latter (also available
> at
> https://git.io/vPb9G) which has been tested with several versions of
> GnuPG. It exposes an optional flag for CMD build, i.e:
>
> R CMD build somepkg --sign
> R CMD build somepkg --sign=jeroen.o...@stat.ucla.edu
>
> The --sign flag creates a signature for the MD5 file [1] in the
> source
> package and saves it as MD5.gpg (similar to a Debian 'Release.gpg'
> file [2]). Obviously the package author or build server needs to have
> a suitable private key in the local keyring.
>
>
> ## Signature verification
>
> Once R supports signed packages, we can develop a system to take
> advantage of such signatures. The verification itself can easily be
> implemented via 'gpg --verify' or via gpg::gpg_verify() and could be
> performed without changes in R itself. The difficult part in GPG
> comes
> from defining which peers should be trusted.
>
> But even without a 'web of trust' there are several ways one can
> immediately take advantage of signatures. For example, when a
> installing a package update or dev-version of a package, we can
> verify
> that the signature of the update matches that of the currently
> installed package. This would prevent the type of attacks where an
> intermediate party pushes a fake malicious update for a popular R
> package via e.g. a hacked CRAN mirror.
>
> Eventually, CRAN could consider allowing signatures as a secure
> alternative to confirmation emails, and signing packages on the build
> servers with a CRAN GPG key, similar to Debian repositories. For now,
> at least establishing a format for (optionally) signing packages
> would
> be a great first step.
>
>
> [1] Eventually we should add SHA256 and SHA256.sig in addition to MD5
> [2] https://cran.r-project.org/web/packages/gpg/vignettes/intro.html#
> debian_example
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel---
This message and its attachments are strictly confidenti...{{dropped:8}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] BUG?: On Linux setTimeLimit() fails to propagate timeout error when it occurs (works on Windows)
setTimeLimit(elapsed=1) causes a timeout error whenever a call takes
more than one second. For instance, this is how it works on Windows
(R 3.3.1):
> setTimeLimit(elapsed=1)
> Sys.sleep(10); message("done")
Error in Sys.sleep(10) : reached elapsed time limit
Also, the error propagates immediately and causes an interrupt after ~1 second;
> system.time({ Sys.sleep(10); message("done") })
Error in Sys.sleep(10) : reached elapsed time limit
Timing stopped at: 0.01 0 1.02
This works as expected. However, on Linux (R 3.3.1 but also e.g.
2.11.0, 2.15.3) I get:
> setTimeLimit(elapsed=1)
> system.time({ Sys.sleep(10); message("done") })
Error in Sys.sleep(10) : reached elapsed time limit
Timing stopped at: 0 0 10.01
Note how the timeout error is signaled, but for some reason, it does
not interrupt the Sys.sleep(10) call until after it finishes after 10
seconds. If you change to Sys.sleep(60) it will take 1 minute. Note
that the following print("done") is not called, so the timeout error
does propagate immediately after Sys.sleep() but not before / during.
This looks like a bug to me. Can anyone on macOS confirm whether this
is also a problem there or not?
/Henrik
> sessionInfo()
R version 3.3.1 (2016-06-21)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows XP x64 (build 2600) Service Pack 3
> sessionInfo()
R version 3.3.1 (2016-06-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.1 LTS
> sessionInfo()
R version 2.11.0 (2010-04-22)
x86_64-unknown-linux-gnu
sessionInfo()
R version 2.15.3 (2013-03-01)
Platform: x86_64-unknown-linux-gnu (64-bit)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] BUG?: On Linux setTimeLimit() fails to propagate timeout error when it occurs (works on Windows)
On 10/25/2016 9:44 PM, Henrik Bengtsson wrote:
setTimeLimit(elapsed=1) causes a timeout error whenever a call takes
more than one second. For instance, this is how it works on Windows
(R 3.3.1):
setTimeLimit(elapsed=1)
Sys.sleep(10); message("done")
Error in Sys.sleep(10) : reached elapsed time limit
Also, the error propagates immediately and causes an interrupt after ~1 second;
system.time({ Sys.sleep(10); message("done") })
Error in Sys.sleep(10) : reached elapsed time limit
Timing stopped at: 0.01 0 1.02
This works as expected. However, on Linux (R 3.3.1 but also e.g.
2.11.0, 2.15.3) I get:
setTimeLimit(elapsed=1)
system.time({ Sys.sleep(10); message("done") })
Error in Sys.sleep(10) : reached elapsed time limit
Timing stopped at: 0 0 10.01
Note how the timeout error is signaled, but for some reason, it does
not interrupt the Sys.sleep(10) call until after it finishes after 10
seconds. If you change to Sys.sleep(60) it will take 1 minute. Note
that the following print("done") is not called, so the timeout error
does propagate immediately after Sys.sleep() but not before / during.
This looks like a bug to me. Can anyone on macOS confirm whether this
is also a problem there or not?
> setTimeLimit(elapsed=1)
> system.time({ Sys.sleep(10); message("done") })
Error in Sys.sleep(10) : reached elapsed time limit
Timing stopped at: 0.003 0.004 0.978
>
> sessionInfo()
R version 3.3.1 (2016-06-21)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.11.6 (El Capitan)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils
[5] datasets methods base
loaded via a namespace (and not attached):
[1] rsconnect_0.5 tools_3.3.1
Error: reached elapsed time limit
/Henrik
sessionInfo()
R version 3.3.1 (2016-06-21)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows XP x64 (build 2600) Service Pack 3
sessionInfo()
R version 3.3.1 (2016-06-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04.1 LTS
sessionInfo()
R version 2.11.0 (2010-04-22)
x86_64-unknown-linux-gnu
sessionInfo()
R version 2.15.3 (2013-03-01)
Platform: x86_64-unknown-linux-gnu (64-bit)
__
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
