On Wed, May 31, 2023 at 5:51 PM Benjamin Root <ben.v.root@gmail.com> wrote:
I think it is the special values aspect that is most concerning. Math is just littered with all sorts of identities, especially with trig functions. While I know that floating point calculations are imprecise, there are certain properties of these functions that still held, such as going from -1 to 1.
As a reference point on an M1 Mac using conda-forge: ```
import numpy as np np.__version__ '1.24.3' np.sin(0.0) 0.0 np.cos(0.0) 1.0 np.sin(np.pi) 1.2246467991473532e-16 np.cos(np.pi) -1.0 np.sin(2*np.pi) -2.4492935982947064e-16 np.cos(2*np.pi) 1.0
Not perfect, but still right in most places.
FWIW, those ~0 answers are actually closer to the correct answers than 0 would be because `np.pi` is not actually π. Those aren't problems in the implementations of np.sin/np.cos, just the intrinsic problems with floating point representations and the choice of radians which places particularly special values at places in between adjacent representable floating point numbers.
I'm ambivalent about reverting. I know I would love speed improvements because transformation calculations in GIS is slow using numpy, but also some coordinate transformations might break because of these changes.
Good to know. Do you have any concrete example that might be worth taking a look at in more detail? Either for performance or accuracy. -- Robert Kern