-
-
Notifications
You must be signed in to change notification settings - Fork 18.5k
assert_almost_equal #13357
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.
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
Comments
hmm, that seems odd. in any event try with master, you can now pass an integer to |
Hi, thanks for the speedy response! Looking at the master branch, we will see the same problem: https://github.com/pydata/pandas/blob/master/pandas/src/testing.pyx#L197
The numbers (fa, fb) are divided and compared to 1. Which is interesting, but not quite the same as just comparing the parts after the decimal point (as the docstring suggests). Perhaps I'm just reading the docs incorrectly. |
+1 to always compare using specified precision (not |
The problem is still present: Here some examples based on the first comment.
I don't know how to make this works, in addition, I find the message a little weird. |
and this is an open issue. you are welcome to submit a PR to fix. |
I would like to fix it but I not 100% sure that I understand the rationale of the code. When using
instead of
From my understanding, the idea here is that the comparison precision (i.e. represented by Should we update the documentation or the code? I would vote to change the code. The whole point of providing the precision is that the user knows what is the correct epsilon to use with the values that are being compared. Did I understood the rationale of the code? Are you OK with a PR to change the code? |
@NewbiZ : PR changes are welcome so long as they fix the issue AND not break existing tests! 😄 |
@jreback I'm Sorry, maybe I did not pick the right words, I just wanted to leave a reminder and add a couple of things. It wasn't a complaint at all. You're right, I tried to correct it but it was difficult for me to understand the why of some parts of this function. Bests, |
This commit adds a new keyword argument `check_low_values`, that will allow the approximate comparison of numerics based on literal decimal places. This is particularly useful when comparing low values: # This fails because it's doing (1 - .1 / .1001) assert_almost_equal(0.1, 0.1001, check_less_precise=True) # This will work as intuitively expected assert_almost_equal( 0.1, 0.1001, check_less_precise=True, check_low_values=True )
take |
This commit adds a new keyword argument `check_low_values`, that will allow the approximate comparison of numerics based on literal decimal places. This is particularly useful when comparing low values: # This fails because it's doing (1 - .1 / .1001) assert_almost_equal(0.1, 0.1001, check_less_precise=True) # This will work as intuitively expected assert_almost_equal( 0.1, 0.1001, check_less_precise=True, check_low_values=True )
Hi, I'm wondering if the following behavior of pandas._testing.assert_almost_equal is expected:
Code Sample, a copy-pastable example if possible
Expected Output
Expect no output / no AssertionError
Actual Output
Note that the numbers differ at decimal 6 and the output suggests they are different at position 3.
output of
pd.show_versions()
INSTALLED VERSIONS
commit: None
python: 2.7.11.final.0
python-bits: 64
OS: Darwin
OS-release: 15.5.0
machine: x86_64
processor: i386
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
pandas: 0.18.1
nose: None
pip: 8.0.2
setuptools: 21.2.1
Cython: None
numpy: 1.11.0
scipy: 0.17.1
statsmodels: None
xarray: None
IPython: 4.2.0
sphinx: None
patsy: None
dateutil: 2.5.3
pytz: 2016.4
blosc: None
bottleneck: None
tables: None
numexpr: None
matplotlib: 1.5.1
openpyxl: 2.3.3
xlrd: 0.9.4
xlwt: 1.0.0
xlsxwriter: None
lxml: None
bs4: None
html5lib: None
httplib2: None
apiclient: None
sqlalchemy: 1.0.12
pymysql: None
psycopg2: 2.6.1 (dt dec pq3 ext lo64)
jinja2: 2.8
boto: 2.39.0
pandas_datareader: None
The text was updated successfully, but these errors were encountered: