Strip out any functionality that is no related to coursework?

[kgiray]

Hi, can we strip out any functionality not related to the battery of tests given in the coursework? Some examples that come into my mind are the if statements to check whether to read from a file or a generator, or for loops around the number of trials per test, which are redundant as by default each test runs once and the workload does not overwrite this as far as I can see.

[jeg114]

Possibly same issue as #23. Was wondering the same and find the documentation slightly ambiguous about this since it states that:

The goal of this coursework is to take an existing library called TestU01, and parallelise, optimise, or otherwise accelerate it.

Which I would understand as, no the whole functionality should still be there. But also

Your goal is to optimise the TestU01 library with three use-cases in mind (or two for a pair):

In which case if the three use cases remain equally functional it should be fine?

[m8pple]

Generally speaking the order of preference for this sort of activity is:

1 - Maintain existing functionality and existing API, with the same functions. In some cases this will make optimisation more difficult, but mainly it just makes it more complicated to read and maintain. It makes for the most maintainable library though, as there is no code duplication.

2 - Maintain existing functionality and existing API, but divert internally to special-case functions. For example, when Crush is called, you check that forall i: nreps=1, then divert to something internally called parallel_Crush that only supports that special case.

3 - Maintain existing functionality but add a new API just for the drivers. For example, you might add a new library API function called bbattery_SmallCrushStress, which is specialised for that use-case, but does not interfere with (nor accelerate) any other calls to bbattery_SmallCrush.

4- Remove existing functionality. You could strip out all code not exercised by the use-case, and just let it crash if it is not on a path exercised by the drivers.

All of those are legitimate for this coursework, including the last one. However, option 4 means that any optimisations are useless for future users of TestU01, so couldn't be published or used by others. That isn't really your aim in this coursework, so feel free to ignore it in the interests of time, but it would be nice if some of the approaches taken by students could be opened up to other researchers (ahem, and I want to use it).

Personally I took option 2, as I dislike modifying in-place, and prefer to divert to specialised copies of the functions, with extremely tight pre-conditions on when that optimised version will kick in. That version of the function can then be completely stripped back.

So the overall answer is: yes, you can do whatever you want to TestU01 as long as the use-cases run. But... it would be nice if the remaining library still worked as much as possible, as it sort of marks the difference between being an assessment for assessments sake, and doing an authentic piece of engineering practise that happens to also be assessed.