Sublist type clarification

[sachpatel]

One of the test cases on in the sublist exercise relates to verifying 'huge sublist not in huge list'.

Maybe the way I have implemented the rest of the functionality for the exercise is not optimal but my solution of traversing a list to verify a sublist makes this test very slow. I did not impose the restriction of the lists being lists of numbers. If I made the exercise treat only numbered lists I believe writing a more optimal check for this test case would be easier.

Would it make sense therefore to specify that this exercise should be for dealing with numbered lists only?
I know the README has examples showing numbered lists but following the list-ops exercise I thought this sublist exercise should be for lists of any type until I hit this particular test case.

[NobbZ]

As long as your language does allow to do the exercise on a generic list
type you should be able to also restrict it to items which are comparable
by equality. So I do not see anything that makes the test case easier when
specializing the list to a certain type. But maybe it would be a little bit
more easier to reason when we knew which track you have this feeling.
Am 14.07.2016 11:16 schrieb "Sachin Patel" notifications@github.com:

One of the test cases on in the sublist exercise relates to verifying
'huge sublist not in huge list'.

Maybe the way I have implemented the rest of the functionality for the
exercise is not optimal but my solution of traversing a list to verify a
sublist makes this test very slow. I did not impose the restriction of the
lists being lists of numbers. If I made the exercise treat only numbered
lists I believe writing a more optimal check for this test case would be
easier.

Would it make sense therefore to specify that this exercise should be for
dealing with numbered lists only?
I know the README has examples showing numbered lists but following the
list-ops exercise I thought this sublist exercise should be for lists of
any type until I hit this particular test case.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#293, or mute the thread
https://github.com/notifications/unsubscribe/AADmR01aCszKuDvVFfK3vIGbnlHbFFyAks5qVf6JgaJpZM4JMPCB
.

[sachpatel]

On the Elixir track. Could just be that I have not thought through the different ways to verify if a large candidate sublist is in a large list.

I agree the exercise should be able to operate on lists of any type that allows comparison through equality.

[IanWhitney]

Alternate thought: remove the large sublist test.

Our test suites are unit tests. And the large sublist test isn't there as a unit test, it's there as a performance test. We talked about this recently in a Rust PR: exercism/rust#147 (comment)

Edit: And in Rectangles exercism/rust#165 (comment)

[sachpatel]

I found my solution was not performing well and for the said test case would take a very long time. I do not believe removing the test case is a very good idea. Instead I will rewrite my solution to be more optimised.

My original solution is here: http://exercism.io/submissions/130efb6e87b841caa4c8fbbe0dfe1a7c

[petertseng]

Well, the large sublist test was not added in #227, and it is true that the data only deals with numbers. If a note should be added about generics, let's open an issue about that. For any tracks that still test large sublists, discussion should happen in those specific tracks about whether they should be kept.