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)
>>
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"
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
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_
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
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
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
(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
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
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
[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
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
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
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
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
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
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
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
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
[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(
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
[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
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
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
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
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
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).
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
28 matches
Mail list logo