+/-0 on this:

• disadvantage: mixingnp andmath makes the code more complex
• advantage: performance gain

The question is: How much performance gain do we get? E.g if I save 1µs in a function that takes 100µs (numbers made up), special-casing some functions to math is IMHO not worth it.

Note that math.sqrt is no longer used. The math.pi part was not originally part of the PR, but suggested by@anntzer

New benchmark (different computer):

In [45]: %timeit np.sqrt(2)717 ns ± 2.49 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)In [46]: %timeit 2 ** (1 / 2)5.97 ns ± 0.376 ns per loop (mean ± std. dev. of 7 runs, 100,000,000 loops each)

Not sure how much math.pi improves the speed (if any). Tried to read up if the compiler possibly can precompute the result with math.pi but I have not come to any insight.

I'm also a bit doubtful about if e.g. pi / 2 or pi / 2.0 should be used (or 0.5 * pi). Benchmarking gives a slight advantage for the float constants, but there may be other aspects as well.

For reference, in current main:

• / 2 : 363 instances (a few are comments/docstring etc)
• / 2. : 107 (all proper code)
• * 0.5 : 41 (all proper code)
• 0.5 * : 67 (some overlap with * 0.5)

The question is not how much speed is gained by replacingnp.sqrt(2) by2**(1/2), but how much is gained e.g. when creating a minimal geo axes or plotting something on a geo axes or whatever "minimal matplotlib-relevant action" that exercises this piece of code.

The question is not how much speed is gained by replacingnp.sqrt(2) by2**(1/2)

Correct. But much easier to just try out the operation...

Btw, it seems like not all the code is actually tested. I messed up in a trig rewrite in two locations, but only got an error for one of them...

Btw, it seems like not all the code is actually tested.

codecov states that we have 81% coverage. The missing 19% is unfortunately not only edge cases and trivial code. In particular in earlier times, testing was more optional, and there's quite a bit of code that nobody has written tests for yet.

On the optimizations: I have the impression you are falling for the micro-optimization trap

In [45]: %timeit np.sqrt(2)
717 ns ± 2.49 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

In [46]: %timeit 2 ** (1 / 2)
5.97 ns ± 0.376 ns per loop (mean ± std. dev. of 7 runs, 100,000,000 loops each)

In relative numbers this is a magnificently sounding 100x speed improvement. However, assume we need 100 of those calculations for creating a plot. That's still only 70us, and negligable compared to

In [4]: %%timeit
...: plt.plot([1, 2])
...: plt.show(block=False)
...: plt.close()
...:
26.4 ms ± 1.44 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

Unless such nanosecond optimizations are in a really hot place, they don't give any measurable benefit and are thus not worth the effort. Even more: If the performance benefit is negligable, other aspects like readability and maintainability of the code will become the deciding factors how code is best written.

In particular in earlier times, testing was more optional, and there's quite a bit of code that nobody has written tests for yet.

We are older than both pytest and nose ;)

We are older than both pytest and nose ;)

If somebody still knows nose 👴.

@oscargus did you still want this to move forward? I'll move to draft, but feel free to move back