Re: [Rd] Patch to allow negative argument in head() and tail()

[Martin Maechler]

> "FrPi" == François Pinard <[EMAIL PROTECTED]>
> on Tue, 18 Jul 2006 17:41:53 -0400 writes:

FrPi> [Vincent Goulet]
>> For me, this usage of head() and tail() is, at first,
>> completely unintuitive since I more used to, say, "start
>> from the beginning (head) of the vector and drop the
>> first n elements" than "return the end of the vector
>> except the first n elements". But I must agree your
>> convention does make sense!

FrPi> Vincent -- bonjour!, Martin -- hi! and all others -- hello! :-)
:-)

FrPi> The usual head and tail Unix utilities, as found
FrPi> within GNU Coreutils, have conventions for negative
FrPi> numbers.  See:

  $ seq 10 | head -n-3
  1
  2
  3
  4
  5
  6
  7
  $ seq 10 | tail -n-3
  8
  9
  10
  $

FrPi> Of course, these do not rule what R should do in any
FrPi> way.  Yet, it is sometimes convenient and even elegant
FrPi> when tools having similar names have similar
FrPi> behaviour.  Despite application domains are different,
FrPi> it's worth pondering such similarities, when these are
FrPi> easily possible.

Thank you for the good suggestion.
However Peter Dalgaard has beaten you here -- in a non-public
mail though.

An excerpt of my answer (of yesterday) to his mail:

  Regarding unix command line compatibility:
  Note that there, 'tail'  is *really* not what we want to imitate:

  "3" is the same as "-3" but different from "+3" :
  ~

  $ for N in 3 -3 +3 ; do echo "  $N :"; echo '  ---' ; tail -n $N 
/tmp/lib12.txt ; done

3 :
---
  10  "target")))
  11  if (!res)
  12  stop(gettextf("This is R %s, package '%s' needs %s %s",
-3 :
---
  10  "target")))
  11  if (!res)
  12  stop(gettextf("This is R %s, package '%s' needs %s %s",
+3 :
---
  3   verbose = getOption("verbose"), version)
  4   {
  5   testRversion <- function(pkgInfo, pkgname, pkgpath) {
  6   current <- getRversion()
  7   if (length(Rdeps <- pkgInfo$Rdepends) > 1) {
  8   target <- Rdeps$version
  9   res <- eval(parse(text = paste("current", Rdeps$op,
  10  "target")))
  11  if (!res)
  12  stop(gettextf("This is R %s, package '%s' needs %s %s",

--

I know that there is some "good" reason for the behavior of
'tail' in "Unix" 
  { tail -3 === tail -n  3   and
tail -3 === tail -n -3  }

but of course, we can't be compatible here, because in S
(and most reasonable languages :-) 
"3 == +3"  and  "3 != -3" !

Martin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Bug?: summary() fails after use of na.action="na.exclude" in lm()

[Gregor Gorjanc]

Hello!

I have encountered a weird problem and I am wondering if this is a bug.
Here is the example:

n <- 50
x <- runif(n=n)
y1 <- 2 * x + rnorm(n=n)
y2 <- 5 * x + rnorm(n=n)
y2[sample(1:n, size=5)] <- NA

y <- cbind(y1, y2)

fit <- lm(y1 ~ 1, na.action="na.exclude")
summary(fit)

## Goes ok here
fit <- lm(y2 ~ 1, na.action="na.exclude")
summary(fit)

## But fails if we use matrix of response variables
fit <- lm(y ~ 1, na.action="na.exclude")
summary(fit)

## Response y1 :
##
## Call:
## lm(formula = y1 ~ 1, na.action = "na.exclude")
##
## Residuals:
## Error in quantile.default(resid) : missing values and NaN's not
allowed if 'na.rm' is FALSE

Am I doing something wrong here?

--

Btw. man page of lm says (in the begining of the details):

"A typical model has the form 'response ~ terms' where 'response' is the
(numeric) response vector ..."
   ^^

Should not this part say that repsponse can also be a matrix?

Thanks

-- 
Lep pozdrav / With regards,
Gregor Gorjanc

--
University of Ljubljana PhD student
Biotechnical Faculty
Zootechnical Department URI: http://www.bfro.uni-lj.si/MR/ggorjan
Groblje 3   mail: gregor.gorjanc  bfro.uni-lj.si

SI-1230 Domzale tel: +386 (0)1 72 17 861
Slovenia, Europefax: +386 (0)1 72 17 888

--
"One must learn by doing the thing; for though you think you know it,
 you have no certainty until you try." Sophocles ~ 450 B.C.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Dropping unused levels of a factor that has "NA" as a level

[Prof Brian Ripley]

It is history:

r16144 | ripley | 2001-09-28 19:40:28 +0100 (Fri, 28 Sep 2001) | 2 lines

add is.na<-, distinguish NA level and NA codes in factors

so predates having NA character strings distinct from "NA".

On Tue, 11 Jul 2006, Brahm, David wrote:

> I mentioned this in R-help on April 28:
> 
> 
> | as.character.factor contains this line (where cx=levels(x)[x]):
> |   if ("NA" %in% levels(x)) cx[is.na(x)] <- ""
> |
> | Is it possible that this is no longer the desired behavior?  These
> | two results don't seem very consistent:
> |
> | > as.character(as.factor(c("AB", "CD", NA)))
> | [1] "AB" "CD" NA  
> | > is.na(.Last.value)[3]
> | [1] TRUE
> |
> | > as.character(as.factor(c("NA", "CD", NA)))
> | [1] "NA"   "CD"   ""
> | > is.na(.Last.value)[3]
> | [1] FALSE
> |
> | I'm using R-2.3.0 on Redhat Linux, but I don't think the behavior
> | is new (maybe since character NA's were introduced?).
> |
> | -- David Brahm ([EMAIL PROTECTED])
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Dalgaard
> Sent: Tuesday, July 11, 2006 5:59 PM
> To: J. Hosking
> Cc: r-devel@stat.math.ethz.ch
> Subject: Re: [Rd] Dropping unused levels of a factor that has "NA" as a level
> 
> "J. Hosking" <[EMAIL PROTECTED]> writes:
> 
> > Is this a bug?
> > 
> >> f1 <- factor(c("a", NA), levels = c("a", "NA") )
> >> f2 <- f1[, drop = TRUE]
> >> f2
> >[1] a
> >Levels: a 
> > 
> > I would have expected f2 to have only one level, "a".  It seems
> > to me that the code in [.factor does not follow the advice in
> > help("factor") on how to set factor codes to be missing when
> > "NA" is a level of the factor.
> 
> 
> Something odd is going on, that's for sure...
> 
> The problem is also there with factor(f1). And the logic in
> as.character.factor seems to be at the root of it:
> 
> > as.character.factor
> function (x, ...)
> {
> cx <- levels(x)[x]
> if ("NA" %in% levels(x))
> cx[is.na(x)] <- ""
> cx
> }
>  
> This looks like something from before we had character NA values. I
> wonder if it is a mistake or there could actually be a reason to
> keep it. 
> 
> 

-- 
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] illegal operation in debian (PR#9086)

[agustin . perez]

Full_Name: Agustin Perez
Version: 2.3.1
OS: Debian 2.6.8-11-amd64-generic
Submission from: (NULL) (193.147.142.6)


First of all excuses for my bad use of english and thanks for read my problem.

Well when I do the following comand in R suddenly crashes and exit me for the
enviroment:

> a<-matrix(1:13500,450,30)
> a%*%t(a)

 *** caught illegal operation ***
address 0x2a9590086f, cause 'illegal operand'

Possible actions:
1: abort (with core dump)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 3


I don't know what is the problem.

Agustín

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] illegal operation in debian (PR#9086)

[ripley]

On Wed, 19 Jul 2006, [EMAIL PROTECTED] wrote:

> Full_Name: Agustin Perez
> Version: 2.3.1
> OS: Debian 2.6.8-11-amd64-generic
> Submission from: (NULL) (193.147.142.6)
> 
> 
> First of all excuses for my bad use of english and thanks for read my problem.
> 
> Well when I do the following comand in R suddenly crashes and exit me for the
> enviroment:
> 
> > a<-matrix(1:13500,450,30)
> > a%*%t(a)
> 
>  *** caught illegal operation ***
> address 0x2a9590086f, cause 'illegal operand'
> 
> Possible actions:
> 1: abort (with core dump)
> 2: normal R exit
> 3: exit R without saving workspace
> 4: exit R saving workspace
> Selection: 3
> 
> 
> I don't know what is the problem.

Quite likely using a BLAS inappropriate for the chip in use.

If you choose 1 and examine the core dump with gdb you will be able to 
tell us where the illegal operand occurred.

-- 
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

Re: [Rd] illegal operation in debian (PR#9086)

[Dirk Eddelbuettel]

On 19 July 2006 at 12:48, [EMAIL PROTECTED] wrote:
| On Wed, 19 Jul 2006, [EMAIL PROTECTED] wrote:
| 
| > Full_Name: Agustin Perez
| > Version: 2.3.1
| > OS: Debian 2.6.8-11-amd64-generic
| > Submission from: (NULL) (193.147.142.6)
| > 
| > 
| > First of all excuses for my bad use of english and thanks for read my 
problem.
| > 
| > Well when I do the following comand in R suddenly crashes and exit me for 
the
| > enviroment:
| > 
| > > a<-matrix(1:13500,450,30)
| > > a%*%t(a)
| > 
| >  *** caught illegal operation ***
| > address 0x2a9590086f, cause 'illegal operand'
| > 
| > Possible actions:
| > 1: abort (with core dump)
| > 2: normal R exit
| > 3: exit R without saving workspace
| > 4: exit R saving workspace
| > Selection: 3
| > 
| > 
| > I don't know what is the problem.
| 
| Quite likely using a BLAS inappropriate for the chip in use.

Yes, that is very likely -- the command just worked on my Debian
system. Please show us the result of 

$ dpkg -l | grep "blas\|lapack"| cut -c-79

Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] illegal operation in debian (PR#9086)

[Perez Martin, Agustin]

Well, first I´m going to write the output of gdb:

 

  [EMAIL PROTECTED]:~$ gdb R core

  GNU gdb 6.3-debian

  Copyright 2004 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 "x86_64-linux"..."/usr/bin/R": not in
executable format: No se reconoce el formato del fichero

  

  Using host libthread_db library "/lib/libthread_db.so.1".

  Core was generated by `/home/agustin.perez/R-2.3.1/bin/exec/R'.

  Program terminated with signal 4, Illegal instruction.

  #0  0x002a9590086f in ?? ()

 

 

And now this is the output of dpkg -l | grep "blas\|lapack"| cut -c-79 :

 

  [EMAIL PROTECTED]:~$ dpkg -l | grep "blas\|lapack"| cut -c-79

  ii  refblas3   1.2-8  Basic Linear Algebra Subroutines 3,
shared l

ii  refblas3-dev   1.2-8  Basic Linear Algebra Subroutines 3, static
l

[EMAIL PROTECTED]:~$

 

 

-Mensaje original-
De: Dirk Eddelbuettel [mailto:[EMAIL PROTECTED] 
Enviado el: miércoles, 19 de julio de 2006 13:20
Para: [EMAIL PROTECTED]; [EMAIL PROTECTED]
CC: r-devel@stat.math.ethz.ch; [EMAIL PROTECTED]
Asunto: Re: [Rd] illegal operation in debian (PR#9086)

 

 

On 19 July 2006 at 12:48, [EMAIL PROTECTED] wrote:

| On Wed, 19 Jul 2006, [EMAIL PROTECTED] wrote:

| 

| > Full_Name: Agustin Perez

| > Version: 2.3.1

| > OS: Debian 2.6.8-11-amd64-generic

| > Submission from: (NULL) (193.147.142.6)

| > 

| > 

| > First of all excuses for my bad use of english and thanks for read my
problem.

| > 

| > Well when I do the following comand in R suddenly crashes and exit me
for the

| > enviroment:

| > 

| > > a<-matrix(1:13500,450,30)

| > > a%*%t(a)

| > 

| >  *** caught illegal operation ***

| > address 0x2a9590086f, cause 'illegal operand'

| > 

| > Possible actions:

| > 1: abort (with core dump)

| > 2: normal R exit

| > 3: exit R without saving workspace

| > 4: exit R saving workspace

| > Selection: 3

| > 

| > 

| > I don't know what is the problem.

| 

| Quite likely using a BLAS inappropriate for the chip in use.

 

Yes, that is very likely -- the command just worked on my Debian

system. Please show us the result of 

 

$ dpkg -l | grep "blas\|lapack"| cut -c-79

 

Dirk

 

-- 

Hell, there are no rules here - we're trying to accomplish something. 

  -- Thomas A. Edison

 

-- 

No virus found in this incoming message.

Checked by AVG Free Edition.



 


-- 

Checked by AVG Free Edition.

 

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] illegal operation in debian (PR#9086)

[Prof Brian Ripley]

On Wed, 19 Jul 2006, Perez Martin, Agustin wrote:

> Well, first I´m going to write the output of gdb:

Used incorrectly: you need to use

gdb  /path/to/R/bin/exec/R 

and perhaps 'where' at the gdb prompt.

(Or run R -d gdb.)

>   [EMAIL PROTECTED]:~$ gdb R core
> 
>   GNU gdb 6.3-debian
> 
>   Copyright 2004 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 "x86_64-linux"..."/usr/bin/R": not in
> executable format: No se reconoce el formato del fichero
> 
>   
> 
>   Using host libthread_db library "/lib/libthread_db.so.1".
> 
>   Core was generated by `/home/agustin.perez/R-2.3.1/bin/exec/R'.
> 
>   Program terminated with signal 4, Illegal instruction.
> 
>   #0  0x002a9590086f in ?? ()

...

-- 
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

Re: [Rd] [BioC] Errors using biocLite on Apple OS X

[Simon Urbanek]

Steven,

short story: now fixed in R-devel. The long story:

On Jul 18, 2006, at 8:15 PM, Steven McKinney wrote:

> The warnings from
>
>  make.packages.html()
>
> on the Apple Mac OS X platform can be dealt
> with as follows:
>

The warning appears for a completely different reason -  
make.packages.html() assumes that HTML help was started and created  
all necessary links which is not the case in the R Mac OS X GUI,  
until you request one of the temporarily generated pages. The idea of  
make.packages.html is to update the  temporary copy of HTML  
documentation on installation such that packages list is up-to-date,  
but since the R GUI generates the files only on-demand, there is no  
need for such update if no temporary documentation was requested yet,  
and so updating doesn't make sense (and the warning can be ignored).  
The correct fix is not not run make.packages.html() at all if the  
temporarily generated list doesn't exist and I have fixed that now  
for R-devel.

All your 'work-arounds' are bogus - may have asked on R-SIG-Mac to  
save you the trouble of going in a completely wrong direction -  just  
invoke the main help page () before installing and the  
temporary help files will be created.


> 
> (1)
>
> make.packages.html() uses the function tempdir() and attempts to  
> create a temporary directory in the default location /tmp/ which  
> fails due to the /tmp directory architecture on the Mac.
>

This is of course nonsense. Mac OS X uses /tmp as many other unix  
systems do and it is available (tempdir() works as well).


> (2)
>
> The function make.packages.html() attempts to create a couple of  
> files, but fails on Mac OS X. Apparently a directory must already  
> exist for file.create() to successfully establish a new file in it.
>

Yes, it fails because it expects the help system to have created them  
already and you're not supposed to mess with that manually. (Again,  
this is not Mac-specific - until help.start is invoked, the  
directories are not there on any unix).


> However, when biocLite() runs, it does not access my redefined  
> make.packages.html() in .Globalenv - the bioclite() call appears to  
> always call the package:utils copy of this function.
>

Yes, that is intentional, thanks to namespaces.


> Thanks to Herve Pages for his excellent summarization of the issues  
> arising when running biocLite on the Mac.
>

For the record, the other warning mentioned appears when installing  
from empty repositories - it is not Mac specific. (The lindsey  
repository is empty on Bioc, because none of the packages compiles).  
I have now also committed the fix (thanks to Seth for the correct  
analysis and fix).

Cheers,
Simon


> -Original Message-
> From: Herve Pages [mailto:[EMAIL PROTECTED]
> Sent: Tue 7/18/2006 12:51 PM
> To: Steven McKinney
> Cc: [EMAIL PROTECTED]
> Subject: Re: [BioC] Errors using biocLite on Apple OS X
>
> Hi Steven,
>
> I can see warnings only in what you reported. These warnings
> are well-known issues but are not biocLite problems: they are
> Mac OS X install.packages() specific issues.
>
> The first warning:
>   1: number of rows of result
>is not a multiple of vector length (arg 2) in: cbind(1, res0,
> Repository = repos)
> is issued by install.packages() when it is given a repos vector with
> length >= 4.
> You can easily reproduce it with:
>> repos <- c("http://bioconductor.org/packages/1.8/bioc";,
>  "http://bioconductor.org/packages/1.8/data/annotation";,
>  "http://bioconductor.org/packages/1.8/data/experiment";,
>  "http://bioconductor.org/packages/1.8/omegahat";,
>  "http://bioconductor.org/packages/1.8/lindsey";,
>  "http://cran.fhcrc.org";)
>> install.packages("Biobase", repos=repos)
>
> The second warning is a permission issue specific to Mac OS X.
>
> Anyway, these warnings should not prevent biocLite to install the  
> requested
> packages correctly.
>
> Cheers,
>
> H.
>
>
> Steven McKinney wrote:
>> I've recently started using R and Bioconductor
>> on an Apple Mac running OS X (10.4). I've been
>> installing packages from the *nix command line,
>> one by one, no trouble.
>>
>> I would like to be able to update using
>> biocLite from the R gui, but keep getting
>> errors.
>>
>>
>>> version
>> _
>> platform powerpc-apple-darwin8.6.0
>> arch powerpc
>> os darwin8.6.0
>> system powerpc, darwin8.6.0
>> status
>> major 2
>> minor 3.1
>> year 2006
>> month 06
>> day 01
>> svn rev 38247
>> language R
>> version.string Version 2.3.1 (2006-06-01)
>>
>>
>>> source("http://bioconductor.org/biocLite.R";)
>>> biocLite("Biobase", destdir =
>>> "/Volumes/KilroyHD/kilroy/Software/BioConductor")
>> Running getBioC version 0.1.6 with R version 2.3.1
>> Running biocinstall version 1.8.4 with R version 2.3.1
>> Your version of R requires version 1.8 of Bioconductor.
>> trying URL
>> 'http://bioconductor.org/packages/1.8/bioc/bin/macosx/powerpc/ 
>> contrib/2.3/Biobas

Re: [Rd] ASCII dump from an REXP (JRI)

[Simon Urbanek]

Adam,

please use stats-rosuda-devel or private mail, your mail ended up on  
R-devel again ...

On Jul 18, 2006, at 10:56 PM, way4thesub wrote:

> evaluate an R expression. Is there a way to just print, verbatim,  
> what R evaluates to the screen (ie just a pure ASCII dump with no  
> regard to the data type)?
>

Probably the easiest is (replace "a" with any expression you want to  
show):

System.out.println(reng.eval("paste(capture.output(print 
(a)),collapse='\n')").asString());

Another alternative is to use callbacks - i.e. create a class that  
implements RMainLoopCallbacks and simple reng.eval("print(a)"); will  
cause rWriteConsole to be called with the output. This approach is  
more suitable for console-like GUIs.

Cheers,
Simon

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Patch to allow negative argument in head() and tail()

[François Pinard]

[Martin Maechler]

>  Regarding unix command line compatibility:
>  Note that there, 'tail'  is *really* not what we want to imitate:

>  "3" is the same as "-3" but different from "+3" :

>I know that there is some "good" reason for the behavior of
>'tail' in "Unix" 
>  { tail -3 === tail -n  3   and
>tail -3 === tail -n -3  }***

>but of course, we can't be compatible here, because in S
>(and most reasonable languages :-) 
>"3 == +3"  and  "3 != -3" !

I'm not sure I understand you fully, or maybe there is a typo on the 
starred line above.  When I speak about GNU "head" and "tail" behaviour,
I'm really meaning the internal behaviour once option values have been 
decoded, but certainly not option representation themselves.

The strange spirit of Unix designers show, where while `-' is only meant 
as an option introducer, by a kind of typographical pun, it is 
temporarily seen a negative sign when the time comes to negate a value, 
and this is the reason `+' was sometimes used, that is, as a humorous 
way to mean a minus sign in option context.  So, `+' really means `-' 
sometimes.  This is a similar kind of humour which later yielded 
a better "more" program to be named "less" :-).

For "head" and "tail", these programs were accepting a number as first 
argument without requiring it to be introduced by the usual `-'.  POSIX 
later came in and got rid of this irregularity.  Moreover, within GNU, 
`+' option introducer was once reserved for so called "long options" and 
consequently unavailable for the above pun, but later freed again when 
the `--' convention was adopted instead of `+' for long options.  Many 
implementations attempted to be compatible to both POSIX and pre-POSIX 
specifications.  GNU implementation also had to cope with their own 
varying option standards, as well as a lot of contradictory pressure 
from users and within.  Even nowadays, as a futile attempt to reconcile 
some incompatible trends that cannot be dismissed, a few environment 
variables can be set to alter how these tools interpret and decode the 
value of the dreaded option.  As you may guess, confusion resulted, and 
those of us who followed it all never fully recovered from all the brain 
damage :-).  [Another tiny corner of Unix where sign confusion blatantly 
existed was "nice", this tool meant to alter process priority.]

*Once* the real value has been decoded out of the option, the current 
convention is as follow, given that N is a positive number:

  Value  "head" tool"tail" tool

  N  Show N initial lines   Show N last lines
  -N Show all but N last lines  Show all but N first lines

Hoping that this clarification may be helpful in the whole thinking! :-)

-- 
François Pinard   http://pinard.progiciels-bpi.ca

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Bug?: summary() fails after use of na.action="na.exclude" in lm()

[Thomas Lumley]

On Wed, 19 Jul 2006, Gregor Gorjanc wrote:
> I have encountered a weird problem and I am wondering if this is a bug.
> Here is the example:
>
> n <- 50
> x <- runif(n=n)
> y1 <- 2 * x + rnorm(n=n)
> y2 <- 5 * x + rnorm(n=n)
> y2[sample(1:n, size=5)] <- NA
>
> y <- cbind(y1, y2)
>
> fit <- lm(y1 ~ 1, na.action="na.exclude")
> summary(fit)
>
> ## Goes ok here
> fit <- lm(y2 ~ 1, na.action="na.exclude")
> summary(fit)
>
> ## But fails if we use matrix of response variables
> fit <- lm(y ~ 1, na.action="na.exclude")
> summary(fit)
>
> ## Response y1 :
> ##
> ## Call:
> ## lm(formula = y1 ~ 1, na.action = "na.exclude")
> ##
> ## Residuals:
> ## Error in quantile.default(resid) : missing values and NaN's not
> allowed if 'na.rm' is FALSE
>

Yes, I think it's a bug.

  summary.mlm() produces an object that is a list of objects of class 
"summary.lm", but these objects get their $resid component from the 
residuals() function and so NAs in their $resid component where a 
"summary.lm"  produced by summary.lm() would not.

-thomas

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Post CGI forms with built-in R function?

[Mike Schaffer]

I wrote a package that requires downloading data from an external  
server based on parameters specified by the user.

I have used RMySQL or Rcurl to accomplish this, but in the interest  
of simplicity for users of this package, I'd like this communication  
to not require installing other packages and their dependencies (e.g.  
RMySQL, Rcurl, etc.).  These dependencies are sometimes a deterrent  
to using my package.

I set up a CGI script on the server to handle data requests.  Now, is  
there a *built-in* R function that could be adapted to post forms or  
otherwise allows long URLs to be passed to this script to retrieve  
the data requested.  I tried using just "scan", but it fails with  
long URLs (sometimes a long list of parameters is required).  I think  
my only option is to use POST, but it doesn't appear it is possible  
without Rcurl.

Can anyone help or suggest a "native" solution to the problem?

Thanks.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] illegal operation in debian (PR#9086)

[Perez Martin, Agustin]

Program received signal SIGILL, Illegal instruction.
0x002a9590086f in ATL_dupKBmm30_1_1_b0 () from
/usr/lib/atlas/libblas.so.3


-Mensaje original-
De: Prof Brian Ripley [mailto:[EMAIL PROTECTED] 
Enviado el: miércoles, 19 de julio de 2006 14:23
Para: Perez Martin, Agustin
CC: 'Dirk Eddelbuettel'; r-devel@stat.math.ethz.ch
Asunto: RE: [Rd] illegal operation in debian (PR#9086)

On Wed, 19 Jul 2006, Perez Martin, Agustin wrote:

> Well, first I´m going to write the output of gdb:

Used incorrectly: you need to use

gdb  /path/to/R/bin/exec/R 

and perhaps 'where' at the gdb prompt.

(Or run R -d gdb.)

>   [EMAIL PROTECTED]:~$ gdb R core
> 
>   GNU gdb 6.3-debian
> 
>   Copyright 2004 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 "x86_64-linux"..."/usr/bin/R": not in
> executable format: No se reconoce el formato del fichero
> 
>   
> 
>   Using host libthread_db library "/lib/libthread_db.so.1".
> 
>   Core was generated by `/home/agustin.perez/R-2.3.1/bin/exec/R'.
> 
>   Program terminated with signal 4, Illegal instruction.
> 
>   #0  0x002a9590086f in ?? ()

...

-- 
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

-- 
No virus found in this incoming message.


 

--

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] illegal operation in debian (PR#9086)

[Prof Brian Ripley]

On Wed, 19 Jul 2006, Perez Martin, Agustin wrote:

> Program received signal SIGILL, Illegal instruction.
> 0x002a9590086f in ATL_dupKBmm30_1_1_b0 () from
> /usr/lib/atlas/libblas.so.3

OK, that is clearly a debian ATLAS issue, so not an R bug.

> -Mensaje original-
> De: Prof Brian Ripley [mailto:[EMAIL PROTECTED] 
> Enviado el: miércoles, 19 de julio de 2006 14:23
> Para: Perez Martin, Agustin
> CC: 'Dirk Eddelbuettel'; r-devel@stat.math.ethz.ch
> Asunto: RE: [Rd] illegal operation in debian (PR#9086)
> 
> On Wed, 19 Jul 2006, Perez Martin, Agustin wrote:
> 
> > Well, first I´m going to write the output of gdb:
> 
> Used incorrectly: you need to use
> 
> gdb  /path/to/R/bin/exec/R 
> 
> and perhaps 'where' at the gdb prompt.
> 
> (Or run R -d gdb.)
> 
> >   [EMAIL PROTECTED]:~$ gdb R core
> > 
> >   GNU gdb 6.3-debian
> > 
> >   Copyright 2004 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 "x86_64-linux"..."/usr/bin/R": not in
> > executable format: No se reconoce el formato del fichero
> > 
> >   
> > 
> >   Using host libthread_db library "/lib/libthread_db.so.1".
> > 
> >   Core was generated by `/home/agustin.perez/R-2.3.1/bin/exec/R'.
> > 
> >   Program terminated with signal 4, Illegal instruction.
> > 
> >   #0  0x002a9590086f in ?? ()
> 
> ...
> 
> 

-- 
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

Re: [Rd] Patch to allow negative argument in head() and tail()

[Charles C. Berry]

On Wed, 19 Jul 2006, Martin Maechler wrote:

[most discussion of unix tail behavior deleted]

>
> I know that there is some "good" reason for the behavior of
> 'tail' in "Unix"
>  { tail -3 === tail -n  3   and
>tail -3 === tail -n -3  }
>
> but of course, we can't be compatible here, because in S
> (and most reasonable languages :-)
> "3 == +3"  and  "3 != -3" !
>


Ahhh. But in R

quote( foo( +n ) ) != quote( foo( n ) )

so if one was determined to emulate GNU Coreutils tail's behavior it 
***could*** be done by using match.call to recover the explicit '+' or 
'-'.

But I shudder to think of the confusion that this approach might cause 
when n is an expression whose value is negative.


Chuck

Charles C. Berry(858) 534-2098
  Dept of Family/Preventive Medicine
E mailto:[EMAIL PROTECTED]   UC San Diego
http://biostat.ucsd.edu/~cberry/ La Jolla, San Diego 92093-0717

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Post CGI forms with built-in R function?

[Duncan Temple Lang]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi Mike

 If you don't want to have to download any packages but stick entirely
within R, then you can mimic the code in httpRequest. But,
as far as I know, there is no function in the standard R distribution to
POST an HTTP request.

  As for using
   scan("http://";)

  what is the string you are using? Are you escaping all the characters
correctly? What's the error message?

 If what you are doing involves only relatively basic HTTP requests,
perhaps the simplest thing to do is use the httpRequest package on CRAN.
It does the basics.  You may have to handle chunked responses yourself
and escaping certain characters. But that is a pure R solution that can
be easily installed via install.packages().



Mike Schaffer wrote:
> I wrote a package that requires downloading data from an external  
> server based on parameters specified by the user.
> 
> I have used RMySQL or Rcurl to accomplish this, but in the interest  
> of simplicity for users of this package, I'd like this communication  
> to not require installing other packages and their dependencies (e.g.  
> RMySQL, Rcurl, etc.).  These dependencies are sometimes a deterrent  
> to using my package.
> 
> I set up a CGI script on the server to handle data requests.  Now, is  
> there a *built-in* R function that could be adapted to post forms or  
> otherwise allows long URLs to be passed to this script to retrieve  
> the data requested.  I tried using just "scan", but it fails with  
> long URLs (sometimes a long list of parameters is required).  I think  
> my only option is to use POST, but it doesn't appear it is possible  
> without Rcurl.
> 
> Can anyone help or suggest a "native" solution to the problem?
> 
> Thanks.
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

- --
Duncan Temple Lang[EMAIL PROTECTED]
Department of Statistics  work:  (530) 752-4782
4210 Mathematical Sciences Building   fax:   (530) 752-7099
One Shields Ave.
University of California at Davis
Davis,
CA 95616,
USA
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFEvlwb9p/Jzwa2QP4RAvL1AJ9W/ixKDEl0KbH9yrGmTbEWsXoP+ACfXVdW
vxQEDd6UsMXzX0baOPdhMvo=
=uzVj
-END PGP SIGNATURE-

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] illegal operation in debian (PR#9086)

[Dirk Eddelbuettel]

On Wed, Jul 19, 2006 at 05:18:03PM +0100, Prof Brian Ripley wrote:
> On Wed, 19 Jul 2006, Perez Martin, Agustin wrote:
> 
> > Program received signal SIGILL, Illegal instruction.
> > 0x002a9590086f in ATL_dupKBmm30_1_1_b0 () from
> > /usr/lib/atlas/libblas.so.3
> 
> OK, that is clearly a debian ATLAS issue, so not an R bug.

Yup. And I had forgotten to ask you about the atlas libs. What does 
'dpkg -l | grep atlas' say ?

And to go one step ahead, conjecturing that you have a particular tuned
atlas library installed, remove that and try with atlas3-base only. The
error should go away. 

Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel