Skip to content

numpy.dot depends on input shape #11419

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
nadavbra opened this issue Jun 25, 2018 · 1 comment
Closed

numpy.dot depends on input shape #11419

nadavbra opened this issue Jun 25, 2018 · 1 comment

Comments

@nadavbra
Copy link

I run the following code:

import numpy as np

v = np.array([0.7372549, 0.25882354, 0.00392157], dtype = np.float32)
print(v)

print('*' * 50)

x = np.ones((1, 3), dtype = np.float32)
print(x)
print(np.dot(x, v))

print('*' * 50)

x = np.ones((2, 3), dtype = np.float32)
print(x)
print(np.dot(x, v))

And get the following output:

[0.7372549  0.25882354 0.00392157]
**************************************************
[[1. 1. 1.]]
[1.]
**************************************************
[[1. 1. 1.]
 [1. 1. 1.]]
[1.0000001 1.0000001]

Mathematically, the second result should have been the same as the first, repeated twice. But instead I get a slightly different numerical result (1.0000001 instead of 1.0). This inconsistency actually matters for my program.

Any insight to why this is happening, and possible workarounds?

I use NumPy 1.14.1.
Python version: 2.7.12+ (default, Aug 4 2016, 20:04:34) [GCC 6.1.1 20160724]
OS: Debian GNU/Linux 9

Thank you.
@seberg
Copy link
Member

seberg commented Jun 25, 2018

That is not a numpy issue:

  1. You cannot numerically expect the result to be exactly 1.0, the other value is numerically just as correct (or correct enough).
  2. Numpy and especially the linear algebra routines that numpy uses, for example optimize memory access for speed. Such thing reorder the actual numerical operations taking place, which can cause different round off errors to occur.
  3. Such round of errors will not be stable on different platforms or even hardware.
  4. You should not rely on floats to be exactly equal normally, there is a reason functions to compare whether they are almost equal exist.

Also, unless you are clear about such round of issues and you know that it works fine for you, do not use float32! There is a readon float64 is the default. So the normal workaround: Use float64, and the numerical error will be a few magnitudes smaller, or some arbitrary precision types.

You might get what you want by replacing or reordering the dot product, but there is no guarantee it will work always.

@seberg seberg closed this as completed Jun 25, 2018
@TomDLT TomDLT mentioned this issue Aug 1, 2018
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@seberg @nadavbra