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

"Nines" bug fix #2

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

weefatboi
Copy link

@weefatboi weefatboi commented Jun 17, 2021

What bug does this PR fix?

  • There's a bug where iterations of three 9s (999, 999999, 999999999, etc) should round up to the next millname (999999 should become 1M, but displays 1000k).
  • The cause was usage of the math.floor() when determining which prefix to append to inputted numbers. Floor rounds down to the nearest whole integer, forcing numbers that should be rounded up have one less millidx than they should at the time of string formatting. This has been replaced with python's native round() function, and has maintained the ability to use precision as an input parameter.
  • drop_nulls logic has also been preserved in such a way that it happens during string formatting, thus the removal of remove_exponents() function which is unneeded with the current changes.
  • prettify() logic remains untouched

How was this PR tested?

  • Ran series of millify() calls on numbers with known bugged outputs, and verified they now round up as intended.
  • Ran series of millify() calls on non-bugged numbers to verify they still work as intended, toggling the various outputs and testing those as well
  • NOTE: using a precision= value of 3 or higher still produces 1000.000k instead of 1.000M. However, it's in my personal opinion that, when using this module, users shouldn't need/want more than two decimal places showing in their string output anyway. If these changes are accepted, this note should probably go in the README / patch notes. Further, if anyone can figure out how to preserve the correct millname while using a precision value of 3 or higher, I haven't been able to yet but am open to all ideas!

Related Ticket

  • Closes 999999 returns 1000k #1
  • NOTE: not sure how versioning works for this project, but I've left version = 0.1.1 as-is in this PR. Should these changes be accepted, you can determine if this needed versioned up to 0.1.2 or left alone! Thanks for reading, and kind regards!

Screenshots

  • before (with bug):
    Screen Shot 2021-06-17 at 1 49 20 PM
  • after (bug fixed):
    Screen Shot 2021-06-17 at 1 51 17 PM

@weefatboi
Copy link
Author

Open to any / all feedback or edits from you! I love this module and use it heavily in my projects, so I appreciate your consideration.

Gordon Wall added 2 commits July 8, 2021 10:26
n < 1000 was skipping While block and showing many decimals, if input had many decimals.
@MitchAngenent
Copy link

@azaitsev, could you please consider merging this PR and deploying a new version of millify on PyPI? I would like to use this improved version of millify, but my organization requires packages (and their updates) to be on PyPI.

@azaitsev
Copy link
Owner

@MitchAngenent sorry, missed this PR. I think we need to add some tests before merging.

@MitchAngenent
Copy link

Hi @azaitsev, I created unit tests that test @weefatboi's work, and the existing functionalities. See PR #3. Could you please look into this PR, and if agreed, merge it and publish a new version of millify to PyPI?

@vinanrra
Copy link

@azaitsev Any news about this?

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.

999999 returns 1000k
4 participants