Changing the return type to long is insufficient, but required. (unless you're really lucky with tests?)
You must also cast the long to int, as some random tests expect the overflow value.

The c# solution is currently not solvable without this realization.

Me too number=6462745976994925
f(k,b)=6462745976994924

Expected: 186268, instead got: 6462745976994924

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.

With n = 15705261201683973613 Expected 15705261201683973612 but got 83
83 is the correct answer. The random tests seem to break when the base is near 80. (I got another error where I got 84 for the base on a large number, but I did not write it down).

#[test]
fn fail12() {
dotest( 15705261201683973613, 15705261201683973612 )
}

Thanks, this was a blast!
Bobby tables would approve.

This is an existing problem documented (much better) by iago.passos. Marking as resolved to avoid duplicated issues.

I may be mistaken, but it appears the rust solution has some issues.
A portion of the tricky tests return the following error:
With n = 17700847248605297701
Expected 17700847248605297700 but got 84 at src/lib.rs:50:9

I believe 17700847248605297701 in base 84 is correct:
1:1:1:1:1:1:1:1:1:1:1_84 (11 digits), meaning the accepted solution (perhaps sometimes) returns n-1 in cases which it should not.

finally got it!

Approved

👍

Looking good now. One final nitpick, then we can approve this sucker:

The assertion messages, in combination with the default output of assert_eq!, have redundant information in them. The default message already has the values in it (left = x, right = y), so including actual and expected again in your message doubles this and makes them rather noisy.

Either only include "your result (left) did not match the expected output (right)", or change the macro to assert!(actual == expected, ...message), because the latter does not print what the actual values were.

I was so focused on maintaining consistency across the different parts of the kata in the series, I misinterpreted your first point.
I've updated accordingly.

As an aside, I did end up making the input i32, not u32 - as traversing negative heights (valleys) should behave the same. The output is u32 as you recommended, as that should never be negative.

I'm wrong, the kata defines heights as 0-9, so I shall make it unsigned.

Now I'm a bit confused. You changed the field generation to a vec of vec of i32, but then you just go ahead and convert that into a string?

My point was to eliminate strings alltogether and change the user function to accept a &[Vec<i32>], not a &str. I.e. the function set_area_string is superfluous.