Re: [Rd] Compilation problems
On 09 Aug 2014, at 16:50 , André Z. D. A. wrote: >> Worst case is that you'll have to install TeX in your local user directory. > > I'll try to find it again. The search I tried didn't look as easy, very few > results, none helpful. And if I could install *just the fonts* on my local > dir, instead of the full TeX, it would be perfect. But I don't know how to do > it. Is it possi If you are playing with the R-devel branch (or rather, trunk), then just hold your horses for a little while. There seems to be a reversed-logic bug that bites if you have inconsolata.sty and not zi4.sty. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: diag(x, n) not preserving integer and logical x
> Duncan Murdoch
> on Fri, 8 Aug 2014 10:51:10 -0400 writes:
Thank you, Duncan (read inline)
> On 07/08/2014, 4:51 AM, Martin Maechler wrote:
>> This is not at all something new(*). As maintainer of the
>> Matrix package, I don't like this inconsistency of base
>> R's diag(). We have had the following -- forever, almost
>> surely inherited from S and S+ :
>>
>> diag(x) preserves the storage mode of x for 'complex' and
>> 'double' precision, but converts integer and logicals to
>> double :
>>
>> > storage.mode(x <- 1i + 1:7); storage.mode(diag(x)) [1]
>> "complex" [1] "complex" > storage.mode(x <- 0 + 1:7);
>> storage.mode(diag(x)) [1] "double" [1] "double"
>>
>> > storage.mode(x <- 1:7); storage.mode(diag(x)) [1]
>> "integer" [1] "double" > storage.mode(x <- 1:7 > 3);
>> storage.mode(diag(x)) [1] "logical" [1] "double"
>>
>> and so it is actually a bit cumbersome (and a memory
>> waste in the case of large matrices) to create a diagonal
>> integer or logical matrix.
>>
>> The help page does not mention the current behavior,
>> though you may say it alludes to the fact that logicals
>> are treated as 0/1 implicitly (**)
>>
> I think the change to preserve integer makes sense, but
> preserving logical does not. A diagonal matrix has zeros
> off the diagonal, and they are not logical.
That's true if you come from the usual mathematical thinking
about matrices; and the same would extend to triangular
matrices, too.
In (S and) R however, matrices and array()s have always been
more general than in applied math (and have allowed any atomic (and even
more general) content).
> Having diag() sometimes return a matrix with FALSE off the diagonal just
> looks wrong.
[... if you have never seen them ..]
OTOH, sparse matrices (in the Matrix package) and also sparse
and dense triangular matrices (all with their classes) have
always (in the Matrix package) had their logical counter parts,
> Diagonal(5)
5 x 5 diagonal matrix of class "ddiMatrix"
[,1] [,2] [,3] [,4] [,5]
[1,]1....
[2,].1...
[3,]..1..
[4,]...1.
[5,]....1
> Diagonal(5) > 0
5 x 5 diagonal matrix of class "ldiMatrix"
[,1] [,2] [,3] [,4] [,5]
[1,] TRUE....
[2,]. TRUE...
[3,].. TRUE..
[4,]... TRUE.
[5,].... TRUE
>
and if you consider any sparseness for logical matrices, typical
application cases would have the TRUE to be rare rather than the
FALSE... and then of course, we have had the as.numeric()
behavior of S and R, all this leading to
the usual FALSE <==> 0 mapping
>> If I change this behavior such that logical and integer x
>> are preserved,
>>
>> make check-all
>>
>> which includes all checks, including those of all
>> recommended packages (including Matrix!) successfully
>> runs through; so at least base + Recommended R never
>> relies on the current behavior, nor should any "well
>> programmed" R code ...
>>
>> Hence my proposal, somewhat tentative for now, to change
>> this diag(.) behavior.
>>
>> Martin Maechler
>>
>> *) and possibly something we "can not" change in R,
>> because too much code implicitely may be depending on it,
>> but now I hope we can still...
>>
>> **) BTW, also including the somewhat amusing case of
>> diag(c("A","B")).
>>
>> __
>> 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] Compilation problems
No, Peter, I have the "(2014-07-10, Sock it to Me) R-3.1.1.tar.gz" source. Thanks for pointing it. So (I hope) it should be ok. Right? Peter Dalgaard, Professor wrote: > If you are playing with the R-devel branch (or rather, trunk), then just hold > your horses for a little while. There seems to be a reversed-logic bug that > bites if you have inconsolata.sty and not zi4.sty. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compilation problems
On 11 Aug 2014, at 15:46 , André Z. D. A. wrote: > No, Peter, I have the "(2014-07-10, Sock it to Me) R-3.1.1.tar.gz" source. > Thanks for pointing it. So (I hope) it should be ok. Right? Not unlikely. (I goofed and thought that it only affected the development version.) Check kpsewhich inconsolata.sty if it is found, and zi4.sty is not, then it should be fixed by an upcoming patch release. -pd > > > Peter Dalgaard, Professor wrote: >> If you are playing with the R-devel branch (or rather, trunk), then just hold >> your horses for a little while. There seems to be a reversed-logic bug that >> bites if you have inconsolata.sty and not zi4.sty. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error when assigning value in environment which is a locked binding
On Aug 10, 2014, at 10:07 PM, Winston Chang wrote: > Another oddity - even though there's an error thrown in assignment to > x$y$z, the assignment succeeds. > > x <- new.env() > x$y <- new.env() > lockEnvironment(x, bindings = TRUE) > x$y$z <- 1 > # Error in x$y$z <- 1 : cannot change value of locked binding for 'y' > > x$y$z > # [1] 1 > > > So I assume there must be a bug somewhere in here. > Why? In both cases (including your previous post) the you have two separate assignments: (x$y)$z <-1 followed by x$y <- y. So the first one always succeeds since there is no reason for it not to, but the second one doesn't because the binding is locked. I presume the confusion comes from the fact that environments are mutable, so x$y changes even if it was not assigned so it's irrelevant if the second assignment succeeds or not. Cheers, Simon > -Winston > > > > On Sun, Aug 10, 2014 at 8:46 PM, Winston Chang > wrote: > >> If an environment x contains a locked binding y which is also an >> environment, and then you try to assign a value to a binding inside of >> y, it can either succeed or fail, depending on how you refer to >> environment y. >> >> x <- new.env() >> x$y <- new.env() >> lockEnvironment(x, bindings = TRUE) >> >> # This assignment fails >> x$y$z <- 1 >> # Error in x$y$z <- 1 : cannot change value of locked binding for 'y' >> >> # Saving x$y to another variable, and then assigning there works >> y2 <- x$y >> y2$z <- 10 # OK >> print(x$y$z) >> # 10 >> >> >> Is this a bug or a feature? I realize that x$y is a locked binding >> while y2 is not. >> >> -Winston >> > > [[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
Re: [Rd] RFC: diag(x, n) not preserving integer and logical x
Would you allow a list argument to diag() as well? I see that
Matrix::Diagonal does not accept it. Perhaps nothing in Matrix deals
with matrices of lists, but they are handy and for diag() it may be
simpler to allow lists than to check for and reject them.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Mon, Aug 11, 2014 at 7:26 AM, Martin Maechler
wrote:
>> Duncan Murdoch
>> on Fri, 8 Aug 2014 10:51:10 -0400 writes:
>
> Thank you, Duncan (read inline)
>
> > On 07/08/2014, 4:51 AM, Martin Maechler wrote:
> >> This is not at all something new(*). As maintainer of the
> >> Matrix package, I don't like this inconsistency of base
> >> R's diag(). We have had the following -- forever, almost
> >> surely inherited from S and S+ :
> >>
> >> diag(x) preserves the storage mode of x for 'complex' and
> >> 'double' precision, but converts integer and logicals to
> >> double :
> >>
> >> > storage.mode(x <- 1i + 1:7); storage.mode(diag(x)) [1]
> >> "complex" [1] "complex" > storage.mode(x <- 0 + 1:7);
> >> storage.mode(diag(x)) [1] "double" [1] "double"
> >>
> >> > storage.mode(x <- 1:7); storage.mode(diag(x)) [1]
> >> "integer" [1] "double" > storage.mode(x <- 1:7 > 3);
> >> storage.mode(diag(x)) [1] "logical" [1] "double"
> >>
> >> and so it is actually a bit cumbersome (and a memory
> >> waste in the case of large matrices) to create a diagonal
> >> integer or logical matrix.
> >>
> >> The help page does not mention the current behavior,
> >> though you may say it alludes to the fact that logicals
> >> are treated as 0/1 implicitly (**)
> >>
>
> > I think the change to preserve integer makes sense, but
> > preserving logical does not. A diagonal matrix has zeros
> > off the diagonal, and they are not logical.
>
> That's true if you come from the usual mathematical thinking
> about matrices; and the same would extend to triangular
> matrices, too.
>
> In (S and) R however, matrices and array()s have always been
> more general than in applied math (and have allowed any atomic (and even
> more general) content).
>
> > Having diag() sometimes return a matrix with FALSE off the diagonal just
> > looks wrong.
>
> [... if you have never seen them ..]
> OTOH, sparse matrices (in the Matrix package) and also sparse
> and dense triangular matrices (all with their classes) have
> always (in the Matrix package) had their logical counter parts,
>
> > Diagonal(5)
> 5 x 5 diagonal matrix of class "ddiMatrix"
>[,1] [,2] [,3] [,4] [,5]
> [1,]1....
> [2,].1...
> [3,]..1..
> [4,]...1.
> [5,]....1
> > Diagonal(5) > 0
> 5 x 5 diagonal matrix of class "ldiMatrix"
>[,1] [,2] [,3] [,4] [,5]
> [1,] TRUE....
> [2,]. TRUE...
> [3,].. TRUE..
> [4,]... TRUE.
> [5,].... TRUE
> >
>
> and if you consider any sparseness for logical matrices, typical
> application cases would have the TRUE to be rare rather than the
> FALSE... and then of course, we have had the as.numeric()
> behavior of S and R, all this leading to
> the usual FALSE <==> 0 mapping
>
>
> >> If I change this behavior such that logical and integer x
> >> are preserved,
> >>
> >> make check-all
> >>
> >> which includes all checks, including those of all
> >> recommended packages (including Matrix!) successfully
> >> runs through; so at least base + Recommended R never
> >> relies on the current behavior, nor should any "well
> >> programmed" R code ...
> >>
> >> Hence my proposal, somewhat tentative for now, to change
> >> this diag(.) behavior.
> >>
> >> Martin Maechler
> >>
> >> *) and possibly something we "can not" change in R,
> >> because too much code implicitely may be depending on it,
> >> but now I hope we can still...
> >>
> >> **) BTW, also including the somewhat amusing case of
> >> diag(c("A","B")).
> >>
> >> __
> >> 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
Re: [Rd] diag(x, n) not preserving integer and logical x
Martin Maechler wrote: > diag(x) preserves the storage mode of x for 'complex' and > 'double' precision, but converts integer and logicals to double : Duncan Murdoch wrote: > I think the change to preserve integer makes sense, but preserving > logical does not. A diagonal matrix has zeros off the diagonal, and > they are not logical. Having diag() sometimes return a matrix with > FALSE off the diagonal just looks wrong. Making diag(1:10) return an integer matrix does make sense, but it could still be undesirable. Often, the user will have intended to get a real matrix, and will after another operation, but only after an unnecessary coercion is done. For example: x<-diag(1:10); x[1,2]<-2.0 I personally think keeping diag(1:10) integer is best, but I thought I'd point out the contrary argument. Having diag(rep(TRUE,10)) return a logical matrix with FALSE off the diagonal does not strike me as too odd. It makes sense if you think of (FALSE, TRUE) as forming a field under operations of sum=XOR and product=AND. And of course it will typically be converted to a 0/1 matrix later if that's what was actually intended. Radford Neal __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Define 'in' for new class
Hi List, Is it possible to define how 'in' works for an object of a specific class (to achieve a similar result to implementing the iterator protocol in a class Python)? Cheers, Simon Knapp [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
