[Rd] package manual without index? check breaks with - LaTeX errors when creating PDF version.
Hello,
What am I doing wrong about creating an index for my package documentation?
Using 2.9.2, I am checking the gld package. It reports the following (all
earlier lines OK):
* checking PDF version of manual ... WARNING
LaTeX errors when creating PDF version.
This typically indicates Rd problems.
* checking PDF version of manual without index ... ERROR
When I look in the gld.Rcheck directory there is no log file there.
Running pdflatex gld-manual.tex works, though it produces a pdf file without
an index. The only warnings from pdflatex are about references to functions
in other packages, such as
pdfTeX warning (dest): name{Rfn.optim} has been referenced but does not exist,
and two about loading stuff that R has already loaded earlier
Package hyperref Warning: Option `hyperindex' has already been used,
Package hyperref Warning: Option `pagebackref' has already been used,
Re-running pdflatex generates the index in the pdf file correctly.
Thanks in advance,
Robert King
--
Robert King, Statistics, School of Mathematical & Physical Sciences,
University of Newcastle, Australia (CRICOS Provider Number: 00109J)
Room V133 ph +61 2 4921 5548
robert.k...@newcastle.edu.au http://tolstoy.newcastle.edu.au/~rking/
"It might be in the basement,
I'll go upstairs and check .." Escher
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unexpected behaviour of isSymmetric() (PR#14000)
Full_Name: Mike Danilov
Version: 2.9.0
OS: Fedora Core 9
Submission from: (NULL) (142.103.121.198)
When checking for the symmetry of a matrix, function isSymmetric.matrix() gets
confused by the discrepancy of colnames/rownames if its argument. See the code
snippet below. Perhaps it's a problem of the matrix product which copies
colnames of the first argument but not the rownames of the second to its value.
Not sure which one should be fixed but the way it is now it seems illogical that
X'X is deemed to be non-symmetric.
x <- c(1,2,3)
names(x) <- c("v1","v2","v3")
isSymmetric(x%*%t(x)) ## returns FALSE instead of TRUE
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unexpected behaviour of isSymmetric() (PR#14000)
On 10/12/2009 02:05 AM, m...@stat.ubc.ca wrote:
Full_Name: Mike Danilov
Version: 2.9.0
OS: Fedora Core 9
Submission from: (NULL) (142.103.121.198)
When checking for the symmetry of a matrix, function isSymmetric.matrix() gets
confused by the discrepancy of colnames/rownames if its argument. See the code
snippet below. Perhaps it's a problem of the matrix product which copies
colnames of the first argument but not the rownames of the second to its value.
Not sure which one should be fixed but the way it is now it seems illogical that
X'X is deemed to be non-symmetric.
x<- c(1,2,3)
names(x)<- c("v1","v2","v3")
isSymmetric(x%*%t(x)) ## returns FALSE instead of TRUE
It seems to be concerned with the names
> y <- x %*% t(x)
> y
v1 v2 v3
[1,] 1 2 3
[2,] 2 4 6
[3,] 3 6 9
> isSymmetric( y )
[1] FALSE
# dropping the dimnames
> isSymmetric( structure( y, dimnames = NULL ) )
[1] TRUE
# pass the ... along this path : isSymmetric > all.equal > all.equal.numeric
> isSymmetric( y, check.attributes = F )
[1] TRUE
# set the dimnames equal
> dimnames( y ) <- rep( list( names(x) ), 2 )
> isSymmetric( y )
[1] TRUE
Not sure this is expected behaviour
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/BcPw : celebrating R commit #5
|- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc
`- http://tr.im/yw8E : New R package : sos
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unexpected behaviour of isSymmetric() (PR#14000)
On Mon, Oct 12, 2009 at 6:41 AM, Romain Francois
wrote:
> On 10/12/2009 02:05 AM, m...@stat.ubc.ca wrote:
>>
>> Full_Name: Mike Danilov
>> Version: 2.9.0
>> OS: Fedora Core 9
>> Submission from: (NULL) (142.103.121.198)
>>
>>
>> When checking for the symmetry of a matrix, function isSymmetric.matrix()
>> gets
>> confused by the discrepancy of colnames/rownames if its argument. See the
>> code
>> snippet below. Perhaps it's a problem of the matrix product which copies
>> colnames of the first argument but not the rownames of the second to its
>> value.
>> Not sure which one should be fixed but the way it is now it seems
>> illogical that
>> X'X is deemed to be non-symmetric.
>>
>> x<- c(1,2,3)
>> names(x)<- c("v1","v2","v3")
>> isSymmetric(x%*%t(x)) ## returns FALSE instead of TRUE
>
> It seems to be concerned with the names
>
>> y <- x %*% t(x)
>> y
> v1 v2 v3
> [1,] 1 2 3
> [2,] 2 4 6
> [3,] 3 6 9
>
>> isSymmetric( y )
> [1] FALSE
>
> # dropping the dimnames
>> isSymmetric( structure( y, dimnames = NULL ) )
> [1] TRUE
>
> # pass the ... along this path : isSymmetric > all.equal > all.equal.numeric
>> isSymmetric( y, check.attributes = F )
> [1] TRUE
>
> # set the dimnames equal
>> dimnames( y ) <- rep( list( names(x) ), 2 )
>> isSymmetric( y )
> [1] TRUE
>
> Not sure this is expected behaviour
>
> Romain
I think the problem is more with the propagation of the column names
in the construction x %*% t(x). If you use the tcrossprod function to
create x %*% t(x) more carefully then the results are sensible
> x<- c(1,2,3); names(x)<- c("v1","v2","v3")
> isSymmetric(tcrossprod(x))
[1] TRUE
> tcrossprod(x)
[,1] [,2] [,3]
[1,]123
[2,]246
[3,]369
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] weigths in nls (PR#13991)
see below.
On Fri, Oct 9, 2009 at 1:35 PM, Tony Plate wrote:
> This is expected behavior from the way nls() is written. The nls() function
> has a "..." argument, which means that additional arguments are allowed.
>
> Under "Arguments" the docs say:
> |...| Additional optional arguments. None are used at present.
>
>
> As far as I can see in the code, nothing at all is done with the additional
> arguments (consistent with the docs). I guess the "..." argument is there
> to allow for future development (though I'm not sure what is gained by
> including "..." as a formal argument now, and not just adding it in the
> future if and when it is needed.)
¿Maybe it allows for other people to write methods?
Kjetil
>
> In general, the use of ... arguments does add flexibility, but it takes away
> some error-checking.
>
> -- Tony Plate
>
> stephen.b...@cibc.com wrote:
>>
>> Potential bug:
>>
>> I mistyped weights in the call ('weigths') and it did not produce any
>> error=
>> message. The coefs were exactly the same like without weights, so I was
>> su=
>> spicious and when weights(nls1) gave NULL, I saw my typo.
>>
>> Usually the function will say "Unused arguments", which shows you the
>> error=
>> , but not nls.
>>
>> Regards
>> Stephen
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> 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
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unexpected error steming from print.data.frame
Hello All,
At the suggestion of commenters on a discussion at stack overflow (
http://stackoverflow.com/questions/1535021/whats-the-biggest-r-gotcha-youve-run-across/1535433#1535433
), I'm forwarding the following behavior report to this list.
R Session:
> a<-data.frame(c(1,2,3,4),c(4,3,2,1))
> a<-a[-3,]
> a
c.1..2..3..4. c.4..3..2..1.
1 1 4
2 2 3
4 4 1
> a[4,1]<-1
> a
Error in data.frame(c.1..2..3..4. = c("1", "2", "4", "1"), c.4..3..2..1. = c("
4", :
duplicate row.names: 4
What's going on:
1. A four row data.frame is created, so the rownames are c(1,2,3,4)
2. The third row is deleted, so the rownames are c(1,2,4)
3. A fourth row is added, and R automatically sets the row name equal to
the index i.e. 4, so the row names are c(1,2,4,4).
4. print.data.frame throws an error because it requires unique row names
It seems to me that either R should automatically generate a unique row names,
or print.data.frame should accept duplicates. Looking at the manual 2.3.2, it
is unclear whether row names are required to be unique, but the help page for
data.frame states: "A data frame is a list of variables of the same number of
rows with unique row names,..." This implies that a[4,1]<-1 creates an invalid
data.frame object.
Cheers,
Ian Fellows
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
