Skip to content
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

Fix floating point number comparison in BatchNorm #14

Closed
wants to merge 275 commits into from

Conversation

TaoLv
Copy link

@TaoLv TaoLv commented Jan 11, 2018

Description

Fix floating point number comparison in BatchNorm:

  • using fabs(a-b) < 1e-8 for double precision floating point number
  • using fabs(a-b) < 1e-6 for single precision floating point number

Checklist

Essentials

  • Passed code style checking (make lint)
  • Changes are complete (i.e. I finished coding on this PR)
  • All changes have test coverage
  • For user-facing API changes, API doc string has been updated. For new C++ functions in header files, their functionalities and arguments are well-documented.
  • To my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

  • Feature1, tests, (and when applicable, API doc)
  • Feature2, tests, (and when applicable, API doc)

Comments

  • If this change is a backward incompatible change, why must this change be made.
  • Interesting edge cases to note here

zheng-da and others added 21 commits January 2, 2018 03:19
This commit may add some overhead of managing NDArray for each fallback.
Conflicts:
	src/operator/nn/mkldnn/mkldnn_batch_norm-inl.h
2. Add memory into signature;
3. Try to split BatchNorm into .h file and .cc file. Will finish it after backward code is refactored.
Caching primitive for BatchNorm forward computation
Add primitive caching for Pooling forward computation
OP primitive cache: use memory as signature for MKLDNN storage type
@zheng-da
Copy link
Owner

i don't think it's necessary. the parameters are provided by users. if they are different, we can consider them different.

@TaoLv
Copy link
Author

TaoLv commented Jan 11, 2018

If user provides 1/sqrt(2) twice, for user, they are same, but for fp number, there may be a slight difference. Just a concern, you can keep it as is. :)

@zheng-da zheng-da force-pushed the refactor branch 5 times, most recently from d6402e0 to ea46c2f Compare January 15, 2018 05:20
@zheng-da zheng-da closed this Jan 15, 2018
TaoLv pushed a commit to TaoLv/incubator-mxnet that referenced this pull request Aug 8, 2019
* Added tutorial for FIT API

* Added tests for Fit API tutorial

* Updated index.md for the new tutorial to show up

* Addressed PR feedback

* Addressed PR feedback

* Removed spurious comment for Py2 and Py3 compatibility

* Address PR feedback

* Addressed PR feedback

* Fixed typo

* Added example to showcase custom event handler

* Fixed imports as estimator moved to contrib package

* Added a side note to inform about estimator reference being updated by the handlers

* Corrected typo

* update tutorial

* address comments

* new line

* fix import

* fix cached graph

* fix import

* address comments

* fix doc gen

* add softmax

* add to website index

* fix doc string

* Fix doc gen (zheng-da#12)

* fix warining

* fix test

* fix

* fix

* fix print

* fix test (zheng-da#13)

* fix warning (zheng-da#14)

* fix href (zheng-da#15)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants