Displaying 20 results from an estimated 6000 matches similar to: "--disable-long-double or --enable-long-double=no?"
2024 Feb 06
2
Advice debugging M1Mac check errors
On 04/02/2024 19:41, Holger Hoefling wrote:
> Hi,
>
> I wanted to ask if people have good advice on how to debug M1Mac package
> check errors when you don?t have a Mac? Is a cloud machine the best option
> or is there something else?
I presumed this was about a CRAN package, possibly hdf5r which has a
R-devel-only warning from the Apple clang compiler. And that is not a
2017 May 23
2
Inconsistency in handling of numeric input with %d by sprintf
https://github.com/Rdatatable/data.table/issues/2171
The fix was easy, it's just surprising to see the behavior change almost on
a whim. Just wanted to point it out in case this is unknown behavior, but
Evan seems to have found this as well.
On Tue, May 23, 2017 at 12:00 PM, Michael Chirico <michaelchirico4 at gmail.com
> wrote:
> Astute observation. And of course we should be
2017 May 23
2
Inconsistency in handling of numeric input with %d by sprintf
I initially thought this is "documented behaviour". ?sprintf says:
Numeric variables with __exactly integer__ values will be coerced to
integer. (emphasis mine).
Turns out this only works when the first value is numeric and not NA, as
shown by the following example:
> sprintf("%d", as.numeric(c(NA,1)))
Error in sprintf("%d", as.numeric(c(NA, 1))) :
invalid
2017 May 19
2
Inconsistency in handling of numeric input with %d by sprintf
Consider
#as.numeric for emphasis
sprintf('%d', as.numeric(1))
# [1] "1"
vs.
sprintf('%d', NA_real_)
> Error in sprintf("%d", NA_real_) :
invalid format '%d'; use format %f, %e, %g or %a for numeric object
>
I understand the error is correct, but if it works for other numeric input,
why doesn't R just coerce NA_real_ to NA_integer_?
2020 Apr 30
1
Translations and snprintf on Windows
[a bit unsure on if this is maybe better for r-package-devel]
We recently added translations to messages at the R and C level to
data.table.
At the C level, we did _() wrapping for char arrays supplied to the
following functions: error, warning, Rprintf, Error, and snprintf.
This seemed OK but the use of snprintf specifically appears to have caused
a crash on Windows:
2019 Jan 11
2
strtoi output of empty string inconsistent across platforms
Identified as root cause of a bug in data.table:
https://github.com/Rdatatable/data.table/issues/3267
On my machine, strtoi("", base = 2L) produces NA_integer_ (which seems
consistent with ?strtoi: "Values which cannot be interpreted as integers or
would overflow are returned as NA_integer_").
But on all the other machines I've seen, 0L is returned. This seems to be
2019 Jun 02
1
rbind has confusing result for custom sub-class (possible bug?)
I thought it would be good to summarize my thoughts, since I made a
few hypotheses that turned out to be false.
This isn't a bug in base R, in either rbind() or `[<-.Date`.
To summarize the root cause:
base::rbind.data.frame() calls `[<-` for each column of the
data.frame, and there is no `[<-.IDate` method to ensure the
replacement value is converted to integer. And, in fact,
2018 Feb 27
2
scale.default gives an incorrect error message when is.numeric() fails on a sparse row matrix (dgeMatrix)
I am attempting to use the lars package with a sparse input feature matrix,
but the following fails:
library(Matrix)
library(lars)
data(diabetes)
attach(diabetes)
x = as(as.matrix(as.data.frame(x)), 'dgCMatrix')
lars(x, y, intercept = FALSE)
Error in scale.default(x, FALSE, normx) :
>
> length of 'scale' must equal the number of columns of 'x'
>
>
More
2019 May 27
2
rbind has confusing result for custom sub-class (possible bug?)
Yes, thanks for following up on thread here. And thanks again for clearing
things up, your email was a finger snap of clarity on the whole issue.
I'll add that actually it was data.table's code at fault on the storage
conversion -- note that if you use an arbitrary sub-class 'foo' with no
methods defined, it'll stay integer.
That's because [<- calls as.Date and then
2019 Jan 11
2
strtoi output of empty string inconsistent across platforms
>>>>> Martin Maechler
>>>>> on Fri, 11 Jan 2019 09:44:14 +0100 writes:
>>>>> Michael Chirico
>>>>> on Fri, 11 Jan 2019 14:36:17 +0800 writes:
>> Identified as root cause of a bug in data.table:
>> https://github.com/Rdatatable/data.table/issues/3267
>> On my machine, strtoi("", base =
2019 May 26
2
rbind has confusing result for custom sub-class (possible bug?)
On Sun, May 26, 2019 at 4:06 AM Michael Chirico
<michaelchirico4 at gmail.com> wrote:
>
> Have finally managed to come up with a fix after checking out sys.calls()
> from within the as.Date.IDate debugger, which shows something like:
>
> [[1]] rbind(DF, DF)
> [[2]] rbind(deparse.level, ...)
> [[3]] `[<-`(`*tmp*`, ri, value = 18042L)
> [[4]] `[<-.Date`(`*tmp*`,
2018 Mar 05
1
model.frame strips class as promised, but fails to strip OBJECT in C
Full thread here:
https://github.com/tidyverse/broom/issues/287
Reproducible example:
is.object(freeny$y)
# [1] TRUE
attr(freeny$y, 'class')
# [1] "ts"
class(freeny$y)
# [1] "ts"
# ts attribute wiped by model.frame
class(model.frame(y ~ ., data = freeny)$y)
# [1] "numeric"
attr(model.frame(y ~ ., data = freeny)$y, 'class')
# NULL
# but still:
2023 Nov 08
1
c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
So, to summarize, the open questions are:
(1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0)
instead of NA_complex_?
(2) Should the first argument in c(NA, x) and c(NA_integer_, x),
where typeof(x) == "complex", be promoted to complex(r=NA_real_, i=0)
instead of NA_complex_?
My opinions:
(1) No. The imaginary part of the
2023 Nov 09
1
c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
>>>>> Mikael Jagan
>>>>> on Wed, 8 Nov 2023 11:13:18 -0500 writes:
> So, to summarize, the open questions are:
> (1) Should as.complex(NA_character_) give complex(r=NA_real_, i=0)
> instead of NA_complex_?
> (2) Should the first argument in c(NA, x) and c(NA_integer_, x),
> where typeof(x) == "complex", be promoted
2020 Oct 19
1
usage of #import in grDevices/src/qdCocoa.h
I happened to notice that this header file uses
#import <Cocoa/Cocoa.h>
This is the first time I came across the preprocessor directive #import;
the first thing I found about it is this Q&A suggesting it's not portable
nor standard C:
https://stackoverflow.com/q/39280248/3576984
On the other hand, this exact invocation seems pretty common on GitHub
2024 Apr 15
1
[External] Re: Repeated library() of one package with different include.only= entries
I think we should try to advance and hopefully finalize this
thread before we forget about it ..
>>>>> Michael Chirico n Thu, 11 Apr 2024 09:10:11 -0700 writes:
>> I would assume that
>> library(Matrix, include.only="isDiagonal")
>> implies that only `isDiagonal` ends up on the search path
> This could also be a reasonable
2023 Nov 07
1
c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
Thanks Martin. My hang-up was not on what the outcome of as.complex(NA)
should be, but rather, how I should read code like c(x, y) generally. Till
now, I have thought of it like 'c(x, y)' is c(as(x, typeof(y)), y)` when
"type(y) > type(x)". Basically in my mind, "coercion" in R <->
as.<newtype>(.) (or coerceVector() in C).
So I tracked down the source
2024 Feb 04
3
Advice debugging M1Mac check errors
Hi,
I wanted to ask if people have good advice on how to debug M1Mac package
check errors when you don?t have a Mac? Is a cloud machine the best option
or is there something else?
Thanks
Holger
[[alternative HTML version deleted]]
2023 Jan 10
1
Shouldn't "Loading" be "Attaching" when referring to library() calls?
>>>>> Michael Chirico via R-devel
>>>>> on Mon, 9 Jan 2023 12:25:46 -0800 writes:
> require() and library() both emit this message immediately before
> running library():
> "Loading required package: %s"
> https://github.com/r-devel/r-svn/blob/4198a2941b702d965bb2374c2b908f48c369f40a/src/library/base/R/library.R#L967-L968
2023 Nov 06
1
c(NA, 0+1i) not the same as c(as.complex(NA), 0+1i)?
>>>>> Michael Chirico
>>>>> on Sun, 5 Nov 2023 09:41:42 -0800 writes:
> This is another follow-up to the thread from September
> "Recent changes to as.complex(NA_real_)".
> A test in data.table was broken by the changes for NA
> coercion to complex; the breakage essentially comes from
> c(NA, 0+1i)
> # vs