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