[Rd] scientific notation and comparison with character variable
L.S. Is the following expected and/or documented? > 1e-2 < "0.05" [1] TRUE > 1e-4 < "0.05" [1] FALSE Many thanks in advance for any pointer. Best, Tobias > sessionInfo() R Under development (unstable) (2013-01-01 r61512) Platform: i386-w64-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] scientific notation and comparison with character variable
It's expected. From ?"<": If the two arguments are atomic vectors of different types, one is coerced to the type of the other, the (decreasing) order of precedence being character, complex, numeric, integer, logical and raw. > as.character(1e-2) < 0.05 [1] TRUE > as.character(1e-4) < 0.05 [1] FALSE Best, -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com On Wed, Jan 2, 2013 at 12:38 PM, Tobias Verbeke wrote: > L.S. > > Is the following expected and/or documented? > >> 1e-2 < "0.05" > [1] TRUE >> 1e-4 < "0.05" > [1] FALSE > > Many thanks in advance for any pointer. > > Best, > Tobias > >> sessionInfo() > R Under development (unstable) (2013-01-01 r61512) > Platform: i386-w64-mingw32/i386 (32-bit) > > locale: > [1] LC_COLLATE=English_United States.1252 > [2] LC_CTYPE=English_United States.1252 > [3] LC_MONETARY=English_United States.1252 > [4] LC_NUMERIC=C > [5] LC_TIME=English_United States.1252 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > __ > 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] scientific notation and comparison with character variable
Thanks and apologies for the noise. Best wishes, Tobias On 01/02/2013 07:43 PM, Joshua Ulrich wrote: It's expected. From ?"<": If the two arguments are atomic vectors of different types, one is coerced to the type of the other, the (decreasing) order of precedence being character, complex, numeric, integer, logical and raw. as.character(1e-2) < 0.05 [1] TRUE as.character(1e-4) < 0.05 [1] FALSE Best, -- Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com On Wed, Jan 2, 2013 at 12:38 PM, Tobias Verbeke wrote: L.S. Is the following expected and/or documented? 1e-2 < "0.05" [1] TRUE 1e-4 < "0.05" [1] FALSE Many thanks in advance for any pointer. Best, Tobias sessionInfo() R Under development (unstable) (2013-01-01 r61512) Platform: i386-w64-mingw32/i386 (32-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base __ 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] Understanding svd usage and its necessity in generalized inverse calculation
Hi all, On Tue, Jan 1, 2013 at 6:01 PM, Thomas Lumley wrote: > Now, if most of the matrices you are trying to invert are actually > invertible (as I would hope), it may be quicker to use the Cholesky > approach will a fallback to the SVD for semidefinite matrices. That is, > something like > > tryCatch( > chol2inv(chol(xx)), > error=function(e) ginv(xx) > ) > > Just to be clear, the Amelia package takes this approach, since our EM algorithm can wander off into questionable parts of the parameter space (with non-invertible matrices). The issue that Paul pointed out was an issue my implementation of the Cholesky approach which broke the try() function and so used SVD for every inverse, which of course is slow(er). This has been fixed in the most recent version (1.6.4) and we are finishing up a version that uses Rcpp to speed things up quite a bit. Cheers, matt. ~~~ Matthew Blackwell Assistant Professor of Political Science University of Rochester url: http://www.mattblackwell.org > Most of the time you will get the Cholesky branch, which is much faster > (about five-fold for 10x10 matrices on my system). On my system and using > a 10x10 matrix the overhead in the tryCatch() is much smaller than the time > taken by either set of linear algebra, so there is a net gain as long as > even a reasonably minority of the matrices are actually invertible. > > You can probably do slightly better by replacing the chol2inv() with > backsolve(): solving just the systems of linear equations you need is > usually preferable to constructing a matrix inverse. > > > Note that this approach will give wrong answers without warning if the > matrices are not symmetric. > >-thomas > > -- > Thomas Lumley > Professor of Biostatistics > University of Auckland > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] formal vs. passed args: parent.frame() behavior.
Happy 2013, Day 2.
I can't seem to figure out why parent.frame() works differently depending
on whether it is a formal/default argument or a passed argument.
# code: basic setup
tmp <- tempfile()
A <- 101
save(A,file=tmp);rm(A)
# these work as expected, loading into the parent of the call load()
load(tmp);str(A);rm(A)
load(tmp, parent.frame());str(A);rm(A)
load(tmp, environment());str(A);rm(A)
# but these are odd, using local()
# works
local( { load(tmp); str(A) } )
#FAILS even though env=parent.frame() by default !?!!
local( { load(tmp,env=parent.frame()); str(A) } )
# works as well!
local( { load(tmp,env=environment()); str(A) } )
ls()## NOT in .GlobalEnv, correct!
args(load) ## env=parent.frame() by default, but is it???
My question is why parent.frame() can't be specified in the args without
changing the behavior of the call itself if you aren't at the top level.
What am I missing?
Jeff
# output #
> tmp <- tempfile()
> A <- 101
> save(A,file=tmp);rm(A)
>
> # these work as expected, loading into the parent of the call load()
> load(tmp);str(A);rm(A)
num 101
> load(tmp, parent.frame());str(A);rm(A)
num 101
> load(tmp, environment());str(A);rm(A)
num 101
>
>
>
> # but these are odd, using local()
>
> # works
> local( { load(tmp); str(A) } )
num 101
>
> #fails even though env=parent.frame() by default !?!!
> local( { load(tmp,env=parent.frame()); str(A) } )
Error in str(A) : object 'A' not found
>
> # works as well!
> local( { load(tmp,env=environment()); str(A) } )
num 101
>
> ls()## NOT in .GlobalEnv, correct!
[1] "tmp"
> args(load) ## env=parent.frame() by default, but is it???
function (file, envir = parent.frame())
NULL
>
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] formal vs. passed args: parent.frame() behavior.
On Jan 3, 2013, at 05:28 , Jeff Ryan wrote:
> Happy 2013, Day 2.
>
> I can't seem to figure out why parent.frame() works differently depending
> on whether it is a formal/default argument or a passed argument.
Because defaults are evaluated in the function's evaluation environment,
whereas passed arguments are evaluated in the caller's environment. Notice in
particular, that defaults can refer to other arguments (as in probability=!freq
in hist.default) and even to internal variables occasionally.
>
> # code: basic setup
>
> tmp <- tempfile()
> A <- 101
> save(A,file=tmp);rm(A)
>
> # these work as expected, loading into the parent of the call load()
> load(tmp);str(A);rm(A)
> load(tmp, parent.frame());str(A);rm(A)
> load(tmp, environment());str(A);rm(A)
>
>
>
> # but these are odd, using local()
>
> # works
> local( { load(tmp); str(A) } )
>
> #FAILS even though env=parent.frame() by default !?!!
> local( { load(tmp,env=parent.frame()); str(A) } )
>
> # works as well!
> local( { load(tmp,env=environment()); str(A) } )
>
> ls()## NOT in .GlobalEnv, correct!
> args(load) ## env=parent.frame() by default, but is it???
>
>
> My question is why parent.frame() can't be specified in the args without
> changing the behavior of the call itself if you aren't at the top level.
>
> What am I missing?
>
> Jeff
>
>
> # output #
>
>> tmp <- tempfile()
>> A <- 101
>> save(A,file=tmp);rm(A)
>>
>> # these work as expected, loading into the parent of the call load()
>> load(tmp);str(A);rm(A)
> num 101
>> load(tmp, parent.frame());str(A);rm(A)
> num 101
>> load(tmp, environment());str(A);rm(A)
> num 101
>>
>>
>>
>> # but these are odd, using local()
>>
>> # works
>> local( { load(tmp); str(A) } )
> num 101
>>
>> #fails even though env=parent.frame() by default !?!!
>> local( { load(tmp,env=parent.frame()); str(A) } )
> Error in str(A) : object 'A' not found
>>
>> # works as well!
>> local( { load(tmp,env=environment()); str(A) } )
> num 101
>>
>> ls()## NOT in .GlobalEnv, correct!
> [1] "tmp"
>> args(load) ## env=parent.frame() by default, but is it???
> function (file, envir = parent.frame())
> NULL
>>
>
> --
> Jeffrey Ryan
> jeffrey.r...@lemnica.com
>
> www.lemnica.com
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
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
