similar to: complex NA's match(), etc: not back-compatible change proposal

That, for example, complex(real=NaN) and complex(imaginary=NaN) are regarded as equal makes it possible that length(unique(as.character(x))) > length(unique(x)) (current code of function 'factor' doesn't expect it). Yes, an argument for the behavior is that NA and NaN are of one kind. On my system, using 32-bit R for Windows from binary from CRAN, the result of sapply(z, match,

On 'factor', I meant the case where 'levels' is not specified, where 'unique' is called. > factor(c(complex(real=NaN), complex(imaginary=NaN))) [1] NaN+0i <NA> Levels: NaN+0i Look at <NA> in the result above. Yes, it happens in earlier versions of R, too. On matching both NA and NaN, another consequence is that length(unique(.)) may depend on order.

This is an RFC / announcement related to the 2nd part of PR#16885 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16885 about complex NA's. The (somewhat rare) incompatibility in R's 3.3.0 match() behavior for the case of complex numbers with NA & NaN's {which has been fixed for R 3.3.0 patched in the mean time} triggered some more comprehensive "research". I

Full_Name: Tom Short Version: 2.4.0 OS: Windows XP Submission from: (NULL) (68.236.159.227) It looks like there's a bug in acosh with complex number in windows: > acosh(2) [1] 1.316958 > acosh(2+0i) [1] 0+NaNi This happens for me on Windows XP with the following versions: R version 2.2.0, 2005-10-06, i386-pc-mingw32 R version 2.4.0 (2006-10-03) i386-pc-mingw32 It works fine with

Hello I want to batch job the calculation of many GLM-models, extract some values and store them in a file. Almost everything in the script below works (read file, extract values and write them to file) except I fail in indexing the GLM with the modelstructure it should run. Running GLM's conventionally is no problem. Conventionally a GLM is calculated as:

Full_Name: Peter Fortini Version: 2.0.1 OS: Windows 2000 Submission from: (NULL) (65.246.187.164) When the imaginary part of the argument is very large, the complex tangent function returns 0+NaNi. For example, tan(1+1000i)=0+NaNi; it should be 0+1i Easy to fix in complex.c, as the original NaN came from division of sinh and cosh that had reached machine infinity. static void z_tan(Rcomplex

I am raising this again. With z <- complex(real = c(0,NaN,NaN), imaginary = c(NA,NA,0)) , results of sapply(z, match, table = z) and match(z, z) are different in R 3.4.0 alpha. I think they should be the same. I suggest changing 'cequal' in unique.c such that a complex number that has both NA and NaN matches NA and doesn't match NaN, as such complex number is printed as NA.

The following behaviour (in R 0.62.3) is disturbing: > (0+0i)^2 [1] NaN+NaNi Is it deliberate?? Laimonis Kavalieris -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To:

The following behaviour (in R 0.62.3) is disturbing: > (0+0i)^2 [1] NaN+NaNi Is it deliberate?? Laimonis Kavalieris -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To:

Hi, FWIW: /* Taken from R/src/main/unique.c */ static int requal(SEXP x, int i, SEXP y, int j) { if (i < 0 || j < 0) return 0; if (!ISNAN(REAL(x)[i]) && !ISNAN(REAL(y)[j])) return (REAL(x)[i] == REAL(y)[j]); else if (R_IsNA(REAL(x)[i]) && R_IsNA(REAL(y)[j])) return 1; else if (R_IsNaN(REAL(x)[i]) && R_IsNaN(REAL(y)[j])) return 1;

Hi , we use a barix <http://www.barix.com/products/instreamer-family/barix/Product/show/instreamer-100/?tx_wvbrxproducts_barixproductslist%5Bbutton%5D=&cHash=e3487444dea24a6b24aa0701dc1fa924>as our icecast client right now ( >400$ ) and I though I would try to replace it with a Raspberri Pi. Did anyone found a cheap and supported usb audio card that would have basic good input (

I get an error when running "make check" after building R-devel r70629 on Ubuntu 14.04. Here are the relevant lines in the file "reg-tests-1c.Rout.fail": > ## m1z uses match(x, *) with length(x) == 1 and failed in R 3.3.0 > ## PR#16909 - a consequence of the match() bug; check here too: > dv <- data.frame(var?1 = 1:3, var?2 = 3); dv[,"var?2"]

On 18/05/16 13:50, Martin Maechler wrote: >>>>>> Mikko Korpela <mikko.korpela at helsinki.fi> >>>>>> on Wed, 18 May 2016 13:05:24 +0300 writes: > > > I get an error when running "make check" after building > > R-devel r70629 on Ubuntu 14.04. > > Here are the relevant > > lines in the file

>>>>> Mikko Korpela <mikko.korpela at helsinki.fi> >>>>> on Wed, 18 May 2016 13:05:24 +0300 writes: > I get an error when running "make check" after building > R-devel r70629 on Ubuntu 14.04. > Here are the relevant > lines in the file "reg-tests-1c.Rout.fail": > > ## m1z uses match(x, *) with

>>>>> Mikko Korpela <mikko.korpela at helsinki.fi> >>>>> on Wed, 18 May 2016 14:18:20 +0300 writes: > On 18/05/16 13:50, Martin Maechler wrote: >>>>>>> Mikko Korpela <mikko.korpela at helsinki.fi> on Wed, 18 >>>>>>> May 2016 13:05:24 +0300 writes: >> >> > I get an error

On 27/02/13 12:06, michel memeteau wrote: > > we use a barix > <http://www.barix.com/products/instreamer-family/barix/Product/show/instreamer-100/?tx_wvbrxproducts_barixproductslist%5Bbutton%5D=&cHash=e3487444dea24a6b24aa0701dc1fa924>as > our icecast client right now ( >400$ ) and I though I would try to > replace it with a Raspberri Pi. > > Did anyone found a

The option is just used to select HMM mirror support and has a very confusing help text. Just pull in the HMM mirror code by default instead. Signed-off-by: Christoph Hellwig <hch at lst.de> --- drivers/gpu/drm/Kconfig | 2 ++ drivers/gpu/drm/amd/amdgpu/Kconfig | 10 ---------- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 ------

Currently, the Kbuild core manipulates header search paths in a crazy way [1]. To fix this mess, I want all Makefiles to add explicit $(srctree)/ to the search paths in the srctree. Some Makefiles are already written in that way, but not all. The goal of this work is to make the notation consistent, and finally get rid of the gross hacks. Having whitespaces after -I does not matter since commit

On Fri, Mar 29, 2019 at 08:32:41PM +0900, Masahiro Yamada wrote: > Currently, the Kbuild core manipulates header search paths in a crazy > way [1]. > > To fix this mess, I want all Makefiles to add explicit $(srctree)/ to > the search paths in the srctree. Some Makefiles are already written in > that way, but not all. The goal of this work is to make the notation >

Currently, the Kbuild core manipulates header search paths in a crazy way [1]. To fix this mess, I want all Makefiles to add explicit $(srctree)/ to the search paths in the srctree. Some Makefiles are already written in that way, but not all. The goal of this work is to make the notation consistent, and finally get rid of the gross hacks. Having whitespaces after -I does not matter since commit