New exercise idea: Unit conversions about julia HOT 2 OPEN

Input range problem

I think it's important to decide the structure of the underlying graph. Will it have one or more cycles? Will it have multiple connected components? Should the solution accept units not given in the graph?

My personal pick would be no cycles and single connected component. The main reasons are:

• The solution is guaranteed to be unique as long as both units exist in the graph
  • If there is a cycle and the cycle's product is different from 1, there are infinitely many possible answers
  • If there are multiple connected components, no solution is possible even if both units are present
  • For the single kind of measure (in this case, length), this is closest to real-life scenarios (IMO)
• The amount of conversions is fixed, unless an edge is traversed back and forth

Missing conversions might be fine, as many languages can handle it by null values or option types.

Handling rounding errors in test cases

This is usually done using absolute/relative error margin. For this particular problem, relative error should be sufficient since 1) all input/output/intermediate values must be positive and 2) only multiplication and division are used. The test roughly looks like this:

# test if `actual` is close to `expected` within `threshold` (relative error)
assert (1 - threshold) * expected <= actual <= (1 + threshold) * expected
# test if `actual` is close to `expected` within `threshold` (absolute error)
assert expected - threshold <= actual <= expected + threshold

Common choice of threshold is 1e-6.

(Another option would be to return the sequence of units involved in the conversion, though it slightly obscures the intent of the problem.)

Input format

The most sensible choice would be a list of triples [unit_from, unit_to, ratio], presented in the most natural data type for each language.

Modeling vs. Implementation

My position is slightly towards modeling rather than implementation. Students are free to use an existing library or solve without one, and IMO neither should be considered superior to the other.

from julia.

I think it's important to decide the structure of the underlying graph. Will it have one or more cycles? Will it have multiple connected components? Should the solution accept units not given in the graph?

I don't like forcing a certain implementation/model upon the student, so I don't think that's something we have to decide.

However, test cases could be arranged in increasing complexity, e.g. the first tests have input that can be followed linearly to convert the units, then more complex test inputs for a more "realistic" exercise.

My personal pick would be no cycles and single connected component.

I feel like if this was a "real world" problem, cycles would be rather common in input data, so I'm not sure I agree on not having them, at least for more complex test cases.

A single connected component seems fine to me to keep the exercise simple. If a student solves that case, they're probably "fluent" enough to adapt it to handle multiple components anyway.

The most sensible choice would be a list of triples [unit_from, unit_to, ratio], presented in the most natural data type for each language.

For easier testing across tracks, it might be useful to store them in a simple text file and then provide the student with a parser in the stub files or generate the representation in code from that.

I'll put together an example implementation and some tests in Julia in the next few days.

from julia.