I like this because it does integer division, not float division.

That's fair - I didn't even notice the const& - but you can also move into it when it's by value, not just copy. You can't move with this signature (and thus you are forced to do a heap allocation). And I would think that we should stick with the signature that is given.

Other solutions reuse the parameter vector instead of creating a new one, avoiding a heap allocation. It seems like this shouldn't be at the top.

Considering the return type is unsigned int, you should use an unsigned int for the running sum, as it (normally) has a greater range of values than int. And signed integer overflow is undefined behavior. Unsigned integer overflow isn't - you could safely overflow and underflow and still arrive at the correct answer as long as it fits in unsigned int.

m_actualTimeUs can still overflow, leading to incorrect behavior. Granted, it would take over 500,000 years for it to happen...

The problem statement asks for an O(1) space solution, but this is O(n).

In Rust, the random tests may have any of g, v1 and v2 equal to 0.

It's not a big deal, but it is not consistent with what is said in the instructions.

You are right, it's not quite an inconsistency. In that case, I suppose the issue I'd like to raise is that, like you said, the instructions should be explicit about the rounding method.

I am getting some inconsistent rounding in the random tests in Rust when the fractional parts are 0.5.

Here are two examples:

GOOG 90 160.45 B, JPMC 67 12.8 S, MY SPACE 24.0 210 B, CITI 50 450 B, CSCO 100 55.5 S expects Buy: 14440 Sell: 6408; Badly formed 2: MY SPACE 24.0 210 B ;CITI 50 450 B ;. The total buy amount is 14440.5 and 14440 is what is expected (rounds down).

BoAML 15 55.5 S, APPL 67 34.8 B, GOOG 12 45.5 B, CLH16.NYM 90 5.5 S, CITI 45 210 S expects Buy: 2878 Sell: 1328; Badly formed 1: CITI 45 210 S ;. The total sell amount is 1327.5 and 1328 is what is expected (rounds up).

I'm pretty sure the expected answers aren't being generated correctly.

In Rust, there is no test case covering potential arithmetic overflow issues that are present in most accepted solutions. I think such a test case should be added or the instructions should be explicit about the range of the input numbers.

Such a test case might be something as simple as [-128, 127] with target 0.

I wanted to make mem (to memoize results) static/global but I couldn't get past compiler errors saying a static variable couldn't be mutable and I couldn't use function calls (such as HashMap::new()) to initialize static variables.

I'm having some trouble understanding this one... What's sub's m parameter meant to represent?

I couldn't find a way to define a check function or closure that would both take an iterator (requires generic type parameters - can't use closures) and capture n from the environment (need closures) so I wouldn't have to pass it as a parameter every time.