refactor: cleanup CountingSort - #5275

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 40.52%. Comparing base (f83bb65) to head (4d7e8b5).

@@             Coverage Diff              @@
##             master    #5275      +/-   ##
============================================
+ Coverage     40.34%   40.52%   +0.18%     
- Complexity     2486     2500      +14     
============================================
  Files           519      521       +2     
  Lines         15479    15483       +4     
  Branches       2950     2954       +4     
============================================
+ Hits           6245     6275      +30     
+ Misses         8944     8916      -28     
- Partials        290      292       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Hello @vil02 . Could you please advise on how to handle the Pseudo Counting Sort classes? To preserve the integrity and original purpose of this repository, it might be best to remove them since they do not actually implement Counting Sort. However, they have been part of the repository for some time, and I'm unsure of the best course of action.

@alxkm: I would suggest to remove them. I would guess, the original implementation was merged by accident. Introducing some QuasiPseudoAlmostCountingSort does not make much sense: it does not have any special properties.

Therefore I suggest to:

• remove these classes (with this PR, or close this one and open a new one; from documentation point of view the second option is better),
• implement a proper CountingSort (i.e. only nonnegative integers as an input) in a new PR.

In any case: thanks to you we have spotted a quite serious bug!

@alxkm: I would suggest to remove them. I would guess, the original implementation was merged by accident. Introducing some QuasiPseudoAlmostCountingSort does not make much sense: it does not have any special properties.

Therefore I suggest to:

• remove these classes (with this PR, or close this one and open a new one; from documentation point of view the second option is better),
• implement a proper CountingSort (i.e. only nonnegative integers as an input) in a new PR.

In any case: thanks to you we have spotted a quite serious bug!

Ok, thank you. Got it. This is really proper way to resolve this issue

This implementation of CountingSort is wrong. Because it works only using TreeMap, which causes wrong asymptotic for CountingSort.

This issue will be resolved in such way:

• Removing existed Counting sort in separate PR
• Add correct implementation for Counting Sort (this is already exist in this pull request)

All these discussed in this PR