0

I have written the following code in Rstudio editor, and the builtin function %in% is not working as desired. At the third last iteration there is a match but %in% is not returning TRUE. Kindly help.

longi=c(5.044747,5.054746,9)
longdummypos=longi
incrementinx=0.000001
for (incx in seq(from=0, to=0.01, by=incrementinx))
{
 longdummypos=longdummypos+incrementinx
 print(longdummypos)
 print(longi)
  a=longdummypos %in% longi
  print(a)
  t1=is.element(TRUE,a)

    if(t1==TRUE)
    {
      break()
    }

    incrementinxfinal=incx  
}
Faraz Hassan
  • 1
  • 1
  • 3
    If it is a floating point number, then there is precision and it may not exactly match – akrun Jun 07 '20 at 18:04
  • This is related to [R FAQ 7.31](https://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f) and https://stackoverflow.com/q/9508518/3358272. In fact, since `%in%` is looking for *equality*, it's a dupe of that (in concept if not actual code). This problem is not unique to R, most languages that use "simple" IEEE-754 for floating-point storage and arithmetic are going to be prone to this problem. – r2evans Jun 07 '20 at 18:07
  • 1
    Okay, @akrun, provide an answer that differs in context and point to the R FAQ and answer that I linked. *"Selective dupe tagging"* is by design: I selectively tag as dupe questions that I feel are dupes, not sure what point you're trying to make. – r2evans Jun 07 '20 at 18:12
  • The issue is not clear. When I commented, it is only based on some assumptions – akrun Jun 07 '20 at 18:13
  • @r2evans i have checked %in% in another simple example in console,and it is working perfectly fine upto 6 decimal places (my desired accuracy). The problem occurs when i use it inside the for loop. – Faraz Hassan Jun 07 '20 at 18:24
  • There is not a match on the fourth iteration. On the fourth iteration, I see: "[1] 5.044751 5.054750 9.000004 [1] 5.044747 5.054746 9.000000 [1] FALSE FALSE FALSE" No match there – duckmayr Jun 07 '20 at 18:27
  • @duckmayr Sorry i made a mistake. It's the third last iteration – Faraz Hassan Jun 07 '20 at 18:36
  • @r2evans . But it is working perfectly fine when the same values of the particular (third last)iteration are tested in the console window seperately. – Faraz Hassan Jun 07 '20 at 18:51
  • 1
    Faraz, testing equality of floating-point numbers works some or perhaps even most of the time, but the premise of testing true equality (in most programming languages) is flawed due to how numbers are stored internally. You need to determine a *tolerance* of effectively-equal numbers, perhaps if `abs(a-b) < 1e-8`. It will often work fine, but it is not guaranteed to work all of the time. – r2evans Jun 07 '20 at 18:51
  • 1
    Faraz, instead of base R's `%in%`, consider using this quick hack: `\`%isin%\` <- function(a, b, tol = sqrt(.Machine$double.eps)) rowSums(abs(outer(a, b, \`-\`)) < tol) > 0` instead. – r2evans Jun 07 '20 at 19:00
  • Better yet, add `na.rm=TRUE` to the `rowSums` call ... – r2evans Jun 07 '20 at 19:09
  • While this is a common question, it is still a duplicate in the premise of equality (and therefore set-membership). Do you have enough help and context to be able to close this question? – r2evans Jun 07 '20 at 19:16
  • @r2evans. Yes, I got the solution for the problem. Thankyou very much for helping. – Faraz Hassan Jun 07 '20 at 19:22
  • @akrun, it's been clearly resolved as the same issue as discussed early in the comments. Since I closed and then reopened, I cannot close it as a dupe of https://stackoverflow.com/q/9508518/3358272. Would you please close it as a dupe? – r2evans Jun 07 '20 at 19:23
  • @r2evans closed now – akrun Jun 07 '20 at 19:24

0 Answers0