alternate implementation, support decimals, extra tests, benchmarking #7
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I recently needed a library to add commas to numbers and I found your library helpful. Thank you.
I ran into trouble with numbers which had decimal values. So, I've written an alternate implementation which supports decimal values and custom decimal characters for internationalization.
I added tests for decimals and custom decimal characters as well as changed them to use unique digits instead of lots of zeroes (because one bug I had grabbed the wrong part but still worked because flipping around all zeroes was still producing the correct result...).
I also added a benchmark script (using BenchmarkJS) which can be used to compare the previous implementation with the newer implementation. Before changing the current implementation during development, copy it to
benchmark/original.js
. Then, it's possible to benchmark that version against new changes.Run the benchmark via
node benchmark/run.js
. I didn't add an npm run script topackage.json
because I'm not sure if you'd like it there or not, or if you'd like to add other scripts. If you'd prefer, I could add one named "benchmark" to run the script. Up to you.The
benchmark/original.js
file currently has the v1.1.0 implementation. So running the benchmark compares that with my alternate implementation. The image below shows the comparison when run on my dev machine. The first few results of each group are a lot faster because the new implementation takes a shortcut when the number isn't large enough to need separators.The speed improvement for the rest of the results are due to avoiding the split/reverse/join operations and instead splitting the
stringNumber
into groups of 3 digits from where the first separator should be.So, this PR provides:
Please let me know if you're interesting in accepting this PR and if you'd like me to revise it before the merge.
Thank you