I'm not sure how to answer this, other than to say they did.
(edit) It's been a few months since I solved this, I see your objection now. I believe I solved this assuming all shoe sizes (per foot) were distinct. Reviewing my solution, this is not a safe assumption and adding tests with duplicated sizes may aid in weeding out false positive solutions.
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.
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)
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.
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).
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.
yes, funny, there are also no invalidatet solutions for this kata.
I'm not sure how to answer this, other than to say they did.
(edit) It's been a few months since I solved this, I see your objection now. I believe I solved this assuming all shoe sizes (per foot) were distinct. Reviewing my solution, this is not a safe assumption and adding tests with duplicated sizes may aid in weeding out false positive solutions.
This solution is displayed at the top when sorting by newest. I would just be curious how this solution could pass tests.
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.
This comment is hidden because it contains spoiler information about the solution
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?
This lead me to round, in spite of the instructions. Afterwhich I was met with this random test:
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
👍
Loading more items...