41–50 of 55 posts
[1] https://github.com/ExPHAT/twitter-sort/blob/master/main.py#L...
While potentially more efficient than bogosort for larger input size, this sorting algorithm has a serious limitation. I am of course talking about being limited to 140 characters per tweet. This seriously restricts maximum input size you can sort, which in turn severely cuts down on potential applications of this technology. Moreover, without deployed SAAS (sorting as a service) bot, algorithm is not deterministic w…
1 - gzip content to store in a tweet. You could squeeze more out.
2 - store the content in an image and standardize on an OCR library
3 - use twitlonger.com for larger messages
EDIT: Anyway I thought app.net was meant to solve all this?
While potentially more efficient than bogosort for larger input size, this sorting algorithm has a serious limitation. I am of course talking about being limited to 140 characters per tweet. This seriously restricts maximum input size you can sort, which in turn severely cuts down on potential applications of this technology. Moreover, without deployed SAAS (sorting as a service) bot, algorithm is not deterministic w…
Regarding maximum input size, I'm sure it can be forked to implement a tweet-sharding approach.
If that turns out to be a bit slow, there's always StackSort: http://gkoberger.github.io/stacksort
This is terrible programming - better to generalize it as a decorator so you can use twitter for any method.
While potentially more efficient than bogosort for larger input size, this sorting algorithm has a serious limitation. I am of course talking about being limited to 140 characters per tweet. This seriously restricts maximum input size you can sort, which in turn severely cuts down on potential applications of this technology. Moreover, without deployed SAAS (sorting as a service) bot, algorithm is not deterministic w…
Hi, I'm with Google Corporate Development and I'd love to talk about your algorithm.
Earlier quoted context omitted.
Big-O notation refers to the worst case runtime of an algorithm. I have no idea where this misconception comes from. Big-O notation is a type of bound on a function's growth rate. That function can represent anything. Best case performance, worst case performance, average case performance, memory usage, how many times you are likely to phone someone while you wait, etc. The standard example showing this is that hash…
that's not 100% true as well, you got omega and theta and others as well for the other cases. Edit: See http://stackoverflow.com/questions/471199/what-is-the-differ...
The S.O. link you posted contains an Accepted Answer which is also exactly correct, and happens to agree exactly with btilly.
I don't know what you think you're saying, or what you think that SO link supports. But it is NOT the case that "big O is worst-case", nor is it the case that the variants like little-o/big-theta/big-omega/etc have anything to do with best/worst/average case. The relevant sense of "upper bound" is not some kind of subtle synonym for "worst case".
give me a break, it does O(n^2) work to verify that the response is sorted and contains the same values.
1. check that the list is the same size
2. for every element in the original, do a binary search in the new list; fail if not found
3. check that the element following the element you found is greater than it
This should make it run in the time it takes to do a binary search times the list size, or O(n * log n)