After some investigation and re-reading what g964 was getting at - I've learned the solution is correct and consistent. Previously I was using format but on a cast, not leveraging actual formatted display of floats. (I knew I was doing something foolish)

For those stuck on this, scratching their heads - I would encourage you to read up on this:
https://users.rust-lang.org/t/formatting-floats-and-rounding/10235

Thank you for the kata, I learned something new.

I am still confused, inspite of your thorough description.
One of the basic tests is as follows; the raw sell value is 6407.6, but 6408 is expected?

l = "GOOG 90 160.45 B, JPMC 67 12.8 S, MYSPACE 24.0 210 B, CITI 50 450 B, CSCO 100 55.5 S";
sol = "Buy: 14440 Sell: 6408; Badly formed 2: MYSPACE 24.0 210 B ;CITI 50 450 B ;" ; //raw sell value is 6407.6; not truncated
do_test(l, sol);

This lead me to round, in spite of the instructions. Afterwhich I was met with this random test:

l = "CAP 15 89.3 S, APPL 67 45.5 B, CLH16.NYM 24.0 5.5 P, CITI 50 450 S";
sol = "Buy: 3048 Sell: 1340; Badly formed 2: CLH16.NYM 24.0 5.5 P ;CITI 50 450 S ;"; //Raw buy value is 3048.5; raw sell value is 1339.5
do_test(l, sol);

These values seem to be rounded (inconsistently) as well, not trucated.

Perhaps (most likely), I'm doing something foolish here. Any insight would be appreciated, as I've attempted format! and write! as well as rounding to no avail.

Thank you.

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

Anyway, it should have been std::span if C++20 was available here.

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 copy the whole input vector by accepting it by value, this one doesn't.

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).

I am not the Rust translator but I have fixed it. Thanks!

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.

What you can do, is to add such test case to sample tests. It will help to verify the solution early.

Good idea, done in all translations. Thanks!

This can still be a little bit tricky

I agree, kata with double or float are often tricky since different languages can have different ways of formatting. I can be wrong but I think part of the fun is finding your way to a solution that is accepted by the tests.
Moreover in this kata many people have problems with the placement of white spaces all the more that CW output compresses many spaces into one.
In my previous post I answered about Rust but as far as I know all 24 translations (there are several translators) give the same results with fixed tests.
Anyway thank for your post.

This can still be a little bit tricky, because

• formatting of fractions can differ between languages. You can say "use default formatting of your language", but...
• ... there might be no default. Library of one language can format doubles with another rounding mode than decimals than money type. Now you have to specify that user has to use double, and using decimal is wrong for this kata (even if it's not wrong in general).

I am not taking any position here and I am not fighting for any specific approach, I just want to show that there can, and will, be some some problems whatever you decide :)
What you can do, is to add such test case to sample tests. It will help to verify the solution early.