similar to: --disable-long-double or --enable-long-double=no?

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