Skip to content
This repository has been archived by the owner on Nov 17, 2023. It is now read-only.

[v1.7.x] Backport #17177 to 1.7.x (Fix incorrect calculation results when the C locale is set to a locale that uses commas as the decimal separator) #18147

Merged

Conversation

nickguletskii
Copy link
Contributor

Description

Backport #17177 to the branch for v1.7.x.

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 separators.

This pull request replaces calls to std::stod and std::stof to the locale-invariant 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, 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 created (except PRs with tiny changes)
  • Changes are complete (i.e. I finished coding on this PR)
  • 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)
  • 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

  • Replace std::stod with dmlc::stod and std::stof with dmlc::stof`.
  • 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.

@mxnet-bot
Copy link

Hey @nickguletskii , Thanks for submitting the PR
All tests are already queued to run once. If tests fail, you can trigger one or more tests again with the following commands:

  • To trigger all jobs: @mxnet-bot run ci [all]
  • To trigger specific jobs: @mxnet-bot run ci [job1, job2]

CI supported jobs: [edge, centos-gpu, website, centos-cpu, miscellaneous, windows-cpu, unix-gpu, sanity, unix-cpu, windows-gpu, clang]


Note:
Only following 3 categories can trigger CI :PR Author, MXNet Committer, Jenkins Admin.
All CI tests must pass before the PR can be merged.

@ciyongch
Copy link
Contributor

Adding this PR to 1.7.0 roadmap #16864.

@ciyongch
Copy link
Contributor

@leezu can you help to take a review and approve/merge if it looks ok to you :)

@leezu leezu merged commit b2e0cce into apache:v1.7.x Apr 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants