search for: bugous

...users would expect: If you multiply a numeric with a "kind of logical" matrix (a pattern one), you will expect that the TRUE/FALSE matrix will be treated as a 1/0 matrix because it is combined with a numeric matrix. So we could say that in this case, the Matrix package behavior is clearly bugous .... but still it has been the behavior for the last 10 years or so. RFC 1: "Change 1": I currently propose to change this behavior for the upcoming release of Matrix (version 1.2-0), though I have no idea if dependent packages would partly fail their checks or otherwise have changed be...

...ernal(inspect(y)) @0x000000000a285648 13 INTSXP g0c0 [REF(65535)] -1000 : 2000000000 (compact) > y <- -1e3:2.1e9 ;.Internal(inspect(y)) @0x0000000019925930 13 INTSXP g0c0 [REF(65535)] -1000 : 2100000000 (compact) and here, y is correct, just the printing from .Internal(inspect(y)) is bugous (probably prints the double as an integer): > y <- -1e3:2.2e9 ; .Internal(inspect(y)) @0x00000000195c0178 14 REALSXP g0c0 [REF(65535)] -1000 : -2094967296 (compact) > length(y) [1] 2200001001 > tail(y) [1] 2.2e+09 2.2e+09 2.2e+09 2.2e+09 2.2e+09 2.2e+09 > tail(y) - 2....

On Tue, Apr 25, 2017 at 02:41:58PM +0000, Cook, Malcolm wrote: > Might this combination serve the purpose: > * R session keeps an open handle on the tempdir it creates, > * whatever tempdir harvesting cron job the user has be made sensitive enough not to delete open files (including open directories) Good suggestion but doesn't work with the (increasingly popular)

...INTSXP g0c0 [REF(65535)] -1000 : 2000000000 (compact) >> > y <- -1e3:2.1e9 ;.Internal(inspect(y)) >> @0x0000000019925930 13 INTSXP g0c0 [REF(65535)] -1000 : 2100000000 (compact) >> >> and here, y is correct, just the printing from >> .Internal(inspect(y)) is bugous (probably prints the double as an integer): >> >> > y <- -1e3:2.2e9 ; .Internal(inspect(y)) >> @0x00000000195c0178 14 REALSXP g0c0 [REF(65535)] -1000 : -2094967296 (compact) >> > length(y) >> [1] 2200001001 >> > tail(y) >> [1] 2.2e+09...

Dear r-help@, A while ago I tried to bundle packages for offline installations. For this I created a script that would access ftp://cran.r-project.org/pub/R/src/contrib/ for each package in a loop. The first trial was bugous and it generated many bad URL requests to cran.r-project.org >From that moment I was not able to access r-project.org. My IP address is 87.70.177.68 Can you please help? Thank you, Guy [[alternative HTML version deleted]]

...5535)] -1000 : 2000000000 (compact) >> > y <- -1e3:2.1e9 ;.Internal(inspect(y)) >> @0x0000000019925930 13 INTSXP g0c0 [REF(65535)] -1000 : 2100000000 (compact) >> >> and here, y is correct, just the printing from >> .Internal(inspect(y)) is bugous (probably prints the double as an integer): > It's a '%ld' that probably needs to be '%lld' for Windows. Will fix > sometime soon. > Best, > luke I had guessed at something like that .. but "interestingly" it was quite different: Our cod...

Martin wrote: > Just this morning, > I found (again!, we had something close to this before) > the following related bugous behavior : > After interrupting a plot (which would have taken a few minutes and was > "wrong" anyway), starting another plot, interrupting again [with C-c], > and maybe the same once more, > R started just giving a ">" prompt > but did not react any further at...

...r example is what I'd expect is always a possibility on some platforms, all of course depending on low things such as root/syadmin/... "permission" to clean up etc. Jeroeen mentioned the fact that tempdir()s also can disappear for other reasons {his was multicore child processes .. bugously(?) implemented}. Further reasons may be race conditions / user code bugs / user errors, etc. Note that the R process which created the tempdir on startup always has the permission to remove it again. But you can also think a full file system, etc. Current R-devel's tempdir(check = TRUE)...

...ect is always a > possibility on some platforms, all of course depending on low > things such as root/syadmin/... "permission" to clean up etc. > > Jeroeen mentioned the fact that tempdir()s also can disappear > for other reasons {his was multicore child processes > .. bugously(?) implemented}. > Further reasons may be race conditions / user code bugs / user > errors, etc. > Note that the R process which created the tempdir on startup > always has the permission to remove it again. But you can also > think a full file system, etc. > > Current R-de...

...ed in the mean time} triggered some more comprehensive "research". I found that we have had a long-standing inconsistency at least between the documented and the real behavior. I am claiming that the documented behavior is desirable and hence R's current "real" behavior is bugous, and I am proposing to change it, in R-devel (to be 3.4.0) for now. In help(match) we have been saying | Exactly what matches what is to some extent a matter of definition. | For all types, \code{NA} matches \code{NA} and no other value. | For real and complex values, \code{NaN} values are...

...possibility on some platforms, all of course depending on low >> things such as root/syadmin/... "permission" to clean up etc. >> >> Jeroeen mentioned the fact that tempdir()s also can disappear >> for other reasons {his was multicore child processes >> .. bugously(?) implemented}. >> Further reasons may be race conditions / user code bugs / user >> errors, etc. >> Note that the R process which created the tempdir on startup >> always has the permission to remove it again. But you can also >> think a full file system, etc. &gt...

...00000000a285648 13 INTSXP g0c0 [REF(65535)] -1000 : 2000000000 (compact) > > y <- -1e3:2.1e9 ;.Internal(inspect(y)) > @0x0000000019925930 13 INTSXP g0c0 [REF(65535)] -1000 : 2100000000 (compact) > > and here, y is correct, just the printing from > .Internal(inspect(y)) is bugous (probably prints the double as an integer): > > > y <- -1e3:2.2e9 ; .Internal(inspect(y)) > @0x00000000195c0178 14 REALSXP g0c0 [REF(65535)] -1000 : -2094967296 (compact) > > length(y) > [1] 2200001001 > > tail(y) > [1] 2.2e+09 2.2e+09 2.2e+09 2.2e+09 2...

...x000000000a285648 13 INTSXP g0c0 [REF(65535)] -1000 : 2000000000 (compact) > > y <- -1e3:2.1e9 ;.Internal(inspect(y)) > @0x0000000019925930 13 INTSXP g0c0 [REF(65535)] -1000 : 2100000000 (compact) > > and here, y is correct, just the printing from > .Internal(inspect(y)) is bugous (probably prints the double as an integer): It's a '%ld' that probably needs to be '%lld' for Windows. Will fix sometime soon. Best, luke > > > y <- -1e3:2.2e9 ; .Internal(inspect(y)) > @0x00000000195c0178 14 REALSXP g0c0 [REF(65535)] -1000 : -2094967296 (c...

...u multiply a numeric with a "kind of logical" matrix (a pattern > one), you will expect that the > TRUE/FALSE matrix will be treated as a 1/0 matrix because it is > combined with a numeric matrix. > So we could say that in this case, the Matrix package behavior is > clearly bugous .... but still it has been the behavior for the last 10 > years or so. > > RFC 1: "Change 1": > I currently propose to change this behavior for the upcoming release > of Matrix (version 1.2-0), though I have no idea if dependent > packages would partly fail their check...

...u multiply a numeric with a "kind of logical" matrix (a pattern > one), you will expect that the > TRUE/FALSE matrix will be treated as a 1/0 matrix because it is > combined with a numeric matrix. > So we could say that in this case, the Matrix package behavior is > clearly bugous .... but still it has been the behavior for the last 10 > years or so. > > RFC 1: "Change 1": > I currently propose to change this behavior for the upcoming release > of Matrix (version 1.2-0), though I have no idea if dependent > packages would partly fail their checks...

...-1000 : 2000000000 (compact) > >> > y <- -1e3:2.1e9 ;.Internal(inspect(y)) > >> @0x0000000019925930 13 INTSXP g0c0 [REF(65535)] -1000 : 2100000000 (compact) > >> > >> and here, y is correct, just the printing from > >> .Internal(inspect(y)) is bugous (probably prints the double as an integer): > >> > >> > y <- -1e3:2.2e9 ; .Internal(inspect(y)) > >> @0x00000000195c0178 14 REALSXP g0c0 [REF(65535)] -1000 : -2094967296 (compact) > >> > length(y) > >> [1] 2200001001 > >> > t...

...platforms, all of course depending on low >>> things such as root/syadmin/... "permission" to clean up etc. >>> >>> Jeroeen mentioned the fact that tempdir()s also can disappear >>> for other reasons {his was multicore child processes >>> .. bugously(?) implemented}. >>> Further reasons may be race conditions / user code bugs / user >>> errors, etc. >>> Note that the R process which created the tempdir on startup >>> always has the permission to remove it again. But you can also >>> think a full f...

I'm having trouble grokking complex NaN's. This first set examples using complex(re=NaN,im=NaN) give what I expect > Re(complex(re=NaN, im=NaN)) [1] NaN > Im(complex(re=NaN, im=NaN)) [1] NaN > Arg(complex(re=NaN, im=NaN)) [1] NaN > Mod(complex(re=NaN, im=NaN)) [1] NaN > abs(complex(re=NaN, im=NaN)) [1] NaN and so do the following > Re(complex(re=1,

...kage:digest" %in% search() >> [1] FALSE > >> This may be intentional, but the behavior seems surprising >> and could be responsible for the behavior outlined >> earlier. > > Yes, the behavior you outlined earlier is buggy, and I also have > seen similar bugous behavior for the case of non-exported > classes. > > Part of it is historical: The S4 code was mostly written before > namespaces were introduced into R; I vaguely remember John > Chambers (the principal creator of S4) saying that he did not > intend the formal classes to be n...

...red some more comprehensive "research". > I found that we have had a long-standing inconsistency at least between the > documented and the real behavior. I am claiming that the documented > behavior is desirable and hence R's current "real" behavior is bugous, and > I am proposing to change it, in R-devel (to be 3.4.0) for now. After the "roaring unanimous" assent (one private msg encouraging me to go forward, no dissenting voice, hence an "odds ratio" of +Inf in favor ;-) I have now committed my proposal to...