similar to: compairing doubles

Displaying 20 results from an estimated 5000 matches similar to: "compairing doubles"

2018 Aug 31
3
compairing doubles
Agreed that's it's rounding error, and all.equal would be the way to go. I wouldn't call it a bug, it's simply part of working with floating point numbers, any language has the same issue. And while we're at it, I think the function can be a lot shorter: .is_continous_evenly_spaced <- function(n){ length(n)>1 && isTRUE(all.equal(n[order(n)], seq(from=min(n),
2018 Aug 31
2
compairing doubles
El vie., 31 ago. 2018 a las 16:00, Mark van der Loo (<mark.vanderloo at gmail.com>) escribi?: > > how about > > is_evenly_spaced <- function(x,...) all.equal(diff(sort(x)),...) This doesn't work, because 1. all.equal does *not* return FALSE. Use of isTRUE or identical(., TRUE) is required if you want a boolean. 2. all.equal compares two objects, not elements in a vector.
2018 Aug 31
0
compairing doubles
how about is_evenly_spaced <- function(x,...) all.equal(diff(sort(x)),...) (use ellipsis to set tolerance if necessary) Op vr 31 aug. 2018 om 15:46 schreef Emil Bode <emil.bode at dans.knaw.nl>: > Agreed that's it's rounding error, and all.equal would be the way to go. > I wouldn't call it a bug, it's simply part of working with floating point > numbers, any
2018 Aug 31
0
compairing doubles
Ah, my bad, you're right of course. sum(abs(diff(diff( sort(x))))) < eps for some reasonable eps then, would do as a oneliner, or all(abs(diff(diff(sort(x)))) < eps) or max(abs(diff(diff(sort(x))))) < eps -Mark Op vr 31 aug. 2018 om 16:14 schreef I?aki Ucar <iucar at fedoraproject.org>: > El vie., 31 ago. 2018 a las 16:00, Mark van der Loo > (<mark.vanderloo at
2018 Aug 31
0
compairing doubles
El vie., 31 ago. 2018 a las 15:10, Felix Ernst (<felix.gm.ernst at outlook.com>) escribi?: > > Dear all, > > I a bit unsure, whether this qualifies as a bug, but it is definitly a strange behaviour. That why I wanted to discuss it. > > With the following function, I want to test for evenly space numbers, starting from anywhere. > > .is_continous_evenly_spaced <-
2018 Aug 31
2
compairing doubles
Le 31/08/2018 ? 16:25, Mark van der Loo a ?crit?: > Ah, my bad, you're right of course. > > sum(abs(diff(diff( sort(x))))) < eps > > for some reasonable eps then, would do as a oneliner, or > > all(abs(diff(diff(sort(x)))) < eps) > > or > > max(abs(diff(diff(sort(x))))) < eps Or with only four function calls: diff(range(diff(sort(x)))) < eps
2018 Sep 03
2
compairing doubles
Maybe a new Operator could be defined for a fast and easy double Comparison: `~~` `~~` <- function (e1, e2) all.equal(e1, e2) And document it properly.
2006 Feb 08
1
corruption of data with serialize(ascii=TRUE)
I noticed the following peculiarity with `serialize()' when `ascii = TRUE' is used. In today's (svn r37299) R-devel, I get > set.seed(10) > x <- rnorm(10) > > a <- serialize(x, con = NULL, ascii = TRUE) > b <- unserialize(a) > > identical(x, b) ## FALSE [1] FALSE > x - b [1] -3.469447e-18 2.775558e-17 -4.440892e-16 0.000000e+00
2005 Oct 21
1
The behavior of match function
> x<-1:10 > y<-x+1e-20 > x [1] 1 2 3 4 5 6 7 8 9 10 > y [1] 1 2 3 4 5 6 7 8 9 10 > identical(x,y) [1] FALSE > match(x,y) [1] 1 2 3 4 5 6 7 8 9 10 What's the principle the function use to determine if x match y? Thank you! 2005-10-21 ------ Deparment of Sociology Fudan University My new mail addres is ronggui.huang at gmail.com
2020 Jan 10
2
SUGGESTION: Settings to disable forked processing in R, e.g. parallel::mclapply()
I'd like to pick up this thread started on 2019-04-11 (https://hypatia.math.ethz.ch/pipermail/r-devel/2019-April/077632.html). Modulo all the other suggestions in this thread, would my proposal of being able to disable forked processing via an option or an environment variable make sense? I've prototyped a working patch that works like: > options(fork.allowed = FALSE) >
2019 Apr 15
2
SUGGESTION: Settings to disable forked processing in R, e.g. parallel::mclapply()
On Mon, 15 Apr 2019 at 08:44, Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > On 4/13/19 12:05 PM, I?aki Ucar wrote: > > On Sat, 13 Apr 2019 at 03:51, Kevin Ushey <kevinushey at gmail.com> wrote: > >> I think it's worth saying that mclapply() works as documented > > Mostly, yes. But it says nothing about fork's copy-on-write and memory >
2020 Jan 10
2
SUGGESTION: Settings to disable forked processing in R, e.g. parallel::mclapply()
If I understand the thread correctly this is an RStudio issue and I would suggest that the developers consider using pthread_atfork() so RStudio can handle forking as they deem fit (bail out with an error or make RStudio work). Note that in principle the functionality requested here can be easily implemented in a package so R doesn?t need to be modified. Cheers, Simon Sent from my iPhone
2020 Jan 10
6
SUGGESTION: Settings to disable forked processing in R, e.g. parallel::mclapply()
Henrik, the example from the post works just fine in CRAN R for me - the post was about homebrew build so it's conceivably a bug in their libraries. That's exactly why I was proposing a more general solution where you can simply define a function in user-space that will issue a warning or stop on fork, it doesn't have to be part of core R, there are other packages that use fork() as
2009 Oct 07
1
Buglet in qbeta?
Hi, I sometimes play around with extreme parameters for distributions and found that qbeta is not always monotone as the following example shows. I don't know whether this is serious enough to submit a bug report (as this example is near to the limitations of floating point arithmetic). Josef > x <- qbeta((0:100)/100,0.01,5) > x [1] 0.000000e+00 1.253990e-201 1.589622e-171
2005 Jan 12
2
Inaccuracy in seq() function (PR#7503)
Full_Name: Vlad Stolin Version: R 2.0.0 OS: Windows 2000 Submission from: (NULL) (204.128.232.211) When generating the sequence using seq() function with non-integer numbers result is somewhat unpredictable. Example: > v1<-seq(1.60,1.90,.05) > v2<-c(1.60,1.65,1.70,1.75,1.80,1.85,1.90) > v1-v2 [1] 0.000000e+00 2.220446e-16 2.220446e-16 0.000000e+00 0.000000e+00 0.000000e+00
2009 Oct 10
1
isFALSE
Hello, Just wondering why there is "isTRUE" and not "isFALSE". Romain -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/BcPw : celebrating R commit #50000 |- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc `- http://tr.im/yw8E : New R package : sos -------------- next part -------------- An
2020 Aug 11
2
M[cbind()] <- assignment with Matrix object loses attributes
? Does this constitute a bug, or is there something I'm missing? assigning sub-elements of a sparse Matrix via M[X]<-..., where X is a 2-column matrix, appears to drop user-assigned attributes. I dug around in the R code for Matrix trying to find the relevant machinery but my brain started to hurt too badly ... ?? Will submit this as a bug if it seems warranted. library(Matrix) m1
2006 Jan 10
2
Correct way to test for exact dimensions of matrix or array
Dear R Users, I want to test the dimensions of an incoming vector, matrix or array safely and succinctly. Specifically I want to check if the unknown object has exactly 2 dimensions with a specified number of rows and columns. I thought that the following would work: > obj=matrix(1,nrow=3,ncol=5) > identical( dim( obj) , c(3,5) ) [1] FALSE But it doesn't because c(3,5) is numeric
2024 Oct 23
1
OSX-specific Bug in randomForest
I've cc'd this to the package maintainer, Andy Liaw <andy_liaw at merck.com>. I'm not sure he reads this list. Duncan Murdoch On 2024-10-23 1:26 a.m., Stevie Pederson wrote: > Hi, > > It appears there is an OSX-specific bug in the function > `randomForest.default()` Going by the source code at >
2006 Jan 30
2
'all' inconsistent?
Hello, I came across the following behavior, which seems illogical to me. I don't know if it is a bug or if I'm missing something: > all(logical(0)) [1] TRUE > any(logical(0)) [1] FALSE > isTRUE(logical(0)) [1] FALSE This actually came up in practice when I did something like > all( names(x) %in% vec ) as an error-handling, and I was hoping that it would work regardless