Accurate trig functions with degrees in scipy

[adriesse]

I just came across this in scipy:

https://docs.scipy.org/doc/scipy/reference/generated/scipy.special.cosdg.html#scipy.special.cosdg

x = 90 + 180 * np.arange(3)

sc.cosdg(x)
array([-0.,  0., -0.])

np.cos(x * np.pi / 180)
array([ 6.1232340e-17, -1.8369702e-16,  3.0616170e-16])

Any objections to using them in pvlib?

[kandersolar]

One downside is that the scipy functions seem to be slower than ours. Of course whether the slowdown is meaningful is another question.

In [1]: from scipy.special import sindg, cosdg, tandg
   ...: from pvlib.tools import sind, cosd, tand
   ...: import numpy as np
   ...: 
   ...: x = np.linspace(-1, 1, 10_000)

In [2]: %timeit _ = sind(x)
43 µs ± 898 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

In [3]: %timeit _ = sindg(x)
399 µs ± 4.47 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

In [4]: %timeit _ = cosd(x)
42.4 µs ± 698 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

In [5]: %timeit _ = cosdg(x)
435 µs ± 6.68 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

In [6]: %timeit _ = tand(x)
49.5 µs ± 1.11 µs per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

In [7]: %timeit _ = tandg(x)
103 µs ± 2.35 µs per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

In [8]: import scipy; scipy.__version__
Out[8]: '1.8.1'

[mikofski]

there was a lot of chatter in the scipy mail lists about this. Could it be a C implementation that is naively looping? That would make it slow vs. some numpy accelerated version.

[adriesse]

There is indeed some c code behind it, but I don't know how it loops. I do like the fact that it cosdg(90) goes cleanly to zero. I suppose rounding off the answer could achieve the same?

[wholmgren]

I support the idea in principle, but the trig functions are the bottleneck in some pvlib functions. Need to make sure there are benchmarks for any function that we change!

[mikofski]

Sorry I'm -1 on switching, but TBH, I've never been a fan of the degree calculations to begin with, b/c I prefer to convert inputs & outputs to/from radians/degrees once. Mainly I am concerned about 2x to 10x slowdown, and the existing functions aren't broken. Having cos(pi/2) -> zero isn't a concern for me, because in IEEE floats, 1e-16 is as close to zero as you can get. IMHO one should not rely to heavily on the exact value of floats. EG that's why we use np.isclose() etc

[adriesse]

Ok, since it's controversial, let's drop it. We have other cats to whip. (Apologies to cat lovers!)