Python code to check if an array has a sequence (1,3,4)
$begingroup$
I recently applied for a job as a Python coder but was rejected.
This was the problem:
Write a python code to check if an array has a sequence (1,3,4)
Assuming they were looking for expert Python programmers, what could I have done better?
# Tested with Python 2.7
import unittest
# Runtime: O(n)
def doesSeqAppear(int_arr):
#check if input is a list
if not isinstance(int_arr, list):
raise TypeError("Input shall be of type array.")
# check all elements are of type int
if not all(isinstance(item, int) for item in int_arr) :
raise ValueError("All elements in array shall be of type int.")
arr_len = len(int_arr)
if arr_len < 3:
return False
# Loop through elements
for i in range(arr_len-2):
if int_arr[i] == 1 and
int_arr[i+1] == 3 and
int_arr[i+2] == 4 :
return True
return False
class TestMethodDoesSeqAppear(unittest.TestCase):
def test_only_single_seq(self):
#Single time
assert doesSeqAppear([1,3,4]) == True
def test_multiple_seq(self):
#multiple
assert doesSeqAppear([2,2,1,3,4,2,1,3,4]) == True
def test_neg_seq(self):
#multiple
assert doesSeqAppear([9,-1,1,3,4,-4,4]) == True
def test_only_empty_seq(self):
#empty
assert doesSeqAppear() == False
def test_only_single_elem_seq(self):
#Single element
assert doesSeqAppear([1]) == False
def test_input_is_none(self):
self.assertRaises(TypeError, doesSeqAppear, None)
def test_raises_type_error(self):
self.assertRaises(TypeError, doesSeqAppear, "string")
def test_raises_value_error(self):
self.assertRaises(ValueError, doesSeqAppear, [1,2,'a', 'b'])
if __name__ == '__main__':
unittest.main()
#
python array interview-questions
$endgroup$
|
show 6 more comments
$begingroup$
I recently applied for a job as a Python coder but was rejected.
This was the problem:
Write a python code to check if an array has a sequence (1,3,4)
Assuming they were looking for expert Python programmers, what could I have done better?
# Tested with Python 2.7
import unittest
# Runtime: O(n)
def doesSeqAppear(int_arr):
#check if input is a list
if not isinstance(int_arr, list):
raise TypeError("Input shall be of type array.")
# check all elements are of type int
if not all(isinstance(item, int) for item in int_arr) :
raise ValueError("All elements in array shall be of type int.")
arr_len = len(int_arr)
if arr_len < 3:
return False
# Loop through elements
for i in range(arr_len-2):
if int_arr[i] == 1 and
int_arr[i+1] == 3 and
int_arr[i+2] == 4 :
return True
return False
class TestMethodDoesSeqAppear(unittest.TestCase):
def test_only_single_seq(self):
#Single time
assert doesSeqAppear([1,3,4]) == True
def test_multiple_seq(self):
#multiple
assert doesSeqAppear([2,2,1,3,4,2,1,3,4]) == True
def test_neg_seq(self):
#multiple
assert doesSeqAppear([9,-1,1,3,4,-4,4]) == True
def test_only_empty_seq(self):
#empty
assert doesSeqAppear() == False
def test_only_single_elem_seq(self):
#Single element
assert doesSeqAppear([1]) == False
def test_input_is_none(self):
self.assertRaises(TypeError, doesSeqAppear, None)
def test_raises_type_error(self):
self.assertRaises(TypeError, doesSeqAppear, "string")
def test_raises_value_error(self):
self.assertRaises(ValueError, doesSeqAppear, [1,2,'a', 'b'])
if __name__ == '__main__':
unittest.main()
#
python array interview-questions
$endgroup$
5
$begingroup$
Well for one, Python lists can have multiple types of values, are you sure they required each array to have all ints. For example:['a','b','c',1,3,4]seems like a valid sequence that would return false in your implementation
$endgroup$
– Navidad20
Dec 14 '16 at 14:36
$begingroup$
Maybe you should have usedxrange? ;)
$endgroup$
– Tamoghna Chowdhury
Dec 14 '16 at 14:38
1
$begingroup$
Also, they asked about an array. Maybe you should have used anumpy.arrayinstead of a list? With NumPy arrays, this could be done in 2 function calls.
$endgroup$
– Tamoghna Chowdhury
Dec 14 '16 at 14:43
3
$begingroup$
As I said in another comment, there are so many unknown points in this question that I think the main reason for rejection may actually be him making assumptions instead of asking questions.
$endgroup$
– ChatterOne
Dec 14 '16 at 15:18
$begingroup$
Why not juststr([1,3,4])[1:-1] in str([array])?
$endgroup$
– Samuel Shifterovich
Dec 14 '16 at 21:41
|
show 6 more comments
$begingroup$
I recently applied for a job as a Python coder but was rejected.
This was the problem:
Write a python code to check if an array has a sequence (1,3,4)
Assuming they were looking for expert Python programmers, what could I have done better?
# Tested with Python 2.7
import unittest
# Runtime: O(n)
def doesSeqAppear(int_arr):
#check if input is a list
if not isinstance(int_arr, list):
raise TypeError("Input shall be of type array.")
# check all elements are of type int
if not all(isinstance(item, int) for item in int_arr) :
raise ValueError("All elements in array shall be of type int.")
arr_len = len(int_arr)
if arr_len < 3:
return False
# Loop through elements
for i in range(arr_len-2):
if int_arr[i] == 1 and
int_arr[i+1] == 3 and
int_arr[i+2] == 4 :
return True
return False
class TestMethodDoesSeqAppear(unittest.TestCase):
def test_only_single_seq(self):
#Single time
assert doesSeqAppear([1,3,4]) == True
def test_multiple_seq(self):
#multiple
assert doesSeqAppear([2,2,1,3,4,2,1,3,4]) == True
def test_neg_seq(self):
#multiple
assert doesSeqAppear([9,-1,1,3,4,-4,4]) == True
def test_only_empty_seq(self):
#empty
assert doesSeqAppear() == False
def test_only_single_elem_seq(self):
#Single element
assert doesSeqAppear([1]) == False
def test_input_is_none(self):
self.assertRaises(TypeError, doesSeqAppear, None)
def test_raises_type_error(self):
self.assertRaises(TypeError, doesSeqAppear, "string")
def test_raises_value_error(self):
self.assertRaises(ValueError, doesSeqAppear, [1,2,'a', 'b'])
if __name__ == '__main__':
unittest.main()
#
python array interview-questions
$endgroup$
I recently applied for a job as a Python coder but was rejected.
This was the problem:
Write a python code to check if an array has a sequence (1,3,4)
Assuming they were looking for expert Python programmers, what could I have done better?
# Tested with Python 2.7
import unittest
# Runtime: O(n)
def doesSeqAppear(int_arr):
#check if input is a list
if not isinstance(int_arr, list):
raise TypeError("Input shall be of type array.")
# check all elements are of type int
if not all(isinstance(item, int) for item in int_arr) :
raise ValueError("All elements in array shall be of type int.")
arr_len = len(int_arr)
if arr_len < 3:
return False
# Loop through elements
for i in range(arr_len-2):
if int_arr[i] == 1 and
int_arr[i+1] == 3 and
int_arr[i+2] == 4 :
return True
return False
class TestMethodDoesSeqAppear(unittest.TestCase):
def test_only_single_seq(self):
#Single time
assert doesSeqAppear([1,3,4]) == True
def test_multiple_seq(self):
#multiple
assert doesSeqAppear([2,2,1,3,4,2,1,3,4]) == True
def test_neg_seq(self):
#multiple
assert doesSeqAppear([9,-1,1,3,4,-4,4]) == True
def test_only_empty_seq(self):
#empty
assert doesSeqAppear() == False
def test_only_single_elem_seq(self):
#Single element
assert doesSeqAppear([1]) == False
def test_input_is_none(self):
self.assertRaises(TypeError, doesSeqAppear, None)
def test_raises_type_error(self):
self.assertRaises(TypeError, doesSeqAppear, "string")
def test_raises_value_error(self):
self.assertRaises(ValueError, doesSeqAppear, [1,2,'a', 'b'])
if __name__ == '__main__':
unittest.main()
#
python array interview-questions
python array interview-questions
edited Dec 14 '16 at 14:25
200_success
129k15152414
129k15152414
asked Dec 14 '16 at 13:33
VivekVivek
14616
14616
5
$begingroup$
Well for one, Python lists can have multiple types of values, are you sure they required each array to have all ints. For example:['a','b','c',1,3,4]seems like a valid sequence that would return false in your implementation
$endgroup$
– Navidad20
Dec 14 '16 at 14:36
$begingroup$
Maybe you should have usedxrange? ;)
$endgroup$
– Tamoghna Chowdhury
Dec 14 '16 at 14:38
1
$begingroup$
Also, they asked about an array. Maybe you should have used anumpy.arrayinstead of a list? With NumPy arrays, this could be done in 2 function calls.
$endgroup$
– Tamoghna Chowdhury
Dec 14 '16 at 14:43
3
$begingroup$
As I said in another comment, there are so many unknown points in this question that I think the main reason for rejection may actually be him making assumptions instead of asking questions.
$endgroup$
– ChatterOne
Dec 14 '16 at 15:18
$begingroup$
Why not juststr([1,3,4])[1:-1] in str([array])?
$endgroup$
– Samuel Shifterovich
Dec 14 '16 at 21:41
|
show 6 more comments
5
$begingroup$
Well for one, Python lists can have multiple types of values, are you sure they required each array to have all ints. For example:['a','b','c',1,3,4]seems like a valid sequence that would return false in your implementation
$endgroup$
– Navidad20
Dec 14 '16 at 14:36
$begingroup$
Maybe you should have usedxrange? ;)
$endgroup$
– Tamoghna Chowdhury
Dec 14 '16 at 14:38
1
$begingroup$
Also, they asked about an array. Maybe you should have used anumpy.arrayinstead of a list? With NumPy arrays, this could be done in 2 function calls.
$endgroup$
– Tamoghna Chowdhury
Dec 14 '16 at 14:43
3
$begingroup$
As I said in another comment, there are so many unknown points in this question that I think the main reason for rejection may actually be him making assumptions instead of asking questions.
$endgroup$
– ChatterOne
Dec 14 '16 at 15:18
$begingroup$
Why not juststr([1,3,4])[1:-1] in str([array])?
$endgroup$
– Samuel Shifterovich
Dec 14 '16 at 21:41
5
5
$begingroup$
Well for one, Python lists can have multiple types of values, are you sure they required each array to have all ints. For example:
['a','b','c',1,3,4] seems like a valid sequence that would return false in your implementation$endgroup$
– Navidad20
Dec 14 '16 at 14:36
$begingroup$
Well for one, Python lists can have multiple types of values, are you sure they required each array to have all ints. For example:
['a','b','c',1,3,4] seems like a valid sequence that would return false in your implementation$endgroup$
– Navidad20
Dec 14 '16 at 14:36
$begingroup$
Maybe you should have used
xrange? ;)$endgroup$
– Tamoghna Chowdhury
Dec 14 '16 at 14:38
$begingroup$
Maybe you should have used
xrange? ;)$endgroup$
– Tamoghna Chowdhury
Dec 14 '16 at 14:38
1
1
$begingroup$
Also, they asked about an array. Maybe you should have used a
numpy.array instead of a list? With NumPy arrays, this could be done in 2 function calls.$endgroup$
– Tamoghna Chowdhury
Dec 14 '16 at 14:43
$begingroup$
Also, they asked about an array. Maybe you should have used a
numpy.array instead of a list? With NumPy arrays, this could be done in 2 function calls.$endgroup$
– Tamoghna Chowdhury
Dec 14 '16 at 14:43
3
3
$begingroup$
As I said in another comment, there are so many unknown points in this question that I think the main reason for rejection may actually be him making assumptions instead of asking questions.
$endgroup$
– ChatterOne
Dec 14 '16 at 15:18
$begingroup$
As I said in another comment, there are so many unknown points in this question that I think the main reason for rejection may actually be him making assumptions instead of asking questions.
$endgroup$
– ChatterOne
Dec 14 '16 at 15:18
$begingroup$
Why not just
str([1,3,4])[1:-1] in str([array])?$endgroup$
– Samuel Shifterovich
Dec 14 '16 at 21:41
$begingroup$
Why not just
str([1,3,4])[1:-1] in str([array])?$endgroup$
– Samuel Shifterovich
Dec 14 '16 at 21:41
|
show 6 more comments
8 Answers
8
active
oldest
votes
$begingroup$
By PEP 8, doesSeqAppear should be does_seq_appear. You used the right naming convention for your unit tests, though. Personally, I would prefer def contains_seq(arr, seq=[1, 3, 4]).
Your arr_len < 3 test is superfluous and should therefore be eliminated. Don't write a special case when the regular case works correctly and just as quickly.
Your all(isinstance(item, int) for item in int_arr) check was not specified in the problem, and is therefore harmful. The question does not say that doesSeqAppear([3.1, 1, 3, 4]) should return False, nor does it say that it should fail with an exception. In fact, by my interpretation, it does contain the magic sequence and should therefore return True. In any case, you have wasted a complete iteration of the list just to perform a check that wasn't asked for.
Checking isinstance(int_arr, list) is un-Pythonic, since duck-typing is the norm in Python. In any case, the code would likely fail naturally if it is not a list.
After cutting all that excess, you should drop the # Loop through elements comment as well.
$endgroup$
$begingroup$
I wouldn't say thearr_len < 3test is superfluous. It is preventing an index error.
$endgroup$
– Darthfett
Dec 14 '16 at 21:02
1
$begingroup$
@Darthfett: I don't think it prevents any errors. If the length is less than 3, theforloop will execute 0 iterations.
$endgroup$
– user2357112
Dec 14 '16 at 21:04
$begingroup$
@user2357112 oops, you are correct. :)
$endgroup$
– Darthfett
Dec 14 '16 at 21:05
$begingroup$
If dropping thearr_len < 3check, it would be appropriate to specify why it still works without it, since it takes a moment to figure that out.
$endgroup$
– jpmc26
Dec 15 '16 at 0:23
add a comment |
$begingroup$
Per the problem definition, I would expect a function thas is able to check any sequence in an array. Not necessarily (1, 3, 4) which was given as an example. In this case, the sequence should also be a parameter of the function, giving the signature:
def has_sequence(array, sequence):
Next, I would rely on Python iterations to "check" if array is a list, or at least an iterable. As there is no obvious reasons, to me, that has_sequence('once upon a time', 'e u') should fail. It seems like a valid usecase.
Following, I would use a variation of the itertools recipe pairwise to group elements of array in tuples of the same length than sequence:
import itertools
def lookup(iterable, length):
tees = itertools.tee(iterable, length)
for i, t in enumerate(tees):
for _ in xrange(i):
next(t, None)
return itertools.izip(*tees)
def has_sequence(array, sequence):
# Convert to tuple for easy testing later
sequence = tuple(sequence)
return any(group == sequence for group in lookup(array, len(sequence)))
Now, other things that could have been done better:
# Tested with Python 2.7can be replaced by#!/usr/bin/env python2
if int_arr[i] == 1 and int_arr[i+1] == 3 and int_arr[i+2] == 4 :can be replaced byif int_arr[i:i+3] == [1, 3, 4]:removing the need for the ugly
assertin unit tests should be replaced byself.assertTrue(…)orself.assertFalse(…)
- you should be more consistent in your usage of whitespace (putting one after each comma, none before any colon…).
$endgroup$
$begingroup$
Something liketuplewisemight be a more evocative name thanlookup. (I had the same idea though.)
$endgroup$
– David Z
Dec 14 '16 at 18:51
add a comment |
$begingroup$
I think your answer is much too long. Here's mine:
def check_for_1_3_4(seq):
return (1, 3, 4) in zip(seq, seq[1:], seq[2:])
Here are some tests:
>>> check_for_1_3_4([1, 3, 4, 5, 6, 7])
True
>>> check_for_1_3_4([5, 6, 7, 1, 3, 4])
True
>>> check_for_1_3_4([5, 6, 1, 3, 4, 7, 8])
True
>>> check_for_1_3_4([1, 3])
False
>>> check_for_1_3_4()
False
>>>
My code may seem terse, but it's still readable for anyone who understands slicing and zip. I expect Python experts to at least know about slicing.
Unfortunately for me, my answer is less efficient than yours. It could triple the amount of memory used! By using generators a more efficient but more complicated solution can be created. Instead of creating copies of the sequence, this new code uses only the original sequence, but the logic is nearly the same.
import itertools
def check_for_1_3_4(seq):
return (1, 3, 4) in itertools.izip(seq,
itertools.islice(seq, 1, None),
itertools.islice(seq, 2, None))
The tests still pass.
I wouldn't expect most Python programmers to be familiar with itertools, but I was under the impression that Python experts do know it.
$endgroup$
$begingroup$
How performant is it? Someone could throw a huge byte array at your method (like a file looking for a particular sequence) and this would duplicate it in memory 3 or 4 times, no?
$endgroup$
– Nate Diamond
Dec 15 '16 at 18:01
$begingroup$
@NateDiamond At worst, it could be five times through the list. However, the time it takes would be the same as a single loop with five instructions per element, unless going through the loop once is easier on the cache, easier for all the popular Python implementations to optimize, or is faster for some other reason. Yes, it would temporarily either triple or quadruple the memory usage. This all probably doesn't matter though. Design is about trade offs, but whether this is performant enough can't be determined with the given problem. Linear speed and memory usage isn't a bad starting place.
$endgroup$
– Drew
Dec 16 '16 at 7:13
$begingroup$
Fair enough, but if I were asking this in an interview, the first question that would pop into my head (assuming you didn't) is "Why didn't you ask how big the sequence could be?". I would then probably say "So what if this is trying to parse a 500mb file?" Net-net, anyone using this should realize the downsides to this approach in case they want to reuse it. Further, you claimed the given answer is much too long, yet the approach has certain benefits in this regard. They should probably be mentioned.
$endgroup$
– Nate Diamond
Dec 16 '16 at 18:12
1
$begingroup$
@NateDiamond Thanks for your input. I've included a discussion about efficiency in my answer.
$endgroup$
– Drew
Dec 19 '16 at 11:05
add a comment |
$begingroup$
KIS[S]
def sequence_contains_sequence(haystack_seq, needle_seq):
for i in range(0, len(haystack_seq) - len(needle_seq) + 1):
if needle_seq == haystack_seq[i:i+len(needle_seq)]:
return True
return False
We can't know why your interviewer rejected your application, but these types of questions are often starting points for conversation--not finished product endpoints. If you write the simplest, most straightforward code you can, you and your interviewer can then talk about things like expansion, generalization, and performance.
Your interviewer knows that asking you to change your function interface is more problematic because you'll also have to change all your [unasked for] unit tests. This slows down the process and might make the interviewer worry that you'll pollute their codebase with a lot of brittle code.
$endgroup$
$begingroup$
"Subsequence" has a very specific technical meaning, and it is the wrong term to use here.
$endgroup$
– 200_success
Dec 15 '16 at 2:36
$begingroup$
@200_success Hmm, you're right. Naming things is hard.
$endgroup$
– brian_o
Dec 15 '16 at 5:15
add a comment |
$begingroup$
Assumptions
You made a lot of assumptions with this code, which you either did not mention during the interview or you incorrectly assumed to be true of the question. In other words, you were over thinking the problem.
#check if input is a list
if not isinstance(int_arr, list):
raise TypeError("Input shall be of type array.")
You should not care about the instance type. The type could easily have been a user defined type which behaves like a list or even another python built in. For example, python has both deque and array, and they both behave like a list, supporting the same operations as a list.
# check all elements are of type int
if not all(isinstance(item, int) for item in int_arr) :
raise ValueError("All elements in array shall be of type int.")
This is not necessarily true because lists or collections in general, in python can contain many different types. So insisting that the list contains only integers is just imposing a requirement which did not exist in the first place.
In closing, I would advice that you adhere to the KISS principle in future interviews and to ask questions or state your assumptions before diving into the code. Even if it doesn't sound like an assumption to you, make sure they know what is going on in your head either as you're coding or before you write your code. It might sound silly to say "Ok I will also make sure that I have been given a list", but you will be saving yourself a lot of grief when they reply, "Don't worry about that, just assume it's a list".
Check if array contains the sequence (1,3,4)
def check_sequence(arr):
return any((arr[i], arr[i + 1], arr[i + 2]) == (1,3,4) for i in range(len(arr) - 2))
$endgroup$
add a comment |
$begingroup$
Is basic IF and FOR loop
def array134(nums):
if len(nums) < 3:
return False
test =[1, 3, 4]
for i in range(len(nums)):
test2 = nums[i:i+3]
if test2 == test:
return True
return False
New contributor
alinkl is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
$begingroup$
Welcome to Code Review! You have presented an alternative solution, but haven't reviewed the code. Please explain your reasoning (how your solution works and why it is better than the original) so that the author and other readers can learn from your thought process. Please read Why are alternative solutions not welcome?
$endgroup$
– Sᴀᴍ Onᴇᴌᴀ
3 hours ago
add a comment |
$begingroup$
This optimization allows you to reduce the number of times checking an element. It also eliminates the need to make a new iterator which you had created with range
# Loop through elements
index = 0
while index < (arr_len-2):
if int_arr[index] != 1:
index += 1
continue
if int_arr[index+1] != 3:
index += 1
continue
if int_arr[index+2] != 4:
index += 1
continue
return True
return False
$endgroup$
$begingroup$
What about the sequence [1,1,3,4]? The first test will find 1 and pass, the second test will not find a 3 and will therefore move on 2 places and miss the pattern that is there.
$endgroup$
– neil
Dec 14 '16 at 16:54
$begingroup$
You make a good point. I could add more if statements to fix that, but i'm not getting the top answer so its not worth it
$endgroup$
– Navidad20
Dec 14 '16 at 16:55
add a comment |
$begingroup$
i dont know this approach is stupid or smart, i was given the same code in an assignment and converted the list to string and matched for the sequence
import re
def list123(nums):
#start writing your code here
str1="".join(str(x) for x in nums)
if re.search("YOUR SEQUENCE",str1):
return True
else:
return False
nums=[1,2,3,4,5]
print(list123(nums))
$endgroup$
1
$begingroup$
Welcome to Code Review! You have presented an alternative solution, but haven't reviewed the code. Please edit to show what aspects of the question code prompted you to write this version, and in what ways it's an improvement over the original.
$endgroup$
– Toby Speight
Sep 6 '18 at 15:22
1
$begingroup$
Welcome to Code Review! In addition to what @TobySpeight mentioned, if you haven't already, please see How do I write a good answer before posting an answer.
$endgroup$
– Sᴀᴍ Onᴇᴌᴀ
Sep 6 '18 at 15:27
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f149867%2fpython-code-to-check-if-an-array-has-a-sequence-1-3-4%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
8 Answers
8
active
oldest
votes
8 Answers
8
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
By PEP 8, doesSeqAppear should be does_seq_appear. You used the right naming convention for your unit tests, though. Personally, I would prefer def contains_seq(arr, seq=[1, 3, 4]).
Your arr_len < 3 test is superfluous and should therefore be eliminated. Don't write a special case when the regular case works correctly and just as quickly.
Your all(isinstance(item, int) for item in int_arr) check was not specified in the problem, and is therefore harmful. The question does not say that doesSeqAppear([3.1, 1, 3, 4]) should return False, nor does it say that it should fail with an exception. In fact, by my interpretation, it does contain the magic sequence and should therefore return True. In any case, you have wasted a complete iteration of the list just to perform a check that wasn't asked for.
Checking isinstance(int_arr, list) is un-Pythonic, since duck-typing is the norm in Python. In any case, the code would likely fail naturally if it is not a list.
After cutting all that excess, you should drop the # Loop through elements comment as well.
$endgroup$
$begingroup$
I wouldn't say thearr_len < 3test is superfluous. It is preventing an index error.
$endgroup$
– Darthfett
Dec 14 '16 at 21:02
1
$begingroup$
@Darthfett: I don't think it prevents any errors. If the length is less than 3, theforloop will execute 0 iterations.
$endgroup$
– user2357112
Dec 14 '16 at 21:04
$begingroup$
@user2357112 oops, you are correct. :)
$endgroup$
– Darthfett
Dec 14 '16 at 21:05
$begingroup$
If dropping thearr_len < 3check, it would be appropriate to specify why it still works without it, since it takes a moment to figure that out.
$endgroup$
– jpmc26
Dec 15 '16 at 0:23
add a comment |
$begingroup$
By PEP 8, doesSeqAppear should be does_seq_appear. You used the right naming convention for your unit tests, though. Personally, I would prefer def contains_seq(arr, seq=[1, 3, 4]).
Your arr_len < 3 test is superfluous and should therefore be eliminated. Don't write a special case when the regular case works correctly and just as quickly.
Your all(isinstance(item, int) for item in int_arr) check was not specified in the problem, and is therefore harmful. The question does not say that doesSeqAppear([3.1, 1, 3, 4]) should return False, nor does it say that it should fail with an exception. In fact, by my interpretation, it does contain the magic sequence and should therefore return True. In any case, you have wasted a complete iteration of the list just to perform a check that wasn't asked for.
Checking isinstance(int_arr, list) is un-Pythonic, since duck-typing is the norm in Python. In any case, the code would likely fail naturally if it is not a list.
After cutting all that excess, you should drop the # Loop through elements comment as well.
$endgroup$
$begingroup$
I wouldn't say thearr_len < 3test is superfluous. It is preventing an index error.
$endgroup$
– Darthfett
Dec 14 '16 at 21:02
1
$begingroup$
@Darthfett: I don't think it prevents any errors. If the length is less than 3, theforloop will execute 0 iterations.
$endgroup$
– user2357112
Dec 14 '16 at 21:04
$begingroup$
@user2357112 oops, you are correct. :)
$endgroup$
– Darthfett
Dec 14 '16 at 21:05
$begingroup$
If dropping thearr_len < 3check, it would be appropriate to specify why it still works without it, since it takes a moment to figure that out.
$endgroup$
– jpmc26
Dec 15 '16 at 0:23
add a comment |
$begingroup$
By PEP 8, doesSeqAppear should be does_seq_appear. You used the right naming convention for your unit tests, though. Personally, I would prefer def contains_seq(arr, seq=[1, 3, 4]).
Your arr_len < 3 test is superfluous and should therefore be eliminated. Don't write a special case when the regular case works correctly and just as quickly.
Your all(isinstance(item, int) for item in int_arr) check was not specified in the problem, and is therefore harmful. The question does not say that doesSeqAppear([3.1, 1, 3, 4]) should return False, nor does it say that it should fail with an exception. In fact, by my interpretation, it does contain the magic sequence and should therefore return True. In any case, you have wasted a complete iteration of the list just to perform a check that wasn't asked for.
Checking isinstance(int_arr, list) is un-Pythonic, since duck-typing is the norm in Python. In any case, the code would likely fail naturally if it is not a list.
After cutting all that excess, you should drop the # Loop through elements comment as well.
$endgroup$
By PEP 8, doesSeqAppear should be does_seq_appear. You used the right naming convention for your unit tests, though. Personally, I would prefer def contains_seq(arr, seq=[1, 3, 4]).
Your arr_len < 3 test is superfluous and should therefore be eliminated. Don't write a special case when the regular case works correctly and just as quickly.
Your all(isinstance(item, int) for item in int_arr) check was not specified in the problem, and is therefore harmful. The question does not say that doesSeqAppear([3.1, 1, 3, 4]) should return False, nor does it say that it should fail with an exception. In fact, by my interpretation, it does contain the magic sequence and should therefore return True. In any case, you have wasted a complete iteration of the list just to perform a check that wasn't asked for.
Checking isinstance(int_arr, list) is un-Pythonic, since duck-typing is the norm in Python. In any case, the code would likely fail naturally if it is not a list.
After cutting all that excess, you should drop the # Loop through elements comment as well.
answered Dec 14 '16 at 14:49
200_success200_success
129k15152414
129k15152414
$begingroup$
I wouldn't say thearr_len < 3test is superfluous. It is preventing an index error.
$endgroup$
– Darthfett
Dec 14 '16 at 21:02
1
$begingroup$
@Darthfett: I don't think it prevents any errors. If the length is less than 3, theforloop will execute 0 iterations.
$endgroup$
– user2357112
Dec 14 '16 at 21:04
$begingroup$
@user2357112 oops, you are correct. :)
$endgroup$
– Darthfett
Dec 14 '16 at 21:05
$begingroup$
If dropping thearr_len < 3check, it would be appropriate to specify why it still works without it, since it takes a moment to figure that out.
$endgroup$
– jpmc26
Dec 15 '16 at 0:23
add a comment |
$begingroup$
I wouldn't say thearr_len < 3test is superfluous. It is preventing an index error.
$endgroup$
– Darthfett
Dec 14 '16 at 21:02
1
$begingroup$
@Darthfett: I don't think it prevents any errors. If the length is less than 3, theforloop will execute 0 iterations.
$endgroup$
– user2357112
Dec 14 '16 at 21:04
$begingroup$
@user2357112 oops, you are correct. :)
$endgroup$
– Darthfett
Dec 14 '16 at 21:05
$begingroup$
If dropping thearr_len < 3check, it would be appropriate to specify why it still works without it, since it takes a moment to figure that out.
$endgroup$
– jpmc26
Dec 15 '16 at 0:23
$begingroup$
I wouldn't say the
arr_len < 3 test is superfluous. It is preventing an index error.$endgroup$
– Darthfett
Dec 14 '16 at 21:02
$begingroup$
I wouldn't say the
arr_len < 3 test is superfluous. It is preventing an index error.$endgroup$
– Darthfett
Dec 14 '16 at 21:02
1
1
$begingroup$
@Darthfett: I don't think it prevents any errors. If the length is less than 3, the
for loop will execute 0 iterations.$endgroup$
– user2357112
Dec 14 '16 at 21:04
$begingroup$
@Darthfett: I don't think it prevents any errors. If the length is less than 3, the
for loop will execute 0 iterations.$endgroup$
– user2357112
Dec 14 '16 at 21:04
$begingroup$
@user2357112 oops, you are correct. :)
$endgroup$
– Darthfett
Dec 14 '16 at 21:05
$begingroup$
@user2357112 oops, you are correct. :)
$endgroup$
– Darthfett
Dec 14 '16 at 21:05
$begingroup$
If dropping the
arr_len < 3 check, it would be appropriate to specify why it still works without it, since it takes a moment to figure that out.$endgroup$
– jpmc26
Dec 15 '16 at 0:23
$begingroup$
If dropping the
arr_len < 3 check, it would be appropriate to specify why it still works without it, since it takes a moment to figure that out.$endgroup$
– jpmc26
Dec 15 '16 at 0:23
add a comment |
$begingroup$
Per the problem definition, I would expect a function thas is able to check any sequence in an array. Not necessarily (1, 3, 4) which was given as an example. In this case, the sequence should also be a parameter of the function, giving the signature:
def has_sequence(array, sequence):
Next, I would rely on Python iterations to "check" if array is a list, or at least an iterable. As there is no obvious reasons, to me, that has_sequence('once upon a time', 'e u') should fail. It seems like a valid usecase.
Following, I would use a variation of the itertools recipe pairwise to group elements of array in tuples of the same length than sequence:
import itertools
def lookup(iterable, length):
tees = itertools.tee(iterable, length)
for i, t in enumerate(tees):
for _ in xrange(i):
next(t, None)
return itertools.izip(*tees)
def has_sequence(array, sequence):
# Convert to tuple for easy testing later
sequence = tuple(sequence)
return any(group == sequence for group in lookup(array, len(sequence)))
Now, other things that could have been done better:
# Tested with Python 2.7can be replaced by#!/usr/bin/env python2
if int_arr[i] == 1 and int_arr[i+1] == 3 and int_arr[i+2] == 4 :can be replaced byif int_arr[i:i+3] == [1, 3, 4]:removing the need for the ugly
assertin unit tests should be replaced byself.assertTrue(…)orself.assertFalse(…)
- you should be more consistent in your usage of whitespace (putting one after each comma, none before any colon…).
$endgroup$
$begingroup$
Something liketuplewisemight be a more evocative name thanlookup. (I had the same idea though.)
$endgroup$
– David Z
Dec 14 '16 at 18:51
add a comment |
$begingroup$
Per the problem definition, I would expect a function thas is able to check any sequence in an array. Not necessarily (1, 3, 4) which was given as an example. In this case, the sequence should also be a parameter of the function, giving the signature:
def has_sequence(array, sequence):
Next, I would rely on Python iterations to "check" if array is a list, or at least an iterable. As there is no obvious reasons, to me, that has_sequence('once upon a time', 'e u') should fail. It seems like a valid usecase.
Following, I would use a variation of the itertools recipe pairwise to group elements of array in tuples of the same length than sequence:
import itertools
def lookup(iterable, length):
tees = itertools.tee(iterable, length)
for i, t in enumerate(tees):
for _ in xrange(i):
next(t, None)
return itertools.izip(*tees)
def has_sequence(array, sequence):
# Convert to tuple for easy testing later
sequence = tuple(sequence)
return any(group == sequence for group in lookup(array, len(sequence)))
Now, other things that could have been done better:
# Tested with Python 2.7can be replaced by#!/usr/bin/env python2
if int_arr[i] == 1 and int_arr[i+1] == 3 and int_arr[i+2] == 4 :can be replaced byif int_arr[i:i+3] == [1, 3, 4]:removing the need for the ugly
assertin unit tests should be replaced byself.assertTrue(…)orself.assertFalse(…)
- you should be more consistent in your usage of whitespace (putting one after each comma, none before any colon…).
$endgroup$
$begingroup$
Something liketuplewisemight be a more evocative name thanlookup. (I had the same idea though.)
$endgroup$
– David Z
Dec 14 '16 at 18:51
add a comment |
$begingroup$
Per the problem definition, I would expect a function thas is able to check any sequence in an array. Not necessarily (1, 3, 4) which was given as an example. In this case, the sequence should also be a parameter of the function, giving the signature:
def has_sequence(array, sequence):
Next, I would rely on Python iterations to "check" if array is a list, or at least an iterable. As there is no obvious reasons, to me, that has_sequence('once upon a time', 'e u') should fail. It seems like a valid usecase.
Following, I would use a variation of the itertools recipe pairwise to group elements of array in tuples of the same length than sequence:
import itertools
def lookup(iterable, length):
tees = itertools.tee(iterable, length)
for i, t in enumerate(tees):
for _ in xrange(i):
next(t, None)
return itertools.izip(*tees)
def has_sequence(array, sequence):
# Convert to tuple for easy testing later
sequence = tuple(sequence)
return any(group == sequence for group in lookup(array, len(sequence)))
Now, other things that could have been done better:
# Tested with Python 2.7can be replaced by#!/usr/bin/env python2
if int_arr[i] == 1 and int_arr[i+1] == 3 and int_arr[i+2] == 4 :can be replaced byif int_arr[i:i+3] == [1, 3, 4]:removing the need for the ugly
assertin unit tests should be replaced byself.assertTrue(…)orself.assertFalse(…)
- you should be more consistent in your usage of whitespace (putting one after each comma, none before any colon…).
$endgroup$
Per the problem definition, I would expect a function thas is able to check any sequence in an array. Not necessarily (1, 3, 4) which was given as an example. In this case, the sequence should also be a parameter of the function, giving the signature:
def has_sequence(array, sequence):
Next, I would rely on Python iterations to "check" if array is a list, or at least an iterable. As there is no obvious reasons, to me, that has_sequence('once upon a time', 'e u') should fail. It seems like a valid usecase.
Following, I would use a variation of the itertools recipe pairwise to group elements of array in tuples of the same length than sequence:
import itertools
def lookup(iterable, length):
tees = itertools.tee(iterable, length)
for i, t in enumerate(tees):
for _ in xrange(i):
next(t, None)
return itertools.izip(*tees)
def has_sequence(array, sequence):
# Convert to tuple for easy testing later
sequence = tuple(sequence)
return any(group == sequence for group in lookup(array, len(sequence)))
Now, other things that could have been done better:
# Tested with Python 2.7can be replaced by#!/usr/bin/env python2
if int_arr[i] == 1 and int_arr[i+1] == 3 and int_arr[i+2] == 4 :can be replaced byif int_arr[i:i+3] == [1, 3, 4]:removing the need for the ugly
assertin unit tests should be replaced byself.assertTrue(…)orself.assertFalse(…)
- you should be more consistent in your usage of whitespace (putting one after each comma, none before any colon…).
edited Dec 14 '16 at 15:16
answered Dec 14 '16 at 15:03
Mathias EttingerMathias Ettinger
24k33182
24k33182
$begingroup$
Something liketuplewisemight be a more evocative name thanlookup. (I had the same idea though.)
$endgroup$
– David Z
Dec 14 '16 at 18:51
add a comment |
$begingroup$
Something liketuplewisemight be a more evocative name thanlookup. (I had the same idea though.)
$endgroup$
– David Z
Dec 14 '16 at 18:51
$begingroup$
Something like
tuplewise might be a more evocative name than lookup. (I had the same idea though.)$endgroup$
– David Z
Dec 14 '16 at 18:51
$begingroup$
Something like
tuplewise might be a more evocative name than lookup. (I had the same idea though.)$endgroup$
– David Z
Dec 14 '16 at 18:51
add a comment |
$begingroup$
I think your answer is much too long. Here's mine:
def check_for_1_3_4(seq):
return (1, 3, 4) in zip(seq, seq[1:], seq[2:])
Here are some tests:
>>> check_for_1_3_4([1, 3, 4, 5, 6, 7])
True
>>> check_for_1_3_4([5, 6, 7, 1, 3, 4])
True
>>> check_for_1_3_4([5, 6, 1, 3, 4, 7, 8])
True
>>> check_for_1_3_4([1, 3])
False
>>> check_for_1_3_4()
False
>>>
My code may seem terse, but it's still readable for anyone who understands slicing and zip. I expect Python experts to at least know about slicing.
Unfortunately for me, my answer is less efficient than yours. It could triple the amount of memory used! By using generators a more efficient but more complicated solution can be created. Instead of creating copies of the sequence, this new code uses only the original sequence, but the logic is nearly the same.
import itertools
def check_for_1_3_4(seq):
return (1, 3, 4) in itertools.izip(seq,
itertools.islice(seq, 1, None),
itertools.islice(seq, 2, None))
The tests still pass.
I wouldn't expect most Python programmers to be familiar with itertools, but I was under the impression that Python experts do know it.
$endgroup$
$begingroup$
How performant is it? Someone could throw a huge byte array at your method (like a file looking for a particular sequence) and this would duplicate it in memory 3 or 4 times, no?
$endgroup$
– Nate Diamond
Dec 15 '16 at 18:01
$begingroup$
@NateDiamond At worst, it could be five times through the list. However, the time it takes would be the same as a single loop with five instructions per element, unless going through the loop once is easier on the cache, easier for all the popular Python implementations to optimize, or is faster for some other reason. Yes, it would temporarily either triple or quadruple the memory usage. This all probably doesn't matter though. Design is about trade offs, but whether this is performant enough can't be determined with the given problem. Linear speed and memory usage isn't a bad starting place.
$endgroup$
– Drew
Dec 16 '16 at 7:13
$begingroup$
Fair enough, but if I were asking this in an interview, the first question that would pop into my head (assuming you didn't) is "Why didn't you ask how big the sequence could be?". I would then probably say "So what if this is trying to parse a 500mb file?" Net-net, anyone using this should realize the downsides to this approach in case they want to reuse it. Further, you claimed the given answer is much too long, yet the approach has certain benefits in this regard. They should probably be mentioned.
$endgroup$
– Nate Diamond
Dec 16 '16 at 18:12
1
$begingroup$
@NateDiamond Thanks for your input. I've included a discussion about efficiency in my answer.
$endgroup$
– Drew
Dec 19 '16 at 11:05
add a comment |
$begingroup$
I think your answer is much too long. Here's mine:
def check_for_1_3_4(seq):
return (1, 3, 4) in zip(seq, seq[1:], seq[2:])
Here are some tests:
>>> check_for_1_3_4([1, 3, 4, 5, 6, 7])
True
>>> check_for_1_3_4([5, 6, 7, 1, 3, 4])
True
>>> check_for_1_3_4([5, 6, 1, 3, 4, 7, 8])
True
>>> check_for_1_3_4([1, 3])
False
>>> check_for_1_3_4()
False
>>>
My code may seem terse, but it's still readable for anyone who understands slicing and zip. I expect Python experts to at least know about slicing.
Unfortunately for me, my answer is less efficient than yours. It could triple the amount of memory used! By using generators a more efficient but more complicated solution can be created. Instead of creating copies of the sequence, this new code uses only the original sequence, but the logic is nearly the same.
import itertools
def check_for_1_3_4(seq):
return (1, 3, 4) in itertools.izip(seq,
itertools.islice(seq, 1, None),
itertools.islice(seq, 2, None))
The tests still pass.
I wouldn't expect most Python programmers to be familiar with itertools, but I was under the impression that Python experts do know it.
$endgroup$
$begingroup$
How performant is it? Someone could throw a huge byte array at your method (like a file looking for a particular sequence) and this would duplicate it in memory 3 or 4 times, no?
$endgroup$
– Nate Diamond
Dec 15 '16 at 18:01
$begingroup$
@NateDiamond At worst, it could be five times through the list. However, the time it takes would be the same as a single loop with five instructions per element, unless going through the loop once is easier on the cache, easier for all the popular Python implementations to optimize, or is faster for some other reason. Yes, it would temporarily either triple or quadruple the memory usage. This all probably doesn't matter though. Design is about trade offs, but whether this is performant enough can't be determined with the given problem. Linear speed and memory usage isn't a bad starting place.
$endgroup$
– Drew
Dec 16 '16 at 7:13
$begingroup$
Fair enough, but if I were asking this in an interview, the first question that would pop into my head (assuming you didn't) is "Why didn't you ask how big the sequence could be?". I would then probably say "So what if this is trying to parse a 500mb file?" Net-net, anyone using this should realize the downsides to this approach in case they want to reuse it. Further, you claimed the given answer is much too long, yet the approach has certain benefits in this regard. They should probably be mentioned.
$endgroup$
– Nate Diamond
Dec 16 '16 at 18:12
1
$begingroup$
@NateDiamond Thanks for your input. I've included a discussion about efficiency in my answer.
$endgroup$
– Drew
Dec 19 '16 at 11:05
add a comment |
$begingroup$
I think your answer is much too long. Here's mine:
def check_for_1_3_4(seq):
return (1, 3, 4) in zip(seq, seq[1:], seq[2:])
Here are some tests:
>>> check_for_1_3_4([1, 3, 4, 5, 6, 7])
True
>>> check_for_1_3_4([5, 6, 7, 1, 3, 4])
True
>>> check_for_1_3_4([5, 6, 1, 3, 4, 7, 8])
True
>>> check_for_1_3_4([1, 3])
False
>>> check_for_1_3_4()
False
>>>
My code may seem terse, but it's still readable for anyone who understands slicing and zip. I expect Python experts to at least know about slicing.
Unfortunately for me, my answer is less efficient than yours. It could triple the amount of memory used! By using generators a more efficient but more complicated solution can be created. Instead of creating copies of the sequence, this new code uses only the original sequence, but the logic is nearly the same.
import itertools
def check_for_1_3_4(seq):
return (1, 3, 4) in itertools.izip(seq,
itertools.islice(seq, 1, None),
itertools.islice(seq, 2, None))
The tests still pass.
I wouldn't expect most Python programmers to be familiar with itertools, but I was under the impression that Python experts do know it.
$endgroup$
I think your answer is much too long. Here's mine:
def check_for_1_3_4(seq):
return (1, 3, 4) in zip(seq, seq[1:], seq[2:])
Here are some tests:
>>> check_for_1_3_4([1, 3, 4, 5, 6, 7])
True
>>> check_for_1_3_4([5, 6, 7, 1, 3, 4])
True
>>> check_for_1_3_4([5, 6, 1, 3, 4, 7, 8])
True
>>> check_for_1_3_4([1, 3])
False
>>> check_for_1_3_4()
False
>>>
My code may seem terse, but it's still readable for anyone who understands slicing and zip. I expect Python experts to at least know about slicing.
Unfortunately for me, my answer is less efficient than yours. It could triple the amount of memory used! By using generators a more efficient but more complicated solution can be created. Instead of creating copies of the sequence, this new code uses only the original sequence, but the logic is nearly the same.
import itertools
def check_for_1_3_4(seq):
return (1, 3, 4) in itertools.izip(seq,
itertools.islice(seq, 1, None),
itertools.islice(seq, 2, None))
The tests still pass.
I wouldn't expect most Python programmers to be familiar with itertools, but I was under the impression that Python experts do know it.
edited Dec 19 '16 at 11:04
answered Dec 15 '16 at 2:20
DrewDrew
412
412
$begingroup$
How performant is it? Someone could throw a huge byte array at your method (like a file looking for a particular sequence) and this would duplicate it in memory 3 or 4 times, no?
$endgroup$
– Nate Diamond
Dec 15 '16 at 18:01
$begingroup$
@NateDiamond At worst, it could be five times through the list. However, the time it takes would be the same as a single loop with five instructions per element, unless going through the loop once is easier on the cache, easier for all the popular Python implementations to optimize, or is faster for some other reason. Yes, it would temporarily either triple or quadruple the memory usage. This all probably doesn't matter though. Design is about trade offs, but whether this is performant enough can't be determined with the given problem. Linear speed and memory usage isn't a bad starting place.
$endgroup$
– Drew
Dec 16 '16 at 7:13
$begingroup$
Fair enough, but if I were asking this in an interview, the first question that would pop into my head (assuming you didn't) is "Why didn't you ask how big the sequence could be?". I would then probably say "So what if this is trying to parse a 500mb file?" Net-net, anyone using this should realize the downsides to this approach in case they want to reuse it. Further, you claimed the given answer is much too long, yet the approach has certain benefits in this regard. They should probably be mentioned.
$endgroup$
– Nate Diamond
Dec 16 '16 at 18:12
1
$begingroup$
@NateDiamond Thanks for your input. I've included a discussion about efficiency in my answer.
$endgroup$
– Drew
Dec 19 '16 at 11:05
add a comment |
$begingroup$
How performant is it? Someone could throw a huge byte array at your method (like a file looking for a particular sequence) and this would duplicate it in memory 3 or 4 times, no?
$endgroup$
– Nate Diamond
Dec 15 '16 at 18:01
$begingroup$
@NateDiamond At worst, it could be five times through the list. However, the time it takes would be the same as a single loop with five instructions per element, unless going through the loop once is easier on the cache, easier for all the popular Python implementations to optimize, or is faster for some other reason. Yes, it would temporarily either triple or quadruple the memory usage. This all probably doesn't matter though. Design is about trade offs, but whether this is performant enough can't be determined with the given problem. Linear speed and memory usage isn't a bad starting place.
$endgroup$
– Drew
Dec 16 '16 at 7:13
$begingroup$
Fair enough, but if I were asking this in an interview, the first question that would pop into my head (assuming you didn't) is "Why didn't you ask how big the sequence could be?". I would then probably say "So what if this is trying to parse a 500mb file?" Net-net, anyone using this should realize the downsides to this approach in case they want to reuse it. Further, you claimed the given answer is much too long, yet the approach has certain benefits in this regard. They should probably be mentioned.
$endgroup$
– Nate Diamond
Dec 16 '16 at 18:12
1
$begingroup$
@NateDiamond Thanks for your input. I've included a discussion about efficiency in my answer.
$endgroup$
– Drew
Dec 19 '16 at 11:05
$begingroup$
How performant is it? Someone could throw a huge byte array at your method (like a file looking for a particular sequence) and this would duplicate it in memory 3 or 4 times, no?
$endgroup$
– Nate Diamond
Dec 15 '16 at 18:01
$begingroup$
How performant is it? Someone could throw a huge byte array at your method (like a file looking for a particular sequence) and this would duplicate it in memory 3 or 4 times, no?
$endgroup$
– Nate Diamond
Dec 15 '16 at 18:01
$begingroup$
@NateDiamond At worst, it could be five times through the list. However, the time it takes would be the same as a single loop with five instructions per element, unless going through the loop once is easier on the cache, easier for all the popular Python implementations to optimize, or is faster for some other reason. Yes, it would temporarily either triple or quadruple the memory usage. This all probably doesn't matter though. Design is about trade offs, but whether this is performant enough can't be determined with the given problem. Linear speed and memory usage isn't a bad starting place.
$endgroup$
– Drew
Dec 16 '16 at 7:13
$begingroup$
@NateDiamond At worst, it could be five times through the list. However, the time it takes would be the same as a single loop with five instructions per element, unless going through the loop once is easier on the cache, easier for all the popular Python implementations to optimize, or is faster for some other reason. Yes, it would temporarily either triple or quadruple the memory usage. This all probably doesn't matter though. Design is about trade offs, but whether this is performant enough can't be determined with the given problem. Linear speed and memory usage isn't a bad starting place.
$endgroup$
– Drew
Dec 16 '16 at 7:13
$begingroup$
Fair enough, but if I were asking this in an interview, the first question that would pop into my head (assuming you didn't) is "Why didn't you ask how big the sequence could be?". I would then probably say "So what if this is trying to parse a 500mb file?" Net-net, anyone using this should realize the downsides to this approach in case they want to reuse it. Further, you claimed the given answer is much too long, yet the approach has certain benefits in this regard. They should probably be mentioned.
$endgroup$
– Nate Diamond
Dec 16 '16 at 18:12
$begingroup$
Fair enough, but if I were asking this in an interview, the first question that would pop into my head (assuming you didn't) is "Why didn't you ask how big the sequence could be?". I would then probably say "So what if this is trying to parse a 500mb file?" Net-net, anyone using this should realize the downsides to this approach in case they want to reuse it. Further, you claimed the given answer is much too long, yet the approach has certain benefits in this regard. They should probably be mentioned.
$endgroup$
– Nate Diamond
Dec 16 '16 at 18:12
1
1
$begingroup$
@NateDiamond Thanks for your input. I've included a discussion about efficiency in my answer.
$endgroup$
– Drew
Dec 19 '16 at 11:05
$begingroup$
@NateDiamond Thanks for your input. I've included a discussion about efficiency in my answer.
$endgroup$
– Drew
Dec 19 '16 at 11:05
add a comment |
$begingroup$
KIS[S]
def sequence_contains_sequence(haystack_seq, needle_seq):
for i in range(0, len(haystack_seq) - len(needle_seq) + 1):
if needle_seq == haystack_seq[i:i+len(needle_seq)]:
return True
return False
We can't know why your interviewer rejected your application, but these types of questions are often starting points for conversation--not finished product endpoints. If you write the simplest, most straightforward code you can, you and your interviewer can then talk about things like expansion, generalization, and performance.
Your interviewer knows that asking you to change your function interface is more problematic because you'll also have to change all your [unasked for] unit tests. This slows down the process and might make the interviewer worry that you'll pollute their codebase with a lot of brittle code.
$endgroup$
$begingroup$
"Subsequence" has a very specific technical meaning, and it is the wrong term to use here.
$endgroup$
– 200_success
Dec 15 '16 at 2:36
$begingroup$
@200_success Hmm, you're right. Naming things is hard.
$endgroup$
– brian_o
Dec 15 '16 at 5:15
add a comment |
$begingroup$
KIS[S]
def sequence_contains_sequence(haystack_seq, needle_seq):
for i in range(0, len(haystack_seq) - len(needle_seq) + 1):
if needle_seq == haystack_seq[i:i+len(needle_seq)]:
return True
return False
We can't know why your interviewer rejected your application, but these types of questions are often starting points for conversation--not finished product endpoints. If you write the simplest, most straightforward code you can, you and your interviewer can then talk about things like expansion, generalization, and performance.
Your interviewer knows that asking you to change your function interface is more problematic because you'll also have to change all your [unasked for] unit tests. This slows down the process and might make the interviewer worry that you'll pollute their codebase with a lot of brittle code.
$endgroup$
$begingroup$
"Subsequence" has a very specific technical meaning, and it is the wrong term to use here.
$endgroup$
– 200_success
Dec 15 '16 at 2:36
$begingroup$
@200_success Hmm, you're right. Naming things is hard.
$endgroup$
– brian_o
Dec 15 '16 at 5:15
add a comment |
$begingroup$
KIS[S]
def sequence_contains_sequence(haystack_seq, needle_seq):
for i in range(0, len(haystack_seq) - len(needle_seq) + 1):
if needle_seq == haystack_seq[i:i+len(needle_seq)]:
return True
return False
We can't know why your interviewer rejected your application, but these types of questions are often starting points for conversation--not finished product endpoints. If you write the simplest, most straightforward code you can, you and your interviewer can then talk about things like expansion, generalization, and performance.
Your interviewer knows that asking you to change your function interface is more problematic because you'll also have to change all your [unasked for] unit tests. This slows down the process and might make the interviewer worry that you'll pollute their codebase with a lot of brittle code.
$endgroup$
KIS[S]
def sequence_contains_sequence(haystack_seq, needle_seq):
for i in range(0, len(haystack_seq) - len(needle_seq) + 1):
if needle_seq == haystack_seq[i:i+len(needle_seq)]:
return True
return False
We can't know why your interviewer rejected your application, but these types of questions are often starting points for conversation--not finished product endpoints. If you write the simplest, most straightforward code you can, you and your interviewer can then talk about things like expansion, generalization, and performance.
Your interviewer knows that asking you to change your function interface is more problematic because you'll also have to change all your [unasked for] unit tests. This slows down the process and might make the interviewer worry that you'll pollute their codebase with a lot of brittle code.
edited Dec 15 '16 at 5:21
answered Dec 14 '16 at 18:25
brian_obrian_o
77949
77949
$begingroup$
"Subsequence" has a very specific technical meaning, and it is the wrong term to use here.
$endgroup$
– 200_success
Dec 15 '16 at 2:36
$begingroup$
@200_success Hmm, you're right. Naming things is hard.
$endgroup$
– brian_o
Dec 15 '16 at 5:15
add a comment |
$begingroup$
"Subsequence" has a very specific technical meaning, and it is the wrong term to use here.
$endgroup$
– 200_success
Dec 15 '16 at 2:36
$begingroup$
@200_success Hmm, you're right. Naming things is hard.
$endgroup$
– brian_o
Dec 15 '16 at 5:15
$begingroup$
"Subsequence" has a very specific technical meaning, and it is the wrong term to use here.
$endgroup$
– 200_success
Dec 15 '16 at 2:36
$begingroup$
"Subsequence" has a very specific technical meaning, and it is the wrong term to use here.
$endgroup$
– 200_success
Dec 15 '16 at 2:36
$begingroup$
@200_success Hmm, you're right. Naming things is hard.
$endgroup$
– brian_o
Dec 15 '16 at 5:15
$begingroup$
@200_success Hmm, you're right. Naming things is hard.
$endgroup$
– brian_o
Dec 15 '16 at 5:15
add a comment |
$begingroup$
Assumptions
You made a lot of assumptions with this code, which you either did not mention during the interview or you incorrectly assumed to be true of the question. In other words, you were over thinking the problem.
#check if input is a list
if not isinstance(int_arr, list):
raise TypeError("Input shall be of type array.")
You should not care about the instance type. The type could easily have been a user defined type which behaves like a list or even another python built in. For example, python has both deque and array, and they both behave like a list, supporting the same operations as a list.
# check all elements are of type int
if not all(isinstance(item, int) for item in int_arr) :
raise ValueError("All elements in array shall be of type int.")
This is not necessarily true because lists or collections in general, in python can contain many different types. So insisting that the list contains only integers is just imposing a requirement which did not exist in the first place.
In closing, I would advice that you adhere to the KISS principle in future interviews and to ask questions or state your assumptions before diving into the code. Even if it doesn't sound like an assumption to you, make sure they know what is going on in your head either as you're coding or before you write your code. It might sound silly to say "Ok I will also make sure that I have been given a list", but you will be saving yourself a lot of grief when they reply, "Don't worry about that, just assume it's a list".
Check if array contains the sequence (1,3,4)
def check_sequence(arr):
return any((arr[i], arr[i + 1], arr[i + 2]) == (1,3,4) for i in range(len(arr) - 2))
$endgroup$
add a comment |
$begingroup$
Assumptions
You made a lot of assumptions with this code, which you either did not mention during the interview or you incorrectly assumed to be true of the question. In other words, you were over thinking the problem.
#check if input is a list
if not isinstance(int_arr, list):
raise TypeError("Input shall be of type array.")
You should not care about the instance type. The type could easily have been a user defined type which behaves like a list or even another python built in. For example, python has both deque and array, and they both behave like a list, supporting the same operations as a list.
# check all elements are of type int
if not all(isinstance(item, int) for item in int_arr) :
raise ValueError("All elements in array shall be of type int.")
This is not necessarily true because lists or collections in general, in python can contain many different types. So insisting that the list contains only integers is just imposing a requirement which did not exist in the first place.
In closing, I would advice that you adhere to the KISS principle in future interviews and to ask questions or state your assumptions before diving into the code. Even if it doesn't sound like an assumption to you, make sure they know what is going on in your head either as you're coding or before you write your code. It might sound silly to say "Ok I will also make sure that I have been given a list", but you will be saving yourself a lot of grief when they reply, "Don't worry about that, just assume it's a list".
Check if array contains the sequence (1,3,4)
def check_sequence(arr):
return any((arr[i], arr[i + 1], arr[i + 2]) == (1,3,4) for i in range(len(arr) - 2))
$endgroup$
add a comment |
$begingroup$
Assumptions
You made a lot of assumptions with this code, which you either did not mention during the interview or you incorrectly assumed to be true of the question. In other words, you were over thinking the problem.
#check if input is a list
if not isinstance(int_arr, list):
raise TypeError("Input shall be of type array.")
You should not care about the instance type. The type could easily have been a user defined type which behaves like a list or even another python built in. For example, python has both deque and array, and they both behave like a list, supporting the same operations as a list.
# check all elements are of type int
if not all(isinstance(item, int) for item in int_arr) :
raise ValueError("All elements in array shall be of type int.")
This is not necessarily true because lists or collections in general, in python can contain many different types. So insisting that the list contains only integers is just imposing a requirement which did not exist in the first place.
In closing, I would advice that you adhere to the KISS principle in future interviews and to ask questions or state your assumptions before diving into the code. Even if it doesn't sound like an assumption to you, make sure they know what is going on in your head either as you're coding or before you write your code. It might sound silly to say "Ok I will also make sure that I have been given a list", but you will be saving yourself a lot of grief when they reply, "Don't worry about that, just assume it's a list".
Check if array contains the sequence (1,3,4)
def check_sequence(arr):
return any((arr[i], arr[i + 1], arr[i + 2]) == (1,3,4) for i in range(len(arr) - 2))
$endgroup$
Assumptions
You made a lot of assumptions with this code, which you either did not mention during the interview or you incorrectly assumed to be true of the question. In other words, you were over thinking the problem.
#check if input is a list
if not isinstance(int_arr, list):
raise TypeError("Input shall be of type array.")
You should not care about the instance type. The type could easily have been a user defined type which behaves like a list or even another python built in. For example, python has both deque and array, and they both behave like a list, supporting the same operations as a list.
# check all elements are of type int
if not all(isinstance(item, int) for item in int_arr) :
raise ValueError("All elements in array shall be of type int.")
This is not necessarily true because lists or collections in general, in python can contain many different types. So insisting that the list contains only integers is just imposing a requirement which did not exist in the first place.
In closing, I would advice that you adhere to the KISS principle in future interviews and to ask questions or state your assumptions before diving into the code. Even if it doesn't sound like an assumption to you, make sure they know what is going on in your head either as you're coding or before you write your code. It might sound silly to say "Ok I will also make sure that I have been given a list", but you will be saving yourself a lot of grief when they reply, "Don't worry about that, just assume it's a list".
Check if array contains the sequence (1,3,4)
def check_sequence(arr):
return any((arr[i], arr[i + 1], arr[i + 2]) == (1,3,4) for i in range(len(arr) - 2))
edited Sep 6 '18 at 15:35
answered Dec 15 '16 at 6:42
smac89smac89
1,306719
1,306719
add a comment |
add a comment |
$begingroup$
Is basic IF and FOR loop
def array134(nums):
if len(nums) < 3:
return False
test =[1, 3, 4]
for i in range(len(nums)):
test2 = nums[i:i+3]
if test2 == test:
return True
return False
New contributor
alinkl is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
$begingroup$
Welcome to Code Review! You have presented an alternative solution, but haven't reviewed the code. Please explain your reasoning (how your solution works and why it is better than the original) so that the author and other readers can learn from your thought process. Please read Why are alternative solutions not welcome?
$endgroup$
– Sᴀᴍ Onᴇᴌᴀ
3 hours ago
add a comment |
$begingroup$
Is basic IF and FOR loop
def array134(nums):
if len(nums) < 3:
return False
test =[1, 3, 4]
for i in range(len(nums)):
test2 = nums[i:i+3]
if test2 == test:
return True
return False
New contributor
alinkl is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
$begingroup$
Welcome to Code Review! You have presented an alternative solution, but haven't reviewed the code. Please explain your reasoning (how your solution works and why it is better than the original) so that the author and other readers can learn from your thought process. Please read Why are alternative solutions not welcome?
$endgroup$
– Sᴀᴍ Onᴇᴌᴀ
3 hours ago
add a comment |
$begingroup$
Is basic IF and FOR loop
def array134(nums):
if len(nums) < 3:
return False
test =[1, 3, 4]
for i in range(len(nums)):
test2 = nums[i:i+3]
if test2 == test:
return True
return False
New contributor
alinkl is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$endgroup$
Is basic IF and FOR loop
def array134(nums):
if len(nums) < 3:
return False
test =[1, 3, 4]
for i in range(len(nums)):
test2 = nums[i:i+3]
if test2 == test:
return True
return False
New contributor
alinkl is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
alinkl is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
answered 3 hours ago
alinklalinkl
1
1
New contributor
alinkl is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
alinkl is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
alinkl is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$begingroup$
Welcome to Code Review! You have presented an alternative solution, but haven't reviewed the code. Please explain your reasoning (how your solution works and why it is better than the original) so that the author and other readers can learn from your thought process. Please read Why are alternative solutions not welcome?
$endgroup$
– Sᴀᴍ Onᴇᴌᴀ
3 hours ago
add a comment |
$begingroup$
Welcome to Code Review! You have presented an alternative solution, but haven't reviewed the code. Please explain your reasoning (how your solution works and why it is better than the original) so that the author and other readers can learn from your thought process. Please read Why are alternative solutions not welcome?
$endgroup$
– Sᴀᴍ Onᴇᴌᴀ
3 hours ago
$begingroup$
Welcome to Code Review! You have presented an alternative solution, but haven't reviewed the code. Please explain your reasoning (how your solution works and why it is better than the original) so that the author and other readers can learn from your thought process. Please read Why are alternative solutions not welcome?
$endgroup$
– Sᴀᴍ Onᴇᴌᴀ
3 hours ago
$begingroup$
Welcome to Code Review! You have presented an alternative solution, but haven't reviewed the code. Please explain your reasoning (how your solution works and why it is better than the original) so that the author and other readers can learn from your thought process. Please read Why are alternative solutions not welcome?
$endgroup$
– Sᴀᴍ Onᴇᴌᴀ
3 hours ago
add a comment |
$begingroup$
This optimization allows you to reduce the number of times checking an element. It also eliminates the need to make a new iterator which you had created with range
# Loop through elements
index = 0
while index < (arr_len-2):
if int_arr[index] != 1:
index += 1
continue
if int_arr[index+1] != 3:
index += 1
continue
if int_arr[index+2] != 4:
index += 1
continue
return True
return False
$endgroup$
$begingroup$
What about the sequence [1,1,3,4]? The first test will find 1 and pass, the second test will not find a 3 and will therefore move on 2 places and miss the pattern that is there.
$endgroup$
– neil
Dec 14 '16 at 16:54
$begingroup$
You make a good point. I could add more if statements to fix that, but i'm not getting the top answer so its not worth it
$endgroup$
– Navidad20
Dec 14 '16 at 16:55
add a comment |
$begingroup$
This optimization allows you to reduce the number of times checking an element. It also eliminates the need to make a new iterator which you had created with range
# Loop through elements
index = 0
while index < (arr_len-2):
if int_arr[index] != 1:
index += 1
continue
if int_arr[index+1] != 3:
index += 1
continue
if int_arr[index+2] != 4:
index += 1
continue
return True
return False
$endgroup$
$begingroup$
What about the sequence [1,1,3,4]? The first test will find 1 and pass, the second test will not find a 3 and will therefore move on 2 places and miss the pattern that is there.
$endgroup$
– neil
Dec 14 '16 at 16:54
$begingroup$
You make a good point. I could add more if statements to fix that, but i'm not getting the top answer so its not worth it
$endgroup$
– Navidad20
Dec 14 '16 at 16:55
add a comment |
$begingroup$
This optimization allows you to reduce the number of times checking an element. It also eliminates the need to make a new iterator which you had created with range
# Loop through elements
index = 0
while index < (arr_len-2):
if int_arr[index] != 1:
index += 1
continue
if int_arr[index+1] != 3:
index += 1
continue
if int_arr[index+2] != 4:
index += 1
continue
return True
return False
$endgroup$
This optimization allows you to reduce the number of times checking an element. It also eliminates the need to make a new iterator which you had created with range
# Loop through elements
index = 0
while index < (arr_len-2):
if int_arr[index] != 1:
index += 1
continue
if int_arr[index+1] != 3:
index += 1
continue
if int_arr[index+2] != 4:
index += 1
continue
return True
return False
edited Dec 14 '16 at 17:00
answered Dec 14 '16 at 14:43
Navidad20Navidad20
992
992
$begingroup$
What about the sequence [1,1,3,4]? The first test will find 1 and pass, the second test will not find a 3 and will therefore move on 2 places and miss the pattern that is there.
$endgroup$
– neil
Dec 14 '16 at 16:54
$begingroup$
You make a good point. I could add more if statements to fix that, but i'm not getting the top answer so its not worth it
$endgroup$
– Navidad20
Dec 14 '16 at 16:55
add a comment |
$begingroup$
What about the sequence [1,1,3,4]? The first test will find 1 and pass, the second test will not find a 3 and will therefore move on 2 places and miss the pattern that is there.
$endgroup$
– neil
Dec 14 '16 at 16:54
$begingroup$
You make a good point. I could add more if statements to fix that, but i'm not getting the top answer so its not worth it
$endgroup$
– Navidad20
Dec 14 '16 at 16:55
$begingroup$
What about the sequence [1,1,3,4]? The first test will find 1 and pass, the second test will not find a 3 and will therefore move on 2 places and miss the pattern that is there.
$endgroup$
– neil
Dec 14 '16 at 16:54
$begingroup$
What about the sequence [1,1,3,4]? The first test will find 1 and pass, the second test will not find a 3 and will therefore move on 2 places and miss the pattern that is there.
$endgroup$
– neil
Dec 14 '16 at 16:54
$begingroup$
You make a good point. I could add more if statements to fix that, but i'm not getting the top answer so its not worth it
$endgroup$
– Navidad20
Dec 14 '16 at 16:55
$begingroup$
You make a good point. I could add more if statements to fix that, but i'm not getting the top answer so its not worth it
$endgroup$
– Navidad20
Dec 14 '16 at 16:55
add a comment |
$begingroup$
i dont know this approach is stupid or smart, i was given the same code in an assignment and converted the list to string and matched for the sequence
import re
def list123(nums):
#start writing your code here
str1="".join(str(x) for x in nums)
if re.search("YOUR SEQUENCE",str1):
return True
else:
return False
nums=[1,2,3,4,5]
print(list123(nums))
$endgroup$
1
$begingroup$
Welcome to Code Review! You have presented an alternative solution, but haven't reviewed the code. Please edit to show what aspects of the question code prompted you to write this version, and in what ways it's an improvement over the original.
$endgroup$
– Toby Speight
Sep 6 '18 at 15:22
1
$begingroup$
Welcome to Code Review! In addition to what @TobySpeight mentioned, if you haven't already, please see How do I write a good answer before posting an answer.
$endgroup$
– Sᴀᴍ Onᴇᴌᴀ
Sep 6 '18 at 15:27
add a comment |
$begingroup$
i dont know this approach is stupid or smart, i was given the same code in an assignment and converted the list to string and matched for the sequence
import re
def list123(nums):
#start writing your code here
str1="".join(str(x) for x in nums)
if re.search("YOUR SEQUENCE",str1):
return True
else:
return False
nums=[1,2,3,4,5]
print(list123(nums))
$endgroup$
1
$begingroup$
Welcome to Code Review! You have presented an alternative solution, but haven't reviewed the code. Please edit to show what aspects of the question code prompted you to write this version, and in what ways it's an improvement over the original.
$endgroup$
– Toby Speight
Sep 6 '18 at 15:22
1
$begingroup$
Welcome to Code Review! In addition to what @TobySpeight mentioned, if you haven't already, please see How do I write a good answer before posting an answer.
$endgroup$
– Sᴀᴍ Onᴇᴌᴀ
Sep 6 '18 at 15:27
add a comment |
$begingroup$
i dont know this approach is stupid or smart, i was given the same code in an assignment and converted the list to string and matched for the sequence
import re
def list123(nums):
#start writing your code here
str1="".join(str(x) for x in nums)
if re.search("YOUR SEQUENCE",str1):
return True
else:
return False
nums=[1,2,3,4,5]
print(list123(nums))
$endgroup$
i dont know this approach is stupid or smart, i was given the same code in an assignment and converted the list to string and matched for the sequence
import re
def list123(nums):
#start writing your code here
str1="".join(str(x) for x in nums)
if re.search("YOUR SEQUENCE",str1):
return True
else:
return False
nums=[1,2,3,4,5]
print(list123(nums))
answered Sep 6 '18 at 15:06
Amar BalAmar Bal
11
11
1
$begingroup$
Welcome to Code Review! You have presented an alternative solution, but haven't reviewed the code. Please edit to show what aspects of the question code prompted you to write this version, and in what ways it's an improvement over the original.
$endgroup$
– Toby Speight
Sep 6 '18 at 15:22
1
$begingroup$
Welcome to Code Review! In addition to what @TobySpeight mentioned, if you haven't already, please see How do I write a good answer before posting an answer.
$endgroup$
– Sᴀᴍ Onᴇᴌᴀ
Sep 6 '18 at 15:27
add a comment |
1
$begingroup$
Welcome to Code Review! You have presented an alternative solution, but haven't reviewed the code. Please edit to show what aspects of the question code prompted you to write this version, and in what ways it's an improvement over the original.
$endgroup$
– Toby Speight
Sep 6 '18 at 15:22
1
$begingroup$
Welcome to Code Review! In addition to what @TobySpeight mentioned, if you haven't already, please see How do I write a good answer before posting an answer.
$endgroup$
– Sᴀᴍ Onᴇᴌᴀ
Sep 6 '18 at 15:27
1
1
$begingroup$
Welcome to Code Review! You have presented an alternative solution, but haven't reviewed the code. Please edit to show what aspects of the question code prompted you to write this version, and in what ways it's an improvement over the original.
$endgroup$
– Toby Speight
Sep 6 '18 at 15:22
$begingroup$
Welcome to Code Review! You have presented an alternative solution, but haven't reviewed the code. Please edit to show what aspects of the question code prompted you to write this version, and in what ways it's an improvement over the original.
$endgroup$
– Toby Speight
Sep 6 '18 at 15:22
1
1
$begingroup$
Welcome to Code Review! In addition to what @TobySpeight mentioned, if you haven't already, please see How do I write a good answer before posting an answer.
$endgroup$
– Sᴀᴍ Onᴇᴌᴀ
Sep 6 '18 at 15:27
$begingroup$
Welcome to Code Review! In addition to what @TobySpeight mentioned, if you haven't already, please see How do I write a good answer before posting an answer.
$endgroup$
– Sᴀᴍ Onᴇᴌᴀ
Sep 6 '18 at 15:27
add a comment |
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f149867%2fpython-code-to-check-if-an-array-has-a-sequence-1-3-4%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
5
$begingroup$
Well for one, Python lists can have multiple types of values, are you sure they required each array to have all ints. For example:
['a','b','c',1,3,4]seems like a valid sequence that would return false in your implementation$endgroup$
– Navidad20
Dec 14 '16 at 14:36
$begingroup$
Maybe you should have used
xrange? ;)$endgroup$
– Tamoghna Chowdhury
Dec 14 '16 at 14:38
1
$begingroup$
Also, they asked about an array. Maybe you should have used a
numpy.arrayinstead of a list? With NumPy arrays, this could be done in 2 function calls.$endgroup$
– Tamoghna Chowdhury
Dec 14 '16 at 14:43
3
$begingroup$
As I said in another comment, there are so many unknown points in this question that I think the main reason for rejection may actually be him making assumptions instead of asking questions.
$endgroup$
– ChatterOne
Dec 14 '16 at 15:18
$begingroup$
Why not just
str([1,3,4])[1:-1] in str([array])?$endgroup$
– Samuel Shifterovich
Dec 14 '16 at 21:41