Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix integer bins closed left #40

Merged
merged 2 commits into from
Mar 18, 2024
Merged

fix integer bins closed left #40

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1145b08
make sure ints are handled appropriately whether right or left closed
d-callan Mar 18, 2024
3948080
add test for left inclusive integer bins where bin width is 1
d-callan Mar 18, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 16 additions & 9 deletions R/utils-cut.R
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,18 +77,25 @@ cut_width <- function(x, width, center = NULL, boundary = NULL, closed = c("righ

# Determine bins

# In practice, min_x is always min(x) because cut_width() is only called with
# boundary=min(x) and inside find_origin(), shift is always zero, so find_origin()
# returns boundary which is min(x).
# Perhaps we can rationalise/remove the boundary code if a use-case can't
# be described.
# Find functional min and max which produces consistently sized bins
# its possible we want to do this for ints regardless of the bin width??
min_x <- find_origin(x_range, width, boundary)
# if x are integers and width is 1, make sure min_x is one smaller than the data
if (all(x == round(x)) && width == 1) {
min_x <- min_x - 1
if (closed == "right") {
# if x are integers and width is 1, make sure min_x is one smaller than the data
# otherwise the first bin will be functionally twice the width
if (all(x == round(x)) && width == 1) {
min_x <- min_x - 1
}
}

max_x <- max(x, na.rm = TRUE)
if (closed == "left") {
# if x are integers and width is 1, make sure max_x is one greater than the data
# otherwise the last bin will be functionally twice the width
if (all(x == round(x)) && width == 1) {
max_x <- max_x + 1
}
}

breaks <- c(seq(min_x, max_x, width))
last_break = tail(breaks, 1)
Expand Down
8 changes: 8 additions & 0 deletions tests/testthat/test-utils-cut.R
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,4 +28,12 @@ test_that("cut_width splits the first inclusive bin for integers where bin width

expect_equal(as.character(cut_width(ints, 1, .5)), expectedBins)
expect_equal(as.character(cut_width(ints,1,boundary=min(ints))), expectedBins)
})

test_that("cut_width splits the last inclusive bin for integers where bin width is 1", {
ints <- c(0,1,2,2,3,3,3,4,4,4,4)
expectedBins <- c("[0,1)","[1,2)","[2,3)","[2,3)","[3,4)","[3,4)","[3,4)","[4,5]","[4,5]","[4,5]","[4,5]")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since they're integers, can we have the last bin simply say "[4, 5)"? It makes sense that the last bin end is 5, but we know we added "5" to make the bin.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thats default behavior of cut, for good reasons, and im not inclined to digging into that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you explain what the reasons are? It doesn't make sense to me.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for every other case, except the one where we have integers or dates w one value per bin, then either the first or last bin needs to be inclusive on both sides. and in fairness, bins w one discrete value per bin, arent really bins at all. i think what cut does is perfectly reasonable, for the vast majority of cases, and trying to run our own impl of a base r fxn feels like a bad idea.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

id rather contribute to base r for this edge case, and get the fix a year from now when it finally works its way through, than run our own impl of cut for that label.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i did not mean to suggest we make our own version of cut or anything, i just didn't understand why having bins like "[4, 5]" were a good idea

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not necessarily arguing they're a good idea, so much as they're not worth the effort to change. They're not very likely to actually confuse anyone, may not even be actually seen by anyone, but do cost me time to change, don't have a super clean way to change and do risk introducing bugs elsewhere by changing. I'd rather just keep relying on cut as-is to do its thing.


expect_equal(as.character(cut_width(ints, 1, .5, closed = "left")), expectedBins)
expect_equal(as.character(cut_width(ints,1,boundary=max(ints),closed = "left")), expectedBins)
})
Loading