Re: [Rd] truncated warning messages
On Fri, Apr 17, 2015 at 6:05 PM, Hervé Pagès wrote:
> As you can see the warning message is truncated so I can't see what
> happened to these packages.
In this case you could also increase options("warning.length")
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] truncated warning messages
Hi, I was installing hundreds of packages on a machine with a single call to install.packages() and after a long time the call to install.packages() finally returned with the following warnings and errors: Warning messages: 1: packages ‘hgu133aprobe’, ‘hgu95av2.db’, ‘BSgenome.Celegans.UCSC.ce2’, ‘BSgenome.Mmusculus.UCSC.mm10’, ‘BSgenome.Dmelanogaster.UCSC.dm3.masked’, ‘BSgenome.Hsapiens.UCSC.hg18.masked’, ‘BSgenome.Hsapiens.UCSC.hg19.masked’, ‘BSgenome.Mmusculus.UCSC.mm9.masked’, ‘BSgenome.Scerevisiae.UCSC.sacCer2’, ‘BSgenome.Hsapiens.NCBI.GRCh38’, ‘BSgenome.Rnorvegicus.UCSC.rn5’, ‘drosophila2probe’, ‘hgu95av2probe’, ‘hgu95av2cdf’, ‘SNPlocs.Hsapiens.dbSNP.20100427’, ‘SNPlocs.Hsapiens.dbSNP.20101109’, ‘SNPlocs.Hsapiens.dbSNP.20110815’, ‘SNPlocs.Hsapiens.dbSNP141.GRCh38’, ‘XtraSNPlocs.Hsapiens.dbSNP141.GRCh38’, ‘org.Sc.sgd.db’, ‘org.Mm.eg.db’, ‘org.At.tair.db’, ‘hom.Hs.inp.db’, ‘GO.db’, ‘TxDb.Hsapiens.UCSC.hg18.knownGene’, ‘TxDb.Hsapiens.UCSC.hg19.knownGene’, ‘TxDb.Hsapiens.UCSC.hg38.knownGene’, ‘TxDb.Mmusculus.UCSC.mm9.knownGene’, ‘TxDb.Mmusculus.UCSC.mm10.knownGene’, ‘TxDb.Dmelanogaster.UCSC. [... truncated] 2: In install.packages(pkgs = doing, lib = lib, ...) : installation of package ‘humanStemCell’ had non-zero exit status 3: In install.packages(pkgs = doing, lib = lib, ...) : installation of package ‘AnnotationForge’ had non-zero exit status As you can see the warning message is truncated so I can't see what happened to these packages. What about having a message like package(s) not available: pkg1, pkg2, pkg3, etc... so when it's truncated we don't loose the important part of the story? I guess the same kind of change could be made to the other warning messages, and, more generally, to any warning/error message obtained by injecting an arbitrary (and potentially long) list of strings. Thanks, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fredhutch.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-3.2.0 Fedora 21 heads up
> On 17 Apr 2015, at 21:09 , Dominick Samperi wrote: > > FYI, with R-3.2.0 the configure options --with-system-zib=yes > --with-system-bzlib=yes --with-system-pcre=yes become the default > (according to Peter Dalgaard), so the devel versions of these > libraries must be installed under Fedora to prevent unresolved > references. > Also according to the NEWS file, one may add... -- 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
[Rd] R-3.2.0 Fedora 21 heads up
FYI, with R-3.2.0 the configure options --with-system-zib=yes --with-system-bzlib=yes --with-system-pcre=yes become the default (according to Peter Dalgaard), so the devel versions of these libraries must be installed under Fedora to prevent unresolved references. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] behavior of as.integer("5000000000")
On 04/17/2015 08:24 AM, Martin Maechler wrote:
Martin Maechler
on Fri, 17 Apr 2015 15:49:35 +0200 writes:
Hervé Pagès
on Mon, 13 Apr 2015 23:36:14 -0700 writes:
>> On 04/13/2015 11:32 PM, Martin Maechler wrote:
>>>
Hi,
> as.integer("50")
[1] 2147483647
Warning message:
inaccurate integer conversion in coercion
>>>
> as.integer("-50")
[1] NA
Warning message:
inaccurate integer conversion in coercion
>>>
Is this a bug or a feature? The man page suggests it's the
latter:
>>>
>>> I think you mean the "former", a bug.
>>>
>>> and I agree entirely, see the following " 2 x 2 " comparison :
>>>
>>> > N <- 5 * 8^-(0:7)
>>> > as.integer(N)
>>> [1] NA NA NA NA 1220703125 152587890
190734862384185
>>> Warning message:
>>> NAs introduced by coercion
>>> > as.integer(-N)
>>> [1] NA NA NA NA -1220703125
-152587890 -19073486
>>> [8]-2384185
>>> Warning message:
>>> NAs introduced by coercion
>>> > as.integer(as.character(N))
>>> [1] 2147483647 2147483647 2147483647 2147483647 1220703125 152587890
190734862384185
>>> Warning message:
>>> inaccurate integer conversion in coercion
>>> > as.integer(as.character(-N))
>>> [1] NA NA NA NA -1220703125
-152587890 -19073486
>>> [8]-2384185
>>> Warning message:
>>> inaccurate integer conversion in coercion
>>>
>>>
>>>
‘as.integer’ attempts to coerce its argument to be of integer
type. The answer will be ‘NA’ unless the coercion succeeds.
>>>
even though someone could always argue that coercion of "50"
succeeded (for some definition of "succeed").
>>>
Also is there any reason why the warning message is different than
with:
>>>
> as.integer(-50)
[1] NA
Warning message:
NAs introduced by coercion
>>>
In the case of as.integer("-50"), it's not really that the
conversion was "inaccurate", it's a little bit worse than that. And
knowing that NAs where introduced by coercion is important.
>>>
>>> Yes.
>>> The message is less a problem than the bug, but I agree we
>>> should try to improve it.
>> Sounds good. Thanks Martin,
> I've committed a change to R-devel now, such that also this case
> returns NA with a warning, actually for the moment with both the
> old warning and the 'NAs introduced by coercion' warning.
> The "nice thing" about the old warning is that it explicitly
> mentions integer coercion.
> I currently think we should keep that property, and I'd propose
> to completely drop the
> "inaccurate integer conversion in coercion"
> warning (it is not used anywhere else currently) and replace it
> in this and other as.integer(.) cases with
> 'NAs introduced by integer coercion'
> (or something similar. ... improvements / proposals are welcome).
Replying to myself:
I've found
'NAs introduced by coercion to integer range'
I like that we see "coercion *to* integer" instead of just
"integer coercion" because the former indicates the direction
of the coercion. I'm not that convinced with the "range" thing
though. I think
as.integer(c("78", "a34", "-50"))
should emit only one warning and not try to categorize the
reasons for getting an NA.
Thanks,
H.
to be even more "on spot", and so will commit it for today.
Of course, amendment proposals are still welcome.
Martin
> BTW, the fact that as.integer("-50") did produce an NA
> instead of -2147483647 so it would have been compatible with
as.integer("50")
> was just another coincidence, namely that we "currently" code NA_integer_
> by INT_MIN (for 32 bit integers, INT_MIN = 2147483648 = 2^31)
> [[but your C code must not rely on that, it is an implementation
detail!]]
> Martin
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] behavior of as.integer("5000000000")
Hi Martin,
On 04/17/2015 06:49 AM, Martin Maechler wrote:
Hervé Pagès
on Mon, 13 Apr 2015 23:36:14 -0700 writes:
> On 04/13/2015 11:32 PM, Martin Maechler wrote:
>>
>>> Hi,
>>> > as.integer("50")
>>> [1] 2147483647
>>> Warning message:
>>> inaccurate integer conversion in coercion
>>
>>> > as.integer("-50")
>>> [1] NA
>>> Warning message:
>>> inaccurate integer conversion in coercion
>>
>>> Is this a bug or a feature? The man page suggests it's the
>>> latter:
>>
>> I think you mean the "former", a bug.
>>
>> and I agree entirely, see the following " 2 x 2 " comparison :
>>
>> > N <- 5 * 8^-(0:7)
>> > as.integer(N)
>> [1] NA NA NA NA 1220703125 152587890
190734862384185
>> Warning message:
>> NAs introduced by coercion
>> > as.integer(-N)
>> [1] NA NA NA NA -1220703125
-152587890 -19073486
>> [8]-2384185
>> Warning message:
>> NAs introduced by coercion
>> > as.integer(as.character(N))
>> [1] 2147483647 2147483647 2147483647 2147483647 1220703125 152587890
190734862384185
>> Warning message:
>> inaccurate integer conversion in coercion
>> > as.integer(as.character(-N))
>> [1] NA NA NA NA -1220703125
-152587890 -19073486
>> [8]-2384185
>> Warning message:
>> inaccurate integer conversion in coercion
>>
>>
>>
>>> ‘as.integer’ attempts to coerce its argument to be of integer
>>> type. The answer will be ‘NA’ unless the coercion succeeds.
>>
>>> even though someone could always argue that coercion of "50"
>>> succeeded (for some definition of "succeed").
>>
>>> Also is there any reason why the warning message is different than
>>> with:
>>
>>> > as.integer(-50)
>>> [1] NA
>>> Warning message:
>>> NAs introduced by coercion
>>
>>> In the case of as.integer("-50"), it's not really that the
>>> conversion was "inaccurate", it's a little bit worse than that. And
>>> knowing that NAs where introduced by coercion is important.
>>
>> Yes.
>> The message is less a problem than the bug, but I agree we
>> should try to improve it.
> Sounds good. Thanks Martin,
I've committed a change to R-devel now, such that also this case
returns NA with a warning, actually for the moment with both the
old warning and the 'NAs introduced by coercion' warning.
The "nice thing" about the old warning is that it explicitly
mentions integer coercion.
I currently think we should keep that property, and I'd propose
to completely drop the
"inaccurate integer conversion in coercion"
warning (it is not used anywhere else currently) and replace it
in this and other as.integer(.) cases with
'NAs introduced by integer coercion'
(or something similar. ... improvements / proposals are welcome).
Thanks. That's a much better warning message.
BTW, the fact that as.integer("-50") did produce an NA
instead of -2147483647 so it would have been compatible with
as.integer("50")
was just another coincidence, namely that we "currently" code NA_integer_
by INT_MIN (for 32 bit integers, INT_MIN = 2147483648 = 2^31)
[[but your C code must not rely on that, it is an implementation detail!]]
Yeah, I suspected that.
Thanks for the fix.
H.
Martin
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] behavior of as.integer("5000000000")
> Martin Maechler
> on Fri, 17 Apr 2015 15:49:35 +0200 writes:
> Hervé Pagès
> on Mon, 13 Apr 2015 23:36:14 -0700 writes:
>> On 04/13/2015 11:32 PM, Martin Maechler wrote:
>>>
Hi,
> as.integer("50")
[1] 2147483647
Warning message:
inaccurate integer conversion in coercion
>>>
> as.integer("-50")
[1] NA
Warning message:
inaccurate integer conversion in coercion
>>>
Is this a bug or a feature? The man page suggests it's the
latter:
>>>
>>> I think you mean the "former", a bug.
>>>
>>> and I agree entirely, see the following " 2 x 2 " comparison :
>>>
>>> > N <- 5 * 8^-(0:7)
>>> > as.integer(N)
>>> [1] NA NA NA NA 1220703125 152587890
190734862384185
>>> Warning message:
>>> NAs introduced by coercion
>>> > as.integer(-N)
>>> [1] NA NA NA NA -1220703125
-152587890 -19073486
>>> [8]-2384185
>>> Warning message:
>>> NAs introduced by coercion
>>> > as.integer(as.character(N))
>>> [1] 2147483647 2147483647 2147483647 2147483647 1220703125 152587890
190734862384185
>>> Warning message:
>>> inaccurate integer conversion in coercion
>>> > as.integer(as.character(-N))
>>> [1] NA NA NA NA -1220703125
-152587890 -19073486
>>> [8]-2384185
>>> Warning message:
>>> inaccurate integer conversion in coercion
>>>
>>>
>>>
‘as.integer’ attempts to coerce its argument to be of integer
type. The answer will be ‘NA’ unless the coercion succeeds.
>>>
even though someone could always argue that coercion of "50"
succeeded (for some definition of "succeed").
>>>
Also is there any reason why the warning message is different than
with:
>>>
> as.integer(-50)
[1] NA
Warning message:
NAs introduced by coercion
>>>
In the case of as.integer("-50"), it's not really that the
conversion was "inaccurate", it's a little bit worse than that. And
knowing that NAs where introduced by coercion is important.
>>>
>>> Yes.
>>> The message is less a problem than the bug, but I agree we
>>> should try to improve it.
>> Sounds good. Thanks Martin,
> I've committed a change to R-devel now, such that also this case
> returns NA with a warning, actually for the moment with both the
> old warning and the 'NAs introduced by coercion' warning.
> The "nice thing" about the old warning is that it explicitly
> mentions integer coercion.
> I currently think we should keep that property, and I'd propose
> to completely drop the
> "inaccurate integer conversion in coercion"
> warning (it is not used anywhere else currently) and replace it
> in this and other as.integer(.) cases with
> 'NAs introduced by integer coercion'
> (or something similar. ... improvements / proposals are welcome).
Replying to myself:
I've found
'NAs introduced by coercion to integer range'
to be even more "on spot", and so will commit it for today.
Of course, amendment proposals are still welcome.
Martin
> BTW, the fact that as.integer("-50") did produce an NA
> instead of -2147483647 so it would have been compatible with
as.integer("50")
> was just another coincidence, namely that we "currently" code NA_integer_
> by INT_MIN (for 32 bit integers, INT_MIN = 2147483648 = 2^31)
> [[but your C code must not rely on that, it is an implementation detail!]]
> Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Redefining {
Redefining operators can be useful in translating R syntax
to some other language. E.g., dplyr does that sort of thing
to translate to sql. It puts the altered definition into an environment
that is used only for such translation so it doesn't mess up
other functions.
> dplyr::base_scalar$`{`
function (x)
{
build_sql("(", x, ")")
}
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Fri, Apr 17, 2015 at 7:49 AM, William Dunlap wrote:
> One could redefine the "{" function with something like
> `{` <- function(...) simplify2array(list(...))
> but then you would have to live with the syntax it requires
> (semicolons for separators instead of commas)
>> {1; 2; 3}
>[1] 1 2 3
>> {{11;12;13}; {21;22;23}; {31;32;33}}
> [,1] [,2] [,3]
>[1,] 11 21 31
>[2,] 12 22 32
>[3,] 13 23 33
>
> I have not seen this in any "real" code.
>
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> On Thu, Apr 16, 2015 at 9:19 PM, Mick Jordan
> wrote:
>
>> I am curious if anyone knows of R code where the "{" function is
>> redefined in a useful way. Or "(" for that matter.
>>
>> Thanks
>> Mick
>>
>> __
>> 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
Re: [Rd] Redefining {
One could redefine the "{" function with something like
`{` <- function(...) simplify2array(list(...))
but then you would have to live with the syntax it requires
(semicolons for separators instead of commas)
> {1; 2; 3}
[1] 1 2 3
> {{11;12;13}; {21;22;23}; {31;32;33}}
[,1] [,2] [,3]
[1,] 11 21 31
[2,] 12 22 32
[3,] 13 23 33
I have not seen this in any "real" code.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Thu, Apr 16, 2015 at 9:19 PM, Mick Jordan wrote:
> I am curious if anyone knows of R code where the "{" function is redefined
> in a useful way. Or "(" for that matter.
>
> Thanks
> Mick
>
> __
> 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
Re: [Rd] Redefining {
On 17 Apr 2015, at 06:19 , Mick Jordan wrote:
> I am curious if anyone knows of R code where the "{" function is redefined in
> a useful way. Or "(" for that matter.
I sincerely would hope not
Incidentally, I seem to recall that during the design of (new?) S, it was at
some point the intention to specify vectors as (7, 9, 13) or [7, 9, 13] but the
resulting semantic issues led the developers to choose the pure functional form
c(7, 9, 13).
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
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] behavior of as.integer("5000000000")
> Hervé Pagès
> on Mon, 13 Apr 2015 23:36:14 -0700 writes:
> On 04/13/2015 11:32 PM, Martin Maechler wrote:
>>
>>> Hi,
>>> > as.integer("50")
>>> [1] 2147483647
>>> Warning message:
>>> inaccurate integer conversion in coercion
>>
>>> > as.integer("-50")
>>> [1] NA
>>> Warning message:
>>> inaccurate integer conversion in coercion
>>
>>> Is this a bug or a feature? The man page suggests it's the
>>> latter:
>>
>> I think you mean the "former", a bug.
>>
>> and I agree entirely, see the following " 2 x 2 " comparison :
>>
>> > N <- 5 * 8^-(0:7)
>> > as.integer(N)
>> [1] NA NA NA NA 1220703125 152587890
190734862384185
>> Warning message:
>> NAs introduced by coercion
>> > as.integer(-N)
>> [1] NA NA NA NA -1220703125
-152587890 -19073486
>> [8]-2384185
>> Warning message:
>> NAs introduced by coercion
>> > as.integer(as.character(N))
>> [1] 2147483647 2147483647 2147483647 2147483647 1220703125 152587890
190734862384185
>> Warning message:
>> inaccurate integer conversion in coercion
>> > as.integer(as.character(-N))
>> [1] NA NA NA NA -1220703125
-152587890 -19073486
>> [8]-2384185
>> Warning message:
>> inaccurate integer conversion in coercion
>>
>>
>>
>>> ‘as.integer’ attempts to coerce its argument to be of integer
>>> type. The answer will be ‘NA’ unless the coercion succeeds.
>>
>>> even though someone could always argue that coercion of "50"
>>> succeeded (for some definition of "succeed").
>>
>>> Also is there any reason why the warning message is different than
>>> with:
>>
>>> > as.integer(-50)
>>> [1] NA
>>> Warning message:
>>> NAs introduced by coercion
>>
>>> In the case of as.integer("-50"), it's not really that the
>>> conversion was "inaccurate", it's a little bit worse than that. And
>>> knowing that NAs where introduced by coercion is important.
>>
>> Yes.
>> The message is less a problem than the bug, but I agree we
>> should try to improve it.
> Sounds good. Thanks Martin,
I've committed a change to R-devel now, such that also this case
returns NA with a warning, actually for the moment with both the
old warning and the 'NAs introduced by coercion' warning.
The "nice thing" about the old warning is that it explicitly
mentions integer coercion.
I currently think we should keep that property, and I'd propose
to completely drop the
"inaccurate integer conversion in coercion"
warning (it is not used anywhere else currently) and replace it
in this and other as.integer(.) cases with
'NAs introduced by integer coercion'
(or something similar. ... improvements / proposals are welcome).
BTW, the fact that as.integer("-50") did produce an NA
instead of -2147483647 so it would have been compatible with
as.integer("50")
was just another coincidence, namely that we "currently" code NA_integer_
by INT_MIN (for 32 bit integers, INT_MIN = 2147483648 = 2^31)
[[but your C code must not rely on that, it is an implementation detail!]]
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
