Thanks, fixed.

It can be easily done without exceeding BigInt size. I don't think randomising the length increases the complexity in any way - it's still just one check.
I have added an explicit max length of input data(64 bits) to simplify things. Sadly, I don't see any way to easily get the max value of BigInt so this will have to do.

JS: it doesn't make much sense to have a single fixed test where calculations may exceed the maximum BigInt size. Easy to hardcode (see my solution). Either make random tests generate such occurences, but that would make the kata significatively harder compared with other languages, or just remove it.

Javascript: export in initial code makes the program crash.

Thanks for the comment, I've updated the tests.
I've left full length and partial length as they were. 'partial length' means some bits may be trimmed from most significant bit's side, 'full length' means no bits trimmed.

Decimal offsets are more readable than hexadecimal ones.

[Python]

• In python "full length" and "partial length" don't make sense, "offet with sign bit set" is simply 4026531840 (without sign bit).

• Tests import solution but use extract_bit. Use either import solution / solution.extract_bits or from solution import extract_bits / extract_bits.

• No random tests.

I solved this kata, but can anyone tell me what theorems from mathematics or algorithms will help to solve this problem more efficiently?

++

Helper method makes debugging much nicer. Great kata!

Thanks, I've updated the description.

👍

New tasks are only put into the queue when they arrive. You cannot predict the future, so this cannot be done before their arrival time.

At t = 0: The queue is [], running task0

At t = 2: task1 arrives, the queue is [task1]

At t = 3: window finishes but task0 is not done yet, put task0 at the end; task1 is now executed, the queue is [task0]

At t = 4: task2 arrives, the queue is [task0, task2]

At t = 6: window finishes but task1 is not done yet, put task1 at the end; task0 is now executed, the queue is [task2, task1]

...

I would like an explanation/clarification for the DifferentStartTimes test:

public void DifferentStartTimes()
    {
        var startTime = new DateTime(2007, 11, 5);
        var tasks = new List<Job>() {
          new Job(Guid.NewGuid(), startTime, TimeSpan.FromSeconds(5)),
          new Job(Guid.NewGuid(), startTime + TimeSpan.FromSeconds(2), TimeSpan.FromSeconds(5)),
          new Job(Guid.NewGuid(), startTime + TimeSpan.FromSeconds(4), TimeSpan.FromSeconds(5)),
        };

        var schedule = RoundRobinScheduler.CreateSchedule(startTime, TimeSpan.FromSeconds(3), new List<Job>(tasks));

        Assert.That(schedule.Count, Is.EqualTo(6));
        Assert.Multiple(() =>
        {
            Assert.That(schedule[0], Is.EqualTo(new Timeslot(tasks[0].Name, TimeSpan.FromSeconds(3), TimeslotType.Job)),"Timeslot 0");
            Assert.That(schedule[1], Is.EqualTo(new Timeslot(tasks[1].Name, TimeSpan.FromSeconds(3), TimeslotType.Job)),"Timeslot 1");
            Assert.That(schedule[2], Is.EqualTo(new Timeslot(tasks[0].Name, TimeSpan.FromSeconds(2), TimeslotType.Job)),"Timeslot 2");
            Assert.That(schedule[3], Is.EqualTo(new Timeslot(tasks[2].Name, TimeSpan.FromSeconds(3), TimeslotType.Job)),"Timeslot 3");
            Assert.That(schedule[4], Is.EqualTo(new Timeslot(tasks[1].Name, TimeSpan.FromSeconds(2), TimeslotType.Job)),"Timeslot 4");
            Assert.That(schedule[5], Is.EqualTo(new Timeslot(tasks[2].Name, TimeSpan.FromSeconds(2), TimeslotType.Job)),"Timeslot 5");
        });
    }

After doing task 0 and task 1, it is now startTime + 6 seconds.

However, after running their timeslots, tasks 0 and 1 are at the end of the job list. So task 2 is next on deck.

Since task 2's arrival time is startTime + 4 seconds, which is less than the current time after the first two timeslots, why can't we run it instead of running task 0 again?