Re: [Rd] capabilities() and non-catchable messages
Do you have DISPLAY set pointing to an X11 server you do not have
access to? It seems so. The solution is to set your X11 settings
properly.
This is coming from Xlib (XOpenDisplay, I believe) and so is not an R
error or warning, and is not output on an R connection but on a C file.
On Mon, 20 Jun 2005, Henrik Bengtsson wrote:
> Just for the record (not a request for fix) and an ad hoc workaround if
> anyone needs it:
>
> REASON:
> Running an R script as a plugin on a remote Suse Linux 8.2 with R v2.1.0
> (2005-04-18), I have noticed that capabilities() generates (to standard
> error)
>
> Xlib: connection to "base:0.0" refused by server
> Xlib: Client is not authorized to connect to Server
>
> which cannot be caught by tryCatch();
>
> tryCatch({
> print(capabilities());
> }, condition=function(c) {
> cat("Condition caught:\n");
> str(c);
> })
>
> because it is not a 'condition' (error or warning).
>
> CONTEXT:
> Since source() calls capabilities("iconv") this messages always show up.
> My R plugin loads custom code using source() and since the standard
> error from the plugin is checked for messages, the host system
> interprets this as if something problematic has occured.
>
> WORKAROUND:
> The workaround that I use now is to redefine capabilities() temporarily
> (since I do not need "iconv" support):
>
> orgCapabilities <- base::capabilities;
> basePos <- which(search() == "package:base"));
> assign("capabilities", function(...) FALSE, pos=basePos);
>
> source()
>
> basePos <- which(search() == "package:base"));
> assign("capabilities", orgCapabilities, pos=basePos);
> rm(orgCapabilities)
>
> Cheers
>
> Henrik
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] efficiency of sample() with prob.
Dear list, A while ago, Vadim asked opinions on improving efficiency of sample() with prob, e.g. sample with replacement with weight. ( https://stat.ethz.ch/pipermail/r-devel/2004-September/030844.html ) He did not post what he ended up with this problem though. I am having exactly the same problem. I need to sample with replacement from a population of size 10 million with fitness values for each individual. sample() is too slow for this purpose. I implement a bisection search algorithm. It is about 30% faster than the linear search one but still not good enough to me. (I can post the function if needed). Does anybody have some good ideas? The only other idea I have is using a faster (but worse) random number generator just for this application. Thanks. Bo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Open device -> glibc 2.3.4 bug for Redhat Enterprise 4?
We have been using Redhat Enterprise 4, on some of our Linux
clients for a while,
and Christoph has just found that opening an R device for a file
without write permission gives a bad glibc error and subsequent
seg.fault:
> postscript("/blabla.ps")
*** glibc detected *** double free or corruption (!prev): 0x01505f10 ***
or
> xfig("/blabla.fig")
*** glibc detected *** double free or corruption (!prev): 0x01505f10 ***
and similar for pdf();
does not happen for jpeg() {which runs via x11},
nor e.g. for
> sink("/bla.txt")
---
Happens both on 32-bit (Pentium) and 64-bit (AMD Athlon)
machines with the following libc :
32-bit:
-rwxr-xr-x 1 root root 1451681 May 13 00:17 /lib/tls/libc-2.3.4.so*
64-bit:
-rwxr-xr-x 1 root root 1490956 May 12 23:26 /lib64/tls/libc-2.3.4.so*
---
Can anyone reproduce this problem?
Regards,
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Open device -> glibc 2.3.4 bug for Redhat Enterprise 4?
This was supposed to be fixed in 2.1.1 -- which version are you using?
-thomas
On Tue, 21 Jun 2005, Martin Maechler wrote:
> We have been using Redhat Enterprise 4, on some of our Linux
> clients for a while,
> and Christoph has just found that opening an R device for a file
> without write permission gives a bad glibc error and subsequent
> seg.fault:
>
>> postscript("/blabla.ps")
> *** glibc detected *** double free or corruption (!prev): 0x01505f10
> ***
>
> or
>
>> xfig("/blabla.fig")
> *** glibc detected *** double free or corruption (!prev): 0x01505f10
> ***
>
> and similar for pdf();
> does not happen for jpeg() {which runs via x11},
> nor e.g. for
>
>> sink("/bla.txt")
>
> ---
>
> Happens both on 32-bit (Pentium) and 64-bit (AMD Athlon)
> machines with the following libc :
>
> 32-bit:
> -rwxr-xr-x 1 root root 1451681 May 13 00:17 /lib/tls/libc-2.3.4.so*
> 64-bit:
> -rwxr-xr-x 1 root root 1490956 May 12 23:26 /lib64/tls/libc-2.3.4.so*
>
> ---
>
> Can anyone reproduce this problem?
>
> Regards,
> Martin
>
> __
> 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] Open device -> glibc 2.3.4 bug for Redhat Enterprise 4?
> "TL" == Thomas Lumley <[EMAIL PROTECTED]>
> on Tue, 21 Jun 2005 09:59:31 -0700 (PDT) writes:
TL> This was supposed to be fixed in 2.1.1 -- which version are you using?
2.1.1 -- and 2.1.0 and 2.0.0 all showed the problem.
But thanks, Thomas, looking in "NEWS" of R-devel showed that
there was a fix for this in R-devel only --- too bad it didn't
make it for R 2.1.1.
And yes, the seg.fault doesn't happen in my version of R-devel.
Further note that only the very recent libc produces the
segfault for us. Earlier versions, including the libc-2.3.2
used in our Debian sid (on AMD Opteron), do give the correct
error message instead of the seg.fault.
TL> On Tue, 21 Jun 2005, Martin Maechler wrote:
>> We have been using Redhat Enterprise 4, on some of our Linux
>> clients for a while,
>> and Christoph has just found that opening an R device for a file
>> without write permission gives a bad glibc error and subsequent
>> seg.fault:
>>
>>> postscript("/blabla.ps")
>> *** glibc detected *** double free or corruption (!prev):
0x01505f10 ***
>>
>> or
>>
>>> xfig("/blabla.fig")
>> *** glibc detected *** double free or corruption (!prev):
0x01505f10 ***
>>
>> and similar for pdf();
>> does not happen for jpeg() {which runs via x11},
>> nor e.g. for
>>
>>> sink("/bla.txt")
>>
>> ---
>>
>> Happens both on 32-bit (Pentium) and 64-bit (AMD Athlon)
>> machines with the following libc :
>>
>> 32-bit:
>> -rwxr-xr-x 1 root root 1451681 May 13 00:17 /lib/tls/libc-2.3.4.so*
>> 64-bit:
>> -rwxr-xr-x 1 root root 1490956 May 12 23:26 /lib64/tls/libc-2.3.4.so*
>>
>> ---
>>
>> Can anyone reproduce this problem?
>>
>> Regards,
>> Martin
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
TL> __
TL> R-devel@r-project.org mailing list
TL> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] weighted.residuals for glm objects (PR#7961)
Full_Name: Henric Nilsson
Version: 2.2.0 (2005-06-20 r34776)
OS: Windows 2000
Submission from: (NULL) (213.115.23.26)
The help page for `weighted.residuals' states that the function can be used with
both `lm' and `glm' objects. However, it's unclear what's meant by the following
passage
"Weighted residuals are the usual residuals Ri, multiplied by wi^0.5, where wi
are the weights as specified in lm's call."
when it comes to a GLM. What's "...usual residuals..." in this context?
After reading the code it's clear that the function multiplies the deviance
residuals by wi^0.5, but this doesn't seem sensible for a GLM. Consider e.g.
> set.seed(1)
> x <- runif(10)
> y <- x + rnorm(10)
> w <- 0:9
> weighted.residuals(lm(y ~ x, weights = w))
2 3 4 5 6 7 8
0.3845201 1.0361636 1.2689516 -0.9817686 3.7205310 1.3823979 -1.5458433
9 10
-6.2029822 2.6149474
> weighted.residuals(glm(y ~ x, weights = w))
2 3 4 5 6 7
0.3845201 1.4653567 2.1978886 -1.9635372 8.3193602 3.3861695
8 9 10
-4.0899170 -17.5446831 7.8448423
I suggest that the code for `weighted.residuals' is changed to
weighted.residuals <- function (obj, drop0 = TRUE)
{
w <- weights(obj)
r <- residuals(obj, type = "deviance")
if (is.null(w))
r
else if (drop0)
r[w != 0]
else r
}
which seems to do the "right thing" for both `lm' and `glm' objects.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Open device -> glibc 2.3.4 bug for Redhat Enterprise 4?
On Tue, 21 Jun 2005, Martin Maechler wrote: >> "TL" == Thomas Lumley <[EMAIL PROTECTED]> >> on Tue, 21 Jun 2005 09:59:31 -0700 (PDT) writes: > >TL> This was supposed to be fixed in 2.1.1 -- which version are you using? > > 2.1.1 -- and 2.1.0 and 2.0.0 all showed the problem. > > But thanks, Thomas, looking in "NEWS" of R-devel showed that > there was a fix for this in R-devel only --- too bad it didn't > make it for R 2.1.1. > It's a double free(), so it produces undefined behaviour and anything can happen. On the Mac (where it was first reported), "anything" was a warning message from malloc, and on many systems "anything" is nothing. I thought I had added it to R-patched as well, but obviously not. -thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] efficiency of sample() with prob.
In his "Introduction to Probability Models" Sheldon Ross describes (sec 11.4.1, 8th edition) the alias method for such weighted sampling. It is based on some decomposition of the original distribution (the weights) into a mixture of two-point distributions. I don't know the run-time complexity of the decomposition step. But once the decomposition is found the complexity of generating a sample is linear in the size of the sample. I haven't coded this because I had found an easier way to deal with the original problem I had at that time. HTH, Vadim > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bo Peng > Sent: Tuesday, June 21, 2005 9:24 AM > To: r-devel@r-project.org > Subject: [Rd] efficiency of sample() with prob. > > Dear list, > > A while ago, Vadim asked opinions on improving efficiency of > sample() with prob, e.g. sample with replacement with weight. > ( > https://stat.ethz.ch/pipermail/r-devel/2004-September/030844.h tml ) He did not post what he ended up with this problem though. > > I am having exactly the same problem. I need to sample with > replacement from a population of size 10 million with fitness > values for each individual. sample() is too slow for this purpose. > > I implement a bisection search algorithm. It is about 30% > faster than the linear search one but still not good enough > to me. (I can post the function if needed). Does anybody have > some good ideas? The only other idea I have is using a faster > (but worse) random number generator just for this application. > > Thanks. > Bo > > __ > 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] Trouble with ifelse and if statement (PR#7962)
Full_Name: Woolton Lee
Version: 2.1
OS: windows
Submission from: (NULL) (128.118.224.46)
I did the following ('g' and 'h' are both numeric vectors)
> i <- abs(g-h)
creating a vector 'i' with values,
> i
[1] 0.08 0.00 0.33 0.00 0.00 0.00 0.00 0.33 0.00 0.00 0.08 0.08 0.20 0.00 0.13
Now, I want to create a new vector =1 whenever 'i' = 0.33 and =0 otherwise. I
use the 'ifelse' function to do this but when I do, I find
> ifelse(i==0.33,1,0)
[1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
even though the third and eighth elements of 'i' clearly equal 0.33. Unless I
have missed something, 'ifelse' should return a vector that looks like,
[1] 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0
When I try 0.13 I get a correct result
> ifelse(i==0.13,1,0)
[1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
but when I try 0.08 or 0.2 I find a similar problem,
> ifelse(i==0.08,1,0)
[1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> ifelse(i==0.20,1,0)
[1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> ifelse(i==0.2,1,0)
[1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Can you explain what is happening? Why is R incorretly returning a vector that
does not reflect the values in 'i'? Is this due to a malfunction in R or have I
missed something?
Thank you for your help.
Woolton
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Data you can use student (PR#7963)
Our Missions : to be the sincere internet merchant on repliica goods who is dedicated on our top-tier product quality, error-free logistics accuracy and hassle-free after-sale customer service, with the knowledge and skills of being a manufacturer since 2002. http://xyie.timedividendwind.com/re/ Addidas, Bally, Bvlgari, Burberry, Cartier, Chanel, Christian Dior, Dunhill, Dupont, Escada, Fendi, Ferragamo, Gucci, Hermes, IWC, Jacob & Co., Louis Vuitton, Mont Blanc, Movado, Nike, Omega, Oris, Prada, Puma, Rado, Roger Dubuis, Rolex, Sector, Tag Heuer, TechnoMarine, Tiffany, Timberland, Tudor There's a song playing in every heart beating flopenlog fbscanf fbendac sz01 dtstrm etacidem Glitter on the front porchGlitter on the hallway __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trouble with ifelse and if statement (PR#7962)
On 6/21/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Full_Name: Woolton Lee
> Version: 2.1
> OS: windows
> Submission from: (NULL) (128.118.224.46)
>
>
> I did the following ('g' and 'h' are both numeric vectors)
> > i <- abs(g-h)
> creating a vector 'i' with values,
> > i
> [1] 0.08 0.00 0.33 0.00 0.00 0.00 0.00 0.33 0.00 0.00 0.08 0.08 0.20 0.00
> 0.13
>
> Now, I want to create a new vector =1 whenever 'i' = 0.33 and =0 otherwise. I
> use the 'ifelse' function to do this but when I do, I find
> > ifelse(i==0.33,1,0)
> [1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>
> even though the third and eighth elements of 'i' clearly equal 0.33. Unless I
> have missed something, 'ifelse' should return a vector that looks like,
> [1] 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0
>
> When I try 0.13 I get a correct result
> > ifelse(i==0.13,1,0)
> [1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
>
> but when I try 0.08 or 0.2 I find a similar problem,
> > ifelse(i==0.08,1,0)
> [1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > ifelse(i==0.20,1,0)
> [1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > ifelse(i==0.2,1,0)
> [1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>
> Can you explain what is happening? Why is R incorretly returning a vector
> that
> does not reflect the values in 'i'? Is this due to a malfunction in R or
> have I
> missed something?
This is 7.31 of the R FAQ:
http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trouble with ifelse and if statement (PR#7962)
On Wed, 2005-06-22 at 04:46 +0200, [EMAIL PROTECTED] wrote:
> Full_Name: Woolton Lee
> Version: 2.1
> OS: windows
> Submission from: (NULL) (128.118.224.46)
>
>
> I did the following ('g' and 'h' are both numeric vectors)
> > i <- abs(g-h)
> creating a vector 'i' with values,
> > i
> [1] 0.08 0.00 0.33 0.00 0.00 0.00 0.00 0.33 0.00 0.00 0.08 0.08 0.20 0.00
> 0.13
>
> Now, I want to create a new vector =1 whenever 'i' = 0.33 and =0 otherwise. I
> use the 'ifelse' function to do this but when I do, I find
> > ifelse(i==0.33,1,0)
> [1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>
> even though the third and eighth elements of 'i' clearly equal 0.33. Unless I
> have missed something, 'ifelse' should return a vector that looks like,
> [1] 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0
>
> When I try 0.13 I get a correct result
> > ifelse(i==0.13,1,0)
> [1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
>
> but when I try 0.08 or 0.2 I find a similar problem,
> > ifelse(i==0.08,1,0)
> [1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > ifelse(i==0.20,1,0)
> [1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> > ifelse(i==0.2,1,0)
> [1] 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>
> Can you explain what is happening? Why is R incorretly returning a vector
> that
> does not reflect the values in 'i'? Is this due to a malfunction in R or
> have I
> missed something?
>
> Thank you for your help.
>
> Woolton
This is not a bug and yes you have missed something.
Read R FAQ 7.31 Why doesn't R think these numbers are equal?
More information is also available here:
http://grouper.ieee.org/groups/754/
One possible solution:
> i
[1] 0.08 0.00 0.33 0.00 0.00 0.00 0.00 0.33 0.00 0.00 0.08 0.08 0.20
[14] 0.00 0.13
> ifelse(sapply(i, function(x) all.equal(x, 0.33)) == "TRUE", 1, 0)
[1] 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0
> ifelse(sapply(i, function(x) all.equal(x, 0.08)) == "TRUE", 1, 0)
[1] 1 0 0 0 0 0 0 0 0 0 1 1 0 0 0
> ifelse(sapply(i, function(x) all.equal(x, 0.2)) == "TRUE", 1, 0)
[1] 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
Marc Schwartz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
