Skip to content

Conversation

auscompgeek
Copy link
Member

These functions provide identical results to the native Python operators // and %. I've verified this is true by property testing with hypothesis.

from hypothesis import assume, given, strategies as st

int64 = st.integers(-2**63, 2**63 - 1)


@given(int64, int64)
def test_floorDiv(a, b):
    assume(b != 0)
    from wpimath import floorDiv

    output = floorDiv(a, b)
    assert output == a // b


@given(int64, int64)
def test_floorMod(a, b):
    assume(b != 0)
    from wpimath import floorMod

    output = floorMod(a, b)
    assert output == a % b

These functions are objectively worse than the native operators in two ways:

  • They only accept integers that fit in a 64-bit int.
  • They have worse performance (presumably due to binding overhead). I've benchmarked these functions on my laptop* against the functions in the operator module, and the native operators consistently win out from a random sample -- pytest-codspeed consistently runs almost 2x iterations of the native operators with less total runtime.

* Framework Laptop 13, AMD Ryzen 5 7640U, Fedora Linux 42, Python 3.12.11, kernel 6.16.7-200.fc42.x86_64

These provide identical results to the native Python operators `//` and `%`, with worse performance.
@virtuald
Copy link
Member

I guess? Added it to make migration easier, would be nice if there was a way to let users know this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants