On Wed, May 31, 2023 at 5:51 PM Benjamin Root <ben.v.r...@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
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
