Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

two-bucket: incorrect test case in canonical data? #911

Closed
cmccandless opened this issue Sep 22, 2017 · 3 comments
Closed

two-bucket: incorrect test case in canonical data? #911

cmccandless opened this issue Sep 22, 2017 · 3 comments

Comments

@cmccandless
Copy link
Contributor

According to the [README] for the exercise, valid moves include:

pouring from one bucket to another
emptying one bucket and doing nothing to the other
filling one bucket and doing nothing to the other

The only other restriction stated is

That means, when starting with the larger bucket full, you are NOT allowed at any point to have the smaller bucket full and the larger bucket empty (aka, the opposite starting point)

In other words, if one bucket is full, and the other empty, the full bucket must be the starting bucket.

The last test case description says "Measure using bucket one of size 2 and bucket two of size 3 - start with bucket one and end with bucket two"

With the above rules, what disqualifies the following from being a valid solution for the above test case?
(2 moves): (fill first bucket, as directed) [2, 0] -> (fill second bucket) [2, 3]

@petertseng
Copy link
Member

I see nothing that disqualifies the proposed two-move solution.

I didn't see any rule that requires that you can only pour water into the start bucket, which is a possible reason one would expect a four-move solution.

@Insti
Copy link
Contributor

Insti commented Sep 23, 2017

The goal is 3 litres.

what disqualifies the following from being a valid solution
(2 moves): (fill first bucket, as directed) [2, 0] -> (fill second bucket) [2, 3]

Don't you have 5 litres at this point?
By emptying the first bucket do you violate the "opposite starting point" constraint?

@cmccandless
Copy link
Contributor Author

There is no requirement for the other bucket to be empty. In fact, if you look at the other test cases, you'll find it is almost never so. The 3L goal only applies to one bucket.

cmccandless added a commit to cmccandless/problem-specifications that referenced this issue Oct 10, 2017
Insti pushed a commit that referenced this issue Oct 10, 2017
* two-bucket: fix incorrect test case

Resolve #911

* two-bucket: update canonical data version
petertseng added a commit to exercism/rust that referenced this issue Nov 20, 2018
)

Note that two-bucket was added to the Rust track at
#375
At the time it declared 1.0.0 compliance, but was actually compliant
with 1.2.0 already!

Further updates to 1.3.0 and 1.4.0 require no action on the Rust track's
part.

1.0.1: Fix exercise name
exercism/problem-specifications#715

Unversioned(!): Change descriptions
exercism/problem-specifications#716
(Our descriptions are no better or worse, so might as well keep them)

1.1.0: Add cases where goal equals one bucket's capacity
exercism/problem-specifications#763
Rust already had these cases, so just update the descriptions

1.2.0: Fix a test case added in 1.1.0
exercism/problem-specifications#911
exercism/problem-specifications#941
Rust already had the correct values, so no action.

1.3.0: move inputs to `input` object
exercism/problem-specifications#1084

1.4.0: rename JSON keys to camelCase
exercism/problem-specifications#1136
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants