Questionable Results

[brichard1638]

This issue concerns the output provided by the in.range function. In the latest version of quickcode, version 0.7, there appears to be an inconsistency in the output based on two equally defined functional configurations.

The proposed error is reproduced below.

For example, the following in.range code yields the following output with all TRUE values: library(quickcode) in.range(50:60, range.vec = c(55,33,22,56,75,213,120)) [1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE

The code syntax reconfigures the in.range function where the output should be the same - but it's not: x = c(55,33,22,56,75,213,120) in.range(x, range.min = 50, range.max = 60) [1] TRUE FALSE FALSE TRUE FALSE FALSE FALSE

Since there are 11 values returned in the first example and only 7 in the second example, it begs the question as to how the first example is being evaluated against the range.vec argument. How is the function being evaluated where all values returned are TRUE?

[oobianom]

I see your question Brice, perhaps the documentation needs to be revised?

in.range( value, range.min, range.max, range.vec = NULL, closest = FALSE, rm.na = FALSE )

So the in.range is simply looking to see if "value" exists within the range.

The range for which "value" should be test can be either two numbers, a minimum (range.min) and a maximum (range.max).

Now, depending on the kind of data you are working with, this means that you first have to compute the range.min and range.max, before using the function to test if "value" is in that range. Well, the current function provides a second option to save you the step of computing the range.min and range.max, it is the range.vec . Therefore, range.vec is an alternative means to specify the range for which "value" should be tested. When range.vec is specified, the function simply uses range(range.vec) to compute range.min and range.max before proceeding to test if "value" is within that range.

Let me know if it makes sense now, and what you think Brice.

[brichard1638]

Obi:::

Your explanation aligns with my understanding of the functional behavior of in.range.

So, if I am interpreting your explanation correctly, and using your example:

in.range(50:60, range.vec = c(55,33,22,56,75,213,120))

[1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE

The result of this example returns 11 TRUE values.

Logic If we sort the values in the range.vec option we get:

sort(c(55,33,22,56,75,213,120)) [1] 22 33 55 56 75 120 213

This places 22 as the range min and 213 as the range max In the original order of range.vec, and given this scenario, 55, the first value in the range.vec should return TRUE 33, the next value should return FALSE as 33 is NOT in the range between 50-60 By this same logic, 22 should also return a FALSE value 56 returns TRUE 75 returns FALSE * 213 and 120 should both return FALSE as they are not in the range between 50-60

So, as I understand the configuration of this function example:

in.range(50:60, range.vec = c(55,33,22,56,75,213,120)) Should return:

[1] TRUE FALSE FALSE TRUE FALSE FALSE FALSE

Is this correct?

The function returns 11 values instead of 7 so I'm still not sure how this function is intended to work using the range.vec argument and also given your explanation.

If I don't understand the function, I suspect others will struggle to understand it as well.

Please advise by explaining in a manner that breaks out the explanation using the outline I've provided.

Brice

---

From: Obi Obianom @.> Sent: Tuesday, March 5, 2024 4:41 PM To: oobianom/quickcode @.> Cc: brichard1638 @.>; Author @.> Subject: Re: [oobianom/quickcode] Questionable Results (Issue #17)

I see your question Brice, perhaps the documentation needs to be revised?

in.range( value, range.min, range.max, range.vec = NULL, closest = FALSE, rm.na = FALSE )

So the in range is simply looking to see if "value" exists within the range.

The range for which "value" should be test can be either two numbers, a minimum (range.min) and a maximum (range.max).

Now, depends on the kind of data you are working with, this means that you first have to compute the range.min and range.max, before using the function to test if "value" is in that range. Well, the currently function provides a second option to save you the step of computing the range.min and range.max, it is the range.vec . Therefore, range.vec is an alternative means to specify the range for which "value" should be tested. When range.vec is specified, the function simply uses range(range.vec) to compute range.min and range.max before proceeding to test if "value" is within that range.

Let me know if it makes sense now, and what you think Brice.

— Reply to this email directly, view it on GitHubhttps://github.com/oobianom/quickcode/issues/17#issuecomment-1979684242, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASLI5UPACWHOR4WSYWEUECDYWY3ZVAVCNFSM6AAAAABEECWJRSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZZGY4DIMRUGI. You are receiving this because you authored the thread.Message ID: @.***>

[oobianom]

Hi Brice, okay let me explain.

Function call: in.range(50:60, range.vec = c(55,33,22,56,75,213,120))

Behavior: a = sort(c(55,33,22,56,75,213,120)) range.min = a[1] range.max = a[7]

Now, the function will test this - sample_to_test = c(50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60) # same thing as 50:60

For each of the numbers in the vector sample_to_test, the function will test if the number is between range.min and range.max

It will return result for each of the 11 values in sample_to_test, that's why you see [1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE

Again, may be the solution here will be to improve the documentation so that it is more clear. What do you think?

[brichard1638]

I'm still confused. If the sample_to_test is 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60 and the min range is 55 a[1] while the max range is 120 a[7], then 50 through 54 should be FALSE not TRUE as none of these values are within a range of 55-120. Another question I have is that 120 is not the largest value in the range - it's actually 213 at a[6]. ???

Am I missing something here?

[oobianom]

Resolving this issue will also be part of the next release