Displaying 20 results from an estimated 3000 matches similar to: "complex NA's match(), etc: not back-compatible change proposal"
2016 May 13
1
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,
2016 May 28
1
complex NA's match(), etc: not back-compatible change proposal
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.
2016 May 10
1
complex NA's match(), etc: not back-compatible change proposal
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
2006 Nov 30
1
bug in acosh (win32) (PR#9403)
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
2007 Jan 11
3
batch job GLM calculations
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:
2005 Apr 07
1
complex tangent (PR#7781)
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
2017 Apr 01
1
complex NA's match(), etc: not back-compatible change proposal
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.
1998 Sep 16
2
R-beta: (0+0i)^2
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:
1998 Sep 16
2
R-beta: (0+0i)^2
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:
2011 Dec 02
1
1.6x speedup for requal() function (in R/src/main/unique.c)
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;
2013 Feb 27
2
using a Rpi as an icecast source
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 (
2016 May 18
3
[patch] Error in reg-tests-1c.R (R-devel)
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"]
2016 May 18
2
[patch] Error in reg-tests-1c.R (R-devel)
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
2016 May 18
0
[patch] Error in reg-tests-1c.R (R-devel)
>>>>> 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
2016 May 19
0
[patch] Error in reg-tests-1c.R (R-devel)
>>>>> 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
2013 Feb 27
0
using a Rpi as an icecast source
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
2019 Aug 06
0
[PATCH 15/15] amdgpu: remove CONFIG_DRM_AMDGPU_USERPTR
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 ------
2019 Jan 31
2
[PATCH] drm: prefix header search paths with $(srctree)/
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
2019 Mar 29
0
[PATCH v2] drm: prefix header search paths with $(srctree)/
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
>
2019 Mar 29
4
[PATCH v2] drm: prefix header search paths with $(srctree)/
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