Re: [Rd] a bug in glm.fit() (PR#7947)

2005-06-15 Thread Prof Brian Ripley
What is the bug? This is the same model: the `intercept' term affects the null model, not the actual model. Just look at all the output. On Thu, 16 Jun 2005 [EMAIL PROTECTED] wrote: > glm.fit() gave me the same AIC's regardless of TRUE or FALSE intercept option. > >> myX <- as.matrix(1:10) >>

[Rd] a bug in glm.fit() (PR#7947)

2005-06-15 Thread jyzz88
glm.fit() gave me the same AIC's regardless of TRUE or FALSE intercept option. > myX <- as.matrix(1:10) > myY <- 3+5*myX > foo <- glm.fit(x=myX, y=myY, family = gaussian(link = "identity"), > intercept=TRUE) > foo$aic [1] 38.94657 > foo <- glm.fit(x=myX, y=myY, family = gaussian(link = "identity"

[Rd] Eilig Geschaftsvorschlag (PR#7945)

2005-06-15 Thread thomas
Geschaftsvorschlag. Zuerst muß ich um Ihre Zuversicht in dieser verhandlung bitten,dies ist auf Grund seiner lage, als das sein total VERTRAULICH und Geheimnisvoll. Aber ich weiß,daß eine verhandlung dieses Ausmaßes irgendeinen ängstlich und besorgt machen wird,aber ich versichre Ihnen,daß alle

Re: [Rd] R Include File Guards

2005-06-15 Thread Paul Roebuck
On Wed, 18 May 2005, Peter Dalgaard wrote: > Paul Roebuck <[EMAIL PROTECTED]> writes: > > > R 2.1.0/src/include from 2005/04/18 download > > > > Naming inconsistent for guards as well but that's pedantic. > > Simple convention: > > file > > #ifndef R_FOO_H > > file > > #ifndef R_EXT_

[Rd] Eilig Geschaftsvorschlag (PR#7944)

2005-06-15 Thread thomas_mandino
Geschaftsvorschlag. Zuerst muß ich um Ihre Zuversicht in dieser verhandlung bitten,dies ist auf Grund seiner lage, als das sein total VERTRAULICH und Geheimnisvoll. Aber ich weiß,daß eine verhandlung dieses Ausmaßes irgendeinen ängstlich und besorgt machen wird,aber ich versichre Ihnen,daß alle

[Rd] \section{Windows}{...} instead of #ifdef windows ... #endif? (Was: Re: (PR#7943) documentation ...)

2005-06-15 Thread Henrik Bengtsson
Just a comment, that probably applies to a lot more Rd files; when trying to developer cross-platform R code, it is very useful to have identical documentation whatever platform you are working on. That is, I would prefer \section{Windows-specific comments}{ ... } rather than #ifdef windo

Re: [Rd] (PR#7943) documentation enhancement: Note in ?seek for Windows

2005-06-15 Thread tplate
Fair enough. But for the benefit of the unfortunate souls having to work in Windows, it would be nice if the documentation were as explicit as possible about what is and is not known about particular issues (while still being concise). How about the following: NEW: #ifdef windows The valu

Re: [Rd] Calling C from Fortran

2005-06-15 Thread Huntsinger, Reid
(Forgot to post.) Yes, that was a typo, and the reason is the same; the C function expects a value rather than its address. That's why you can't use it directly from Fortran (aside from naming issues) but it's fine in C. Reid Huntsinger -Original Message- From: Gilles GUILLOT [mailto:[EMA

Re: [Rd] (PR#7943) documentation enhancement: Note in ?seek for

2005-06-15 Thread ripley
Actually, there is a known issue: it is often wrong for binary files opened in append mode, and we have caught by that too. So those writers did make the sort of error I did not trust them not to make. On Wed, 15 Jun 2005, Prof Brian Ripley wrote: > I think the proposed change is appropriate o

Re: [Rd] (PR#7943) documentation enhancement: Note in ?seek for

2005-06-15 Thread ripley
I think the proposed change is appropriate only if the return value is *known* to be reliable for binary files. I for one do not trust the writers of an OS whom have made such a serious error in one mode (and many other errors elsewhere) not to have made one in closely related code. Since it i

[Rd] documentation enhancement: Note in ?seek for Windows (PR#7943)

2005-06-15 Thread tplate
[I started a new bug report for this issue because it was not the primary issue in the original discussion, which was PR#7899] [EMAIL PROTECTED] wrote: > Tony Plate wrote: > [snip] >>[EMAIL PROTECTED] wrote: >>[snip] >>>Note that ?seek currently tells us "The value returned by >>>seek(where

Re: [Rd] (PR#7942) extra spaces before imag part when printing complex numbers

2005-06-15 Thread cyril . humbert
Prof Brian Ripley wrote: > This is intentional: it aligns the numbers. E.g. > > >options(width=12) > >print(c(1+1i, 1-10i, 1+100i)) > [1] 1+ 1i > [2] 1- 10i > [3] 1+100i > > Neat, eh? > > What made you think this was a bug? Ah ok, I've misunderstood this feature probably perhaps because, at

Re: [Rd] Calling C from Fortran

2005-06-15 Thread Gilles GUILLOT
Thanks for your reply. Am I write if I say that the wrapper shoul be double F77_SUB(mygammafn)(double *x) { return gammafn(*x); } instead of double F77_SUB(mygammafn)(double *x) { return gammafn(x); } the first does not compile. wrapper2.c: In function `mygammafn_': wrapper2.c:6: error: incomp

Re: [Rd] italic (PR#7932)

2005-06-15 Thread Gabor Grothendieck
On 6/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote: > > > [EMAIL PROTECTED] wrote: > > > >> Full_Name: G. Grothendieck > >> Version: R version 2.1.0, 2005-05-14 > >> OS: Windows XP > >> Submission from: (NULL) (216.59.254.207) > >> > >> > >> This

Re: [Rd] italic (PR#7932)

2005-06-15 Thread ripley
On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] wrote: > >> Full_Name: G. Grothendieck >> Version: R version 2.1.0, 2005-05-14 >> OS: Windows XP >> Submission from: (NULL) (216.59.254.207) >> >> >> This code: >> >> >>> plot(1:10) >>> text(5,5,lab=expression(italic(22*"33"))) > > F

Re: [Rd] (PR#7942) extra spaces before imag part when printing

2005-06-15 Thread ripley
This is intentional: it aligns the numbers. E.g. > options(width=12) > print(c(1+1i, 1-10i, 1+100i)) [1] 1+ 1i [2] 1- 10i [3] 1+100i Neat, eh? What made you think this was a bug? On Wed, 15 Jun 2005 [EMAIL PROTECTED] wrote: > Hello, > > When printing sequence of complex numbers, extra spaces

[Rd] extra spaces before imag part when printing complex numbers (PR#7942)

2005-06-15 Thread cyril . humbert
Hello, When printing sequence of complex numbers, extra spaces are sometimes printed between real and imaginary part of each number. For example: ## R Version 2.1.1 beta (2005-06-13) [Debian unstable, i386] ## and R Version 2.1.0 [Debian unstable, i386] > print(c(1+1i, 10+1i, 100+1

Re: [Rd] write.table confused by rownames/colnames (PR#7941)

2005-06-15 Thread rasche
Hello, Alright, I did not look at it that way I admit. I built a matrix with multiple row names (as a data.frame). Confusion started when exporting this as a spread-sheet. Now it all works fine. Thanks and sorry for the false alarm, Axel Prof Brian Ripley wrote: > It seems that you are the one

Re: [Rd] write.table confused by rownames/colnames (PR#7941)

2005-06-15 Thread Prof Brian Ripley
It seems that you are the one who is confused: the help file says By default there is no column name for a column of row names. If 'col.names = NA' a blank column name is added. If there are no row names, there is no point in adding a blank column name for them. So what did *you* t

Re: [Rd] write.table confused by rownames/colnames (PR#7941)

2005-06-15 Thread ligges
[EMAIL PROTECTED] wrote: > Full_Name: Axel Rasche > Version: 2.1.0 > OS: Win2000 > Submission from: (NULL) (141.14.21.81) > > > Hi, > > write.table does not accept the second statement with > . > I do not see why this should not be possible. > > test = matrix(1:4, 2, 2, dimnames = list( c(

Re: [Rd] R 2.1.1 slated for June 20

2005-06-15 Thread Marc Schwartz
On Wed, 2005-06-15 at 07:51 +0100, Prof Brian Ripley wrote: > Our preference is F77 compilers over F9x ones, as the lists Simon showed > reflects - we decided to prefer F95 to F90 in future, though. > > My experience is that g77 from gcc-3.4.x is preferable to gfortran. > As I said earlier, once

Re: [Rd] italic (PR#7932)

2005-06-15 Thread ligges
[EMAIL PROTECTED] wrote: > Full_Name: G. Grothendieck > Version: R version 2.1.0, 2005-05-14 > OS: Windows XP > Submission from: (NULL) (216.59.254.207) > > > This code: > > >>plot(1:10) >>text(5,5,lab=expression(italic(22*"33"))) For mathematical non-character-string annotation a math font i

Re: [Rd] R 2.1.1 slated for June 20

2005-06-15 Thread Marc Schwartz
On Tue, 2005-06-14 at 23:08 -0500, Marc Schwartz wrote: > In reviewing the Add/Remove Application GUI, gfortran is listed as an > "Extra Package" in the Development Tools Group. > > g77 is not listed in that Group or in the Legacy Development Group, so > it would appear that it is a "silent" pa

[Rd] write.table confused by rownames/colnames (PR#7941)

2005-06-15 Thread rasche
Full_Name: Axel Rasche Version: 2.1.0 OS: Win2000 Submission from: (NULL) (141.14.21.81) Hi, write.table does not accept the second statement with . I do not see why this should not be possible. test = matrix(1:4, 2, 2, dimnames = list( c("a","b"), c("c","d") )) write.table(test, file = "te

[Rd] Calling C function from Fortran

2005-06-15 Thread Gilles GUILLOT
Hi all, the example in the R doc and the hints from Shusong Jin , Ingmar Visser and Reid Huntsinger (thanks all three) refer to the case where the function does not have arguments. I'm still looking for a proper sequence of commands to call C functions with arguemnts from R. Imagine I want

Re: [Rd] source() chdir does not work (PR#7940)

2005-06-15 Thread ripley
This is already fixed: o source(file, chdir = TRUE) was not checking that 'file' was a filepath (rather than a URL). For 2.1.0 only, it did not work even if 'file' was a filepath. >From the R FAQ: Before you actually submit a bug report, you should check whether the b

[Rd] source() chdir does not work (PR#7940)

2005-06-15 Thread agalakhov
Full_Name: Alex Galakhov Version: 2.1.0 OS: Linux (Debian) Submission from: (NULL) (195.19.131.68) After software upgrade source() does not work properly anymore. It completely ignores the chdir= parameter. This is because is.character(file) is always false after the assignment file<-file(file).

Re: [Rd] R 2.1.1 slated for June 20

2005-06-15 Thread Peter Dalgaard
Marc Schwartz <[EMAIL PROTECTED]> writes: > On Wed, 2005-06-15 at 00:01 +0200, Peter Dalgaard wrote: > > Marc Schwartz <[EMAIL PROTECTED]> writes: > > > > > Prof. Ripley, > > > > > > If my read of the config.log is correct, it would appear that g77 was > > > used and not gfortran (which is insta