You are viewing a plain text version of this content. The canonical link for it is here.

Posted to commits@mxnet.apache.org by GitBox <gi...@apache.org> on 2019/12/26 15:28:49 UTC

[GitHub] [incubator-mxnet] nickguletskii opened a new pull request #17177: Bugfix/locale invariant stod

nickguletskii opened a new pull request #17177: Bugfix/locale invariant stod
URL: https://github.com/apache/incubator-mxnet/pull/17177

## Description ##
Currently, many operators utilize `std::stod` to convert strings into floating point numbers. This causes incorrect calculations (#17140, #16134) when the C locale is set to a locale which uses commas (`,`) as decimal point separators.

This pull request replaces calls to `std::stod` and `std::stof` to `dmlc::stod` and `dmlc::stof` respectively.

### The scope of this patch ###

This patch should fix a large portion of interactions through Python and JVM frontends, since they use locale-invariant serialization in order to pass parameters into MXNet's C API.

However, frontends which utilize C locale-aware serialization (i.e. call `sprintf` or similar) may break when using locales which don't use `.` as the decimal separator. They will have to be fixed in a separate patch. I also suspect that they are already broken, because operators utilising dmlc-core parameter parsing were already using locale-invariant serialization.

### Further steps ###
STL streams are heavily used within the codebase, both for serialization and for forming user-friendly messages. Fortunately, they don't seem to be affected by the C standard library locale settings. However, if someone sets the STL locale by calling [std::locale::global](https://en.cppreference.com/w/cpp/locale/locale/global), MXNet's API will be broken. In order to ensure that this doesn't happen, all streams which are used for serialization will have to be imbued with the "C" locale (not the locale set in the C standard library).

It would be nice to see a more principled approach to serialization in MXNet 2.0, e.g. using a binary format for communication between the frontend and the backend. In addition to solving locale-related issues, this would probably result in a smaller invocation overhead.

### Locale-invariant serialization vs locale-aware serialization ###

As a side-note, using locale-aware serialization is not an option, simply because using `,` as the decimal separator adds ambiguities to tuple serialization, e.g. `(4,4,3)` can be a tuple of 3 integers, or a tuple of 2 floats.

## Checklist ##
### Essentials ###
Please feel free to remove inapplicable items for your PR.
- [ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant [JIRA issue](https://issues.apache.org/jira/projects/MXNET/issues) created (except PRs with tiny changes)
- [x] Changes are complete (i.e. I finished coding on this PR)
- [x] All changes have test coverage:
- Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
- Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
- Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
- [x] Code is well-documented:
- For user-facing API changes, API doc string has been updated.
- For new C++ functions in header files, their functionalities and arguments are documented.
- For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
- Check the API doc at https://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
- [ ] To the best of my knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

### Changes ###
- [x] Replace `std::stod` with `dmlc::stod` and `std::stof with `dmlc::stof`.
- [x] Add a test that tests locale invariance for scalar ops.

## Comments ##
- May break Julia and R code when using a locale that uses `,` as the decimal separator. However, since there was no consistency between the various operators before, it is not unlikely that the code was already broken.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

With regards,
Apache Git Services