brick_sort implemented

[HarsheetKakar]

References to other Issues or PRs or Relevant literature

#129

Brief description of what is fixed or changed

Other comments

[codecov]

Codecov Report

Merging #207 into master will increase coverage by 0.027%.
The diff coverage is 100.000%.

@@              Coverage Diff              @@
##            master      #207       +/-   ##
=============================================
+ Coverage   96.897%   96.924%   +0.027%     
=============================================
  Files           24        24               
  Lines         1934      1951       +17     
=============================================
+ Hits          1874      1891       +17     
  Misses          60        60               

Impacted Files	Coverage Δ
pydatastructs/linear_data_structures/__init__.py	100.000% <ø> (ø)
pydatastructs/linear_data_structures/algorithms.py	100.000% <100.000%> (ø)

[HarsheetKakar]

so is it ready to merge now? @czgdp1807

[czgdp1807]

so is it ready to merge now? @czgdp1807

Tests should be updated. Common tests should be used for all sorting algorithms. The function, test_merge_sort_parallel can be renamed to _test_common_sort(sort_func) and test_merge_sort_parallel and test_brick_sort should call them from inside, like,

def test_merge_sort_parallel():
    _test_common_sort(merge_sort_parallel)

[HarsheetKakar]

so is it ready to merge now? @czgdp1807

Tests should be updated. Common tests should be used for all sorting algorithms. The function, test_merge_sort_parallel can be renamed to _test_common_sort(sort_func) and test_merge_sort_parallel and test_brick_sort should call them from inside, like,

def test_merge_sort_parallel():
    _test_common_sort(merge_sort_parallel)

sure sounds good, and while we are at it I also feel that we should put the algorithms under their own module.

[czgdp1807]

Or testing function for parallel and non parallel algorithms can be separated(array(s) used in testing should be same, only num_threads needs attention). I hope you are getting my point.

[czgdp1807]

while we are at it I also feel that we should put the algorithms under their own module.

Well, every algorithm.py file under different modules contains algorithms for the data structure represented by that module. This helps in keeping things specific for each module. Every algorithm is under global namespace so not a big issue.

[HarsheetKakar]

Or testing function for parallel and non parallel algorithms can be separated(array(s) used in testing should be same, only num_threads needs attention). I hope you are getting my point.

I get it, and I have felt the same while I was working on it... so this is the proposal:

pydatastructs

algorithms

sequential

tests

concurrent

tests

[czgdp1807]

I get it, and I have felt the same while I was working on it... so this is the proposal:

Every parallel algorithm has _parallel appended to it, so putting them under different module isn't really useful . Though our current classes may not work with parallel algorithms through processes because sharing user defined objects among processes is not possible with python. A _to_python_object method can be introduced in every class to support that. Opening a separate issue for this.

[HarsheetKakar]

Or testing function for parallel and non parallel algorithms can be separated(array(s) used in testing should be same, only num_threads needs attention). I hope you are getting my point.

take a look at it please.