add test case for empty array

[NewBornRustacean]

Add test cases for empty arrays in partition()

@akern40 what's up! thanks to follow up #1502 😃
I realize that you add check to empty array but if empty array comes in, partition goes panic for now.
this PR is adding test cases for that cases(empty array).

if we prefer return result with empty array, then we need to change the bound check logic imo.

        let axis_len = self.len_of(axis);
        if kth >= axis_len {
            panic!("partition index {} is out of bounds for axis of length {}", kth, axis_len);
        }

Changes

• Added test_partition_empty() test case to validate behavior of partition() with empty arrays
• Tests three scenarios:
  1. 1D empty array (Array1::zeros(0))
  2. 2D empty array with zero rows (Array2::zeros((0, 3)))
  3. 2D empty array with zero columns (Array2::zeros((2, 0)))

Why Panic?

The partition() method should panic when called on empty arrays for several reasons:

1. Logical Consistency: Partitioning requires a kth element to partition around, but empty arrays have no elements to use as a pivot. This makes the operation undefined for empty arrays.

2. Mathematical Correctness: The partition operation's postcondition requires that:

   • All elements before the kth index are ≤ the kth element
   • All elements after the kth index are ≥ the kth element
     This condition cannot be satisfied with an empty array since there is no kth element.

3. Safety: Allowing partition on empty arrays could lead to undefined behavior or incorrect results in algorithms that rely on the partitioning postcondition.

4. Consistency with Other Operations: Many array operations (like indexing, slicing) panic on empty arrays when the operation is undefined, making this behavior consistent with the rest of the API.

[akern40]

Hey! So I'm not sure I agree with this... I think partitioning around a valid index (i.e., k < self.len_of(axis)) on an empty array should return an empty array. My argument is three-fold:

1. I don't think it's logically inconsistent or will cause downstream effects (that wouldn't already be caused by an empty array) - I think the post-condition is trivially true for an empty array.

2. I'm never quite comfortable with how much we panic in the library, and I think if we can justify returning a result instead of panicking, then we should.

3. It's what NumPy does; I actually think this is the strongest argument 😅 I wonder if there's been some discussion on NumPy to this question

[akern40]

Oh I do think we should test it though, so thank you for that!

[akern40]

I wonder if there's been some discussion on NumPy to this question

I can't find any with a quick search, which makes me think that this hasn't been a major issue for users (and that we should therefore opt to use NumPy's behavior).

One more argument: it seems odd to me that we'd want the behavior of a function to change when the user alters the length of a different axis from the one that they're operating on. It feels like the error would be a little "far away" from the function itself. There's a policy laid out by one of the original library authors somewhere (I can't find it right now) that says a function can only panic as a result of bad arguments, not as a result of the contents of an array (i.e., you can't panic if you encounter a certain value in an array, you'd have to return a Result instead). I don't think whether this policy does / should extend to the shape of the array.

[NewBornRustacean]

@akern40 Hi! Thanks for the comments.
I also agree that the behavior should be consistent with NumPy!

How about modifying it so that if the input array is empty, the result array is returned immediately before performing the bound check?
will add a new test case for the empty array as well!

[akern40]

@NewBornRustacean I was on vacation but these look good! I just added some documentation, once the tests pass I'll merge this in.