Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/kaiosilveira/hacker-rank-challenges

An aggregator of my completed code challenges in Hacker Rank, containing detailed explanation, benchmarking, time complexity analysis, and thorough testing
https://github.com/kaiosilveira/hacker-rank-challenges

code-challenges hacker-rank-solutions ruby time-complexity-analysis time-complexity-visualization

Last synced: 28 days ago
JSON representation

An aggregator of my completed code challenges in Hacker Rank, containing detailed explanation, benchmarking, time complexity analysis, and thorough testing

Awesome Lists containing this project

README

        

[![Continuous Integration](https://github.com/kaiosilveira/hacker-rank-challenges/actions/workflows/ruby.yml/badge.svg)](https://github.com/kaiosilveira/hacker-rank-challenges/actions/workflows/ruby.yml)

# Problem-solving

This repository is an aggregator of my solutions to code challenges. Inside each solution you will find:

- a main file for the challenge, which contains the samples and the challenge execution (`index.rb`)
- the challenge wrapper, with constraint validations (`challenge.rb` + `challenge.spec.rb`)
- the underlying algorithm used to solve the challenge (`algorithm.rb` + `algorithm.spec.rb`)
- a benchmark of the results (`benchmarking.rb` + some CSVs with benchmark output)
- a `README.md` file with a detailed explanation of the code implemented

## Programming language choice ๐Ÿ‘จ๐Ÿฝโ€๐Ÿ’ป

Because of its simplicity, elegance and API completeness, Ruby was the chosen programming language to implement the code for the challenges.

### Available tasks โš™๏ธ

- `rake test`: run all unit tests from all files
- `rake create_challenge'[challenge_name]'`: create a new directory with the default structure for a challenge

## Testing & Continuous integration ๐Ÿงช

Each challenge contains a unit test suite covering the constraints described by the challenge itself, at least one happy path, and sometimes some interesting particular cases.

The built-in `test/unit` test framework was used to implement the test suites, as no external dependency will be needed.

**Continuous integration**

A simple CI pipeline was put in place to execute the tests for each directory inside this repo. It sets up Ruby and runs the tests. This happens for every push to `main`. The config is:

```yml
name: Continuous Integration

on:
push:
branches: ["main"]

jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
ruby-version: ["2.6"]

steps:
- uses: actions/checkout@v3
- name: Set up Ruby
uses: ruby/setup-ruby@v1
with:
ruby-version: ${{ matrix.ruby-version }}
bundler: "Gemfile.lock"
bundler-cache: true
- name: Lock bundle
run: bundle lock --add-platform x86_64-linux

- name: Run tests
run: bundle exec rake
```

See [ruby.yml](./.github/workflows/ruby.yml) for the actual file.

## Benchmarking โฐ

To benchmark the code execution, the [benchmark](https://github.com/ruby/benchmark) gem was used. A [benchmarking.rb](./_utils/benchmark.rb) module was created to abstract the setup for the benchmarking, allowing the client code to call it passing a reference to the function to be executed and some more configuration parameters. The `Benchmarking` module also aggregates the value of `n` and the time it took to run the function for each execution and gives it back to the client code, so it can store the results and perform the graphical analysis later. See below an example of the benchmark in action:

```console
โžœ ruby ./left-rotation/benchmarking.rb
n = 0 0.000011 0.000003 0.000014 (0.000011)
n = 1 0.000003 0.000001 0.000004 (0.000003)
n = 2 0.000004 0.000001 0.000005 (0.000005)
n = 3 0.000003 0.000000 0.000003 (0.000004)
n = 4 0.000003 0.000000 0.000003 (0.000003)
n = 5 0.000003 0.000001 0.000004 (0.000003)
n = 6 0.000005 0.000001 0.000006 (0.000005)
n = 7 0.000003 0.000000 0.000003 (0.000004)
n = 8 0.000004 0.000002 0.000006 (0.000004)
n = 9 0.000003 0.000001 0.000004 (0.000003)
n = 10 0.000005 0.000001 0.000006 (0.000005)
```

## Time complexity ๐Ÿ“ˆ

The time complexity is calculated for each challenge, using the [Big O](https://en.wikipedia.org/wiki/Big_O_notation) notation. Common time complexities are:

- Constant: $O(1)$
- Linear: $O(n)$
- Quadratic: $O(n^2)$

The experiment to calculate the time complexity for each challenge is an exercise of using all possible values described in the **Constraints** section of the challenge at Hacker Rank, always with an eye on the term that varies the most and could cause the biggest impact on the code execution. The analysis is performed on the dump generated by the benchmark process described above.

For each challenge, a chart was created to allow us to visually identify the time complexity for the solution. The [YouPlot](https://github.com/red-data-tools/YouPlot) gem was used to create the charts from the command line. See below some examples of generated charts:

- Constant time complexity $O(1)$:

```console
โžœ cat ./cat-and-mouse/results.csv | uplot line -d, -w 50 -h 15 -t Results --canvas ascii --xlabel n --ylabel "T(n)"
Results
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
0.02 โ”‚ โ”‚
โ”‚ โ”‚
โ”‚ โ”‚
โ”‚ โ”‚
โ”‚ โ”‚
โ”‚ โ”‚
โ”‚ โ”‚
T(n) โ”‚ | โ”‚
โ”‚ . | โ”‚
โ”‚ | | โ”‚
โ”‚ | . | โ”‚
โ”‚ | | | โ”‚
โ”‚ . ,. | | | โ”‚
โ”‚ | . , || | | | โ”‚
0 โ”‚@@_11___]_L1__1___________]____]___L_________]____โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
0 1000000
n
```

- Linear time complexity $O(n)$:

```console
โžœ cat ./left-rotation/results.csv | uplot line -d, -w 50 -h 15 -t Results --canvas ascii --xlabel n --ylabel "T(n)"
Results
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
0.02 โ”‚ โ”‚
โ”‚ โ”‚
โ”‚ โ”‚
โ”‚ โ”‚
โ”‚ , โ”‚
โ”‚ /\โ”‚
โ”‚ . |โ”‚
T(n) โ”‚ .r./""` โ”‚
โ”‚ __/"` โ”‚
โ”‚ ._.--"`-/ โ”‚
โ”‚ _.--` โ”‚
โ”‚ r/""" โ”‚
โ”‚ .r""/" โ”‚
โ”‚ _.__--""` โ”‚
0 โ”‚__--" ` โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
0 100000
n

```

- Quadratic time complexity $O(n^{2})$:

```console
โžœ cat ./electronic-shops/results.csv | uplot line -d, -w 50 -h 15 -t Results --canvas ascii --xlabel n --ylabel "T(n)"
Results
โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
5 โ”‚ ./ โ”‚
โ”‚ .r` โ”‚
โ”‚ .` โ”‚
โ”‚ ./ โ”‚
โ”‚ ./ โ”‚
โ”‚ ./` โ”‚
โ”‚ ./` โ”‚
T(n) โ”‚ .r" โ”‚
โ”‚ ./` โ”‚
โ”‚ ./` โ”‚
โ”‚ _-" โ”‚
โ”‚ _-" โ”‚
โ”‚ _r/" โ”‚
โ”‚ ._r-/" โ”‚
0 โ”‚_____.--/"` โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜
0 10000
```