Find the majority element, which appears more than half the time Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)Perm-Missing-Elem: 100% functional score, but only 60% performanceDetermining the existence of string IntersectionsFind the dominator in an array of integersJavaScript : Search highest ID in JSON-structure. Increment & return itFind the most frequent element in a sequence without copying elementsReconstruct a string, given a list of subsequence tripletsReturn a sorted ordering of courses such that we can finish all coursesHash table solution to twoSumSum of a sublistFind the elements that appear only once
Is there a kind of relay only consumes power when switching?
When was Kai Tak permanently closed to cargo service?
Wu formula for manifolds with boundary
How would a mousetrap for use in space work?
What does "lightly crushed" mean for cardamon pods?
Do jazz musicians improvise on the parent scale in addition to the chord-scales?
Why do we bend a book to keep it straight?
What is the longest distance a player character can jump in one leap?
Is it fair for a professor to grade us on the possession of past papers?
What does the "x" in "x86" represent?
What's the meaning of "fortified infraction restraint"?
Why wasn't DOSKEY integrated with COMMAND.COM?
How to Make a Beautiful Stacked 3D Plot
Is grep documentation wrong?
Is it cost-effective to upgrade an old-ish Giant Escape R3 commuter bike with entry-level branded parts (wheels, drivetrain)?
What does this Jacques Hadamard quote mean?
How to answer "Have you ever been terminated?"
Should I use a zero-interest credit card for a large one-time purchase?
How could we fake a moon landing now?
If a VARCHAR(MAX) column is included in an index, is the entire value always stored in the index page(s)?
Amount of permutations on an NxNxN Rubik's Cube
Is it ethical to give a final exam after the professor has quit before teaching the remaining chapters of the course?
Do wooden building fires get hotter than 600°C?
Most bit efficient text communication method?
Find the majority element, which appears more than half the time
Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)Perm-Missing-Elem: 100% functional score, but only 60% performanceDetermining the existence of string IntersectionsFind the dominator in an array of integersJavaScript : Search highest ID in JSON-structure. Increment & return itFind the most frequent element in a sequence without copying elementsReconstruct a string, given a list of subsequence tripletsReturn a sorted ordering of courses such that we can finish all coursesHash table solution to twoSumSum of a sublistFind the elements that appear only once
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
$begingroup$
The task:
Given a list of elements, find the majority element, which appears
more than half the time (> floor(len(lst) / 2.0)).
You can assume that such element exists.
For example, given [1, 2, 1, 1, 3, 4, 0], return 1.
My solution:
const lst = [1, 2, 1, 1, 3, 4, 0];
const findMajorityElem = lst => lst.reduce((acc, x) => acc.major[1] < acc[x]) acc.major = [x, acc[x]];
return acc;
, major: null).major[0];
console.log(findMajorityElem(lst));
javascript algorithm programming-challenge functional-programming
$endgroup$
add a comment |
$begingroup$
The task:
Given a list of elements, find the majority element, which appears
more than half the time (> floor(len(lst) / 2.0)).
You can assume that such element exists.
For example, given [1, 2, 1, 1, 3, 4, 0], return 1.
My solution:
const lst = [1, 2, 1, 1, 3, 4, 0];
const findMajorityElem = lst => lst.reduce((acc, x) => acc.major[1] < acc[x]) acc.major = [x, acc[x]];
return acc;
, major: null).major[0];
console.log(findMajorityElem(lst));
javascript algorithm programming-challenge functional-programming
$endgroup$
5
$begingroup$
In the example[1, 2, 1, 1, 3, 4, 0]
, 1 appears 3 times,floor(len(lst) / 2.0))
is 3, and since 3 is not more than 3, therefore 1 is not the majority element, and the example list doesn't have a majority element.
$endgroup$
– janos
Apr 1 at 16:47
$begingroup$
@janos the example is inaccurate. However it explicitly says I can assume that there exists a majority element
$endgroup$
– thadeuszlay
Apr 1 at 16:54
add a comment |
$begingroup$
The task:
Given a list of elements, find the majority element, which appears
more than half the time (> floor(len(lst) / 2.0)).
You can assume that such element exists.
For example, given [1, 2, 1, 1, 3, 4, 0], return 1.
My solution:
const lst = [1, 2, 1, 1, 3, 4, 0];
const findMajorityElem = lst => lst.reduce((acc, x) => acc.major[1] < acc[x]) acc.major = [x, acc[x]];
return acc;
, major: null).major[0];
console.log(findMajorityElem(lst));
javascript algorithm programming-challenge functional-programming
$endgroup$
The task:
Given a list of elements, find the majority element, which appears
more than half the time (> floor(len(lst) / 2.0)).
You can assume that such element exists.
For example, given [1, 2, 1, 1, 3, 4, 0], return 1.
My solution:
const lst = [1, 2, 1, 1, 3, 4, 0];
const findMajorityElem = lst => lst.reduce((acc, x) => acc.major[1] < acc[x]) acc.major = [x, acc[x]];
return acc;
, major: null).major[0];
console.log(findMajorityElem(lst));
javascript algorithm programming-challenge functional-programming
javascript algorithm programming-challenge functional-programming
edited Apr 1 at 12:08
thadeuszlay
asked Apr 1 at 12:00
thadeuszlaythadeuszlay
941616
941616
5
$begingroup$
In the example[1, 2, 1, 1, 3, 4, 0]
, 1 appears 3 times,floor(len(lst) / 2.0))
is 3, and since 3 is not more than 3, therefore 1 is not the majority element, and the example list doesn't have a majority element.
$endgroup$
– janos
Apr 1 at 16:47
$begingroup$
@janos the example is inaccurate. However it explicitly says I can assume that there exists a majority element
$endgroup$
– thadeuszlay
Apr 1 at 16:54
add a comment |
5
$begingroup$
In the example[1, 2, 1, 1, 3, 4, 0]
, 1 appears 3 times,floor(len(lst) / 2.0))
is 3, and since 3 is not more than 3, therefore 1 is not the majority element, and the example list doesn't have a majority element.
$endgroup$
– janos
Apr 1 at 16:47
$begingroup$
@janos the example is inaccurate. However it explicitly says I can assume that there exists a majority element
$endgroup$
– thadeuszlay
Apr 1 at 16:54
5
5
$begingroup$
In the example
[1, 2, 1, 1, 3, 4, 0]
, 1 appears 3 times, floor(len(lst) / 2.0))
is 3, and since 3 is not more than 3, therefore 1 is not the majority element, and the example list doesn't have a majority element.$endgroup$
– janos
Apr 1 at 16:47
$begingroup$
In the example
[1, 2, 1, 1, 3, 4, 0]
, 1 appears 3 times, floor(len(lst) / 2.0))
is 3, and since 3 is not more than 3, therefore 1 is not the majority element, and the example list doesn't have a majority element.$endgroup$
– janos
Apr 1 at 16:47
$begingroup$
@janos the example is inaccurate. However it explicitly says I can assume that there exists a majority element
$endgroup$
– thadeuszlay
Apr 1 at 16:54
$begingroup$
@janos the example is inaccurate. However it explicitly says I can assume that there exists a majority element
$endgroup$
– thadeuszlay
Apr 1 at 16:54
add a comment |
3 Answers
3
active
oldest
votes
$begingroup$
If it is known that a majority element exists, then the efficient algorithm to use is the Boyer-Moore majority vote algorithm, which requires only O(1) space.
$endgroup$
2
$begingroup$
That's a little deceptive... it's $Omega(log n)$ space in terms of bit complexity.
$endgroup$
– Charles
Apr 1 at 20:44
2
$begingroup$
@Charles Why would you want to break it down in terms of bits?
$endgroup$
– 200_success
Apr 2 at 1:18
1
$begingroup$
I think the question should be, why hide the size of the space requirements? Calling O(1) is, IMO, deceptive: it makes it sound like a fixed amount of space suffices for arbitrarily large arrays, but the larger the array the larger the numbers you need to store, and the larger the numbers the larger the space they take up. Sure, only logarithmically so, but then let's call it logarithmic space, not constant space. It's only constant space in the sense that you use a constant number of words when the words themselves grow logarithmically, but then you're being tricky and hiding the real size.
$endgroup$
– Charles
Apr 2 at 1:59
1
$begingroup$
@Charles I don't understand why there's necessarily a correlation between the size of the array and the size of the values within it. To me those are completely orthogonal concerns. It also doesn't seem particularly relevant here anyway, since Javascript's numbers are fixed-size.
$endgroup$
– Kyle
Apr 2 at 2:31
1
$begingroup$
@Charles I don’t think that’s entirely fair. Unlike algorithms and structures that meaningfully depend on bit width (radix sort, van Emde Boas trees, ...), this one only has a dependence on it in that it needs to store an array index and an array element (an offline version can also get away with storing two indices instead). That is, it needs as much space as an array access, and you generally want to count this as O(1). Yes, that means you’re counting words, not bits, but that’s the standard cost model, and it makes perfect sense outside of specialized applications.
$endgroup$
– Alex Shpilkin
Apr 2 at 14:17
|
show 2 more comments
$begingroup$
@200_success's suggestion seems like the right play here.
That said, I thought it was worth pointing out a couple small improvements to your approach:
major
need only be the element itself (since you can look up its value in the accumulator)- Since you tagged this
functional-programming
, you can use expressions everywhere, and avoid theif
statement.
Revised code:
const findMajorityElem = lst => lst.reduce((acc, x) => , major: null).major
And just for fun, again based on your tag, here's a single-expression solution in Ramda. Again, I don't recommend actually using this given that Boyer-Moore exists:
pipe(
groupBy(identity),
map(length),
toPairs,
converge( reduce(maxBy(last)), [head, identity] ),
head,
parseInt
)(lst)
You can try it here
$endgroup$
add a comment |
$begingroup$
If the number exists, it should be done like this and shorter.
let result =
[2,3,4,5,1,1,1,2,2,22,2,2,2,2,2,2,2,2,1,1,33,3,2,1,1,1,1,2,2,2,2,2].reduce( (a ,b) =>
console.log(a)
return a.length == null ? ( a != b ? [] : a.concat(b)):
a.length == 0 ? [b] :
a[a.length-1] == b ? a.concat(b) :
a.slice(0,a.length-2) ;
)[0]
console.log(result) //2
$endgroup$
1
$begingroup$
Welcome to Code Review!and shorter
is a bit short on what deserves improvement in the code in the question and why the way proposed is better.
$endgroup$
– greybeard
Apr 2 at 5:42
$begingroup$
Shorter means in Javascript, you may write in a neater way. It’s an implementation of voter algorithm. Just compare the last element in result with a new element, if they are different, just cancel them. Then the final survived element will be the result. Time is o(n) and if in-place space is o(1).
$endgroup$
– E.Coms
Apr 2 at 11:41
add a comment |
Your Answer
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%2f216648%2ffind-the-majority-element-which-appears-more-than-half-the-time%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
If it is known that a majority element exists, then the efficient algorithm to use is the Boyer-Moore majority vote algorithm, which requires only O(1) space.
$endgroup$
2
$begingroup$
That's a little deceptive... it's $Omega(log n)$ space in terms of bit complexity.
$endgroup$
– Charles
Apr 1 at 20:44
2
$begingroup$
@Charles Why would you want to break it down in terms of bits?
$endgroup$
– 200_success
Apr 2 at 1:18
1
$begingroup$
I think the question should be, why hide the size of the space requirements? Calling O(1) is, IMO, deceptive: it makes it sound like a fixed amount of space suffices for arbitrarily large arrays, but the larger the array the larger the numbers you need to store, and the larger the numbers the larger the space they take up. Sure, only logarithmically so, but then let's call it logarithmic space, not constant space. It's only constant space in the sense that you use a constant number of words when the words themselves grow logarithmically, but then you're being tricky and hiding the real size.
$endgroup$
– Charles
Apr 2 at 1:59
1
$begingroup$
@Charles I don't understand why there's necessarily a correlation between the size of the array and the size of the values within it. To me those are completely orthogonal concerns. It also doesn't seem particularly relevant here anyway, since Javascript's numbers are fixed-size.
$endgroup$
– Kyle
Apr 2 at 2:31
1
$begingroup$
@Charles I don’t think that’s entirely fair. Unlike algorithms and structures that meaningfully depend on bit width (radix sort, van Emde Boas trees, ...), this one only has a dependence on it in that it needs to store an array index and an array element (an offline version can also get away with storing two indices instead). That is, it needs as much space as an array access, and you generally want to count this as O(1). Yes, that means you’re counting words, not bits, but that’s the standard cost model, and it makes perfect sense outside of specialized applications.
$endgroup$
– Alex Shpilkin
Apr 2 at 14:17
|
show 2 more comments
$begingroup$
If it is known that a majority element exists, then the efficient algorithm to use is the Boyer-Moore majority vote algorithm, which requires only O(1) space.
$endgroup$
2
$begingroup$
That's a little deceptive... it's $Omega(log n)$ space in terms of bit complexity.
$endgroup$
– Charles
Apr 1 at 20:44
2
$begingroup$
@Charles Why would you want to break it down in terms of bits?
$endgroup$
– 200_success
Apr 2 at 1:18
1
$begingroup$
I think the question should be, why hide the size of the space requirements? Calling O(1) is, IMO, deceptive: it makes it sound like a fixed amount of space suffices for arbitrarily large arrays, but the larger the array the larger the numbers you need to store, and the larger the numbers the larger the space they take up. Sure, only logarithmically so, but then let's call it logarithmic space, not constant space. It's only constant space in the sense that you use a constant number of words when the words themselves grow logarithmically, but then you're being tricky and hiding the real size.
$endgroup$
– Charles
Apr 2 at 1:59
1
$begingroup$
@Charles I don't understand why there's necessarily a correlation between the size of the array and the size of the values within it. To me those are completely orthogonal concerns. It also doesn't seem particularly relevant here anyway, since Javascript's numbers are fixed-size.
$endgroup$
– Kyle
Apr 2 at 2:31
1
$begingroup$
@Charles I don’t think that’s entirely fair. Unlike algorithms and structures that meaningfully depend on bit width (radix sort, van Emde Boas trees, ...), this one only has a dependence on it in that it needs to store an array index and an array element (an offline version can also get away with storing two indices instead). That is, it needs as much space as an array access, and you generally want to count this as O(1). Yes, that means you’re counting words, not bits, but that’s the standard cost model, and it makes perfect sense outside of specialized applications.
$endgroup$
– Alex Shpilkin
Apr 2 at 14:17
|
show 2 more comments
$begingroup$
If it is known that a majority element exists, then the efficient algorithm to use is the Boyer-Moore majority vote algorithm, which requires only O(1) space.
$endgroup$
If it is known that a majority element exists, then the efficient algorithm to use is the Boyer-Moore majority vote algorithm, which requires only O(1) space.
answered Apr 1 at 12:38
200_success200_success
131k17157422
131k17157422
2
$begingroup$
That's a little deceptive... it's $Omega(log n)$ space in terms of bit complexity.
$endgroup$
– Charles
Apr 1 at 20:44
2
$begingroup$
@Charles Why would you want to break it down in terms of bits?
$endgroup$
– 200_success
Apr 2 at 1:18
1
$begingroup$
I think the question should be, why hide the size of the space requirements? Calling O(1) is, IMO, deceptive: it makes it sound like a fixed amount of space suffices for arbitrarily large arrays, but the larger the array the larger the numbers you need to store, and the larger the numbers the larger the space they take up. Sure, only logarithmically so, but then let's call it logarithmic space, not constant space. It's only constant space in the sense that you use a constant number of words when the words themselves grow logarithmically, but then you're being tricky and hiding the real size.
$endgroup$
– Charles
Apr 2 at 1:59
1
$begingroup$
@Charles I don't understand why there's necessarily a correlation between the size of the array and the size of the values within it. To me those are completely orthogonal concerns. It also doesn't seem particularly relevant here anyway, since Javascript's numbers are fixed-size.
$endgroup$
– Kyle
Apr 2 at 2:31
1
$begingroup$
@Charles I don’t think that’s entirely fair. Unlike algorithms and structures that meaningfully depend on bit width (radix sort, van Emde Boas trees, ...), this one only has a dependence on it in that it needs to store an array index and an array element (an offline version can also get away with storing two indices instead). That is, it needs as much space as an array access, and you generally want to count this as O(1). Yes, that means you’re counting words, not bits, but that’s the standard cost model, and it makes perfect sense outside of specialized applications.
$endgroup$
– Alex Shpilkin
Apr 2 at 14:17
|
show 2 more comments
2
$begingroup$
That's a little deceptive... it's $Omega(log n)$ space in terms of bit complexity.
$endgroup$
– Charles
Apr 1 at 20:44
2
$begingroup$
@Charles Why would you want to break it down in terms of bits?
$endgroup$
– 200_success
Apr 2 at 1:18
1
$begingroup$
I think the question should be, why hide the size of the space requirements? Calling O(1) is, IMO, deceptive: it makes it sound like a fixed amount of space suffices for arbitrarily large arrays, but the larger the array the larger the numbers you need to store, and the larger the numbers the larger the space they take up. Sure, only logarithmically so, but then let's call it logarithmic space, not constant space. It's only constant space in the sense that you use a constant number of words when the words themselves grow logarithmically, but then you're being tricky and hiding the real size.
$endgroup$
– Charles
Apr 2 at 1:59
1
$begingroup$
@Charles I don't understand why there's necessarily a correlation between the size of the array and the size of the values within it. To me those are completely orthogonal concerns. It also doesn't seem particularly relevant here anyway, since Javascript's numbers are fixed-size.
$endgroup$
– Kyle
Apr 2 at 2:31
1
$begingroup$
@Charles I don’t think that’s entirely fair. Unlike algorithms and structures that meaningfully depend on bit width (radix sort, van Emde Boas trees, ...), this one only has a dependence on it in that it needs to store an array index and an array element (an offline version can also get away with storing two indices instead). That is, it needs as much space as an array access, and you generally want to count this as O(1). Yes, that means you’re counting words, not bits, but that’s the standard cost model, and it makes perfect sense outside of specialized applications.
$endgroup$
– Alex Shpilkin
Apr 2 at 14:17
2
2
$begingroup$
That's a little deceptive... it's $Omega(log n)$ space in terms of bit complexity.
$endgroup$
– Charles
Apr 1 at 20:44
$begingroup$
That's a little deceptive... it's $Omega(log n)$ space in terms of bit complexity.
$endgroup$
– Charles
Apr 1 at 20:44
2
2
$begingroup$
@Charles Why would you want to break it down in terms of bits?
$endgroup$
– 200_success
Apr 2 at 1:18
$begingroup$
@Charles Why would you want to break it down in terms of bits?
$endgroup$
– 200_success
Apr 2 at 1:18
1
1
$begingroup$
I think the question should be, why hide the size of the space requirements? Calling O(1) is, IMO, deceptive: it makes it sound like a fixed amount of space suffices for arbitrarily large arrays, but the larger the array the larger the numbers you need to store, and the larger the numbers the larger the space they take up. Sure, only logarithmically so, but then let's call it logarithmic space, not constant space. It's only constant space in the sense that you use a constant number of words when the words themselves grow logarithmically, but then you're being tricky and hiding the real size.
$endgroup$
– Charles
Apr 2 at 1:59
$begingroup$
I think the question should be, why hide the size of the space requirements? Calling O(1) is, IMO, deceptive: it makes it sound like a fixed amount of space suffices for arbitrarily large arrays, but the larger the array the larger the numbers you need to store, and the larger the numbers the larger the space they take up. Sure, only logarithmically so, but then let's call it logarithmic space, not constant space. It's only constant space in the sense that you use a constant number of words when the words themselves grow logarithmically, but then you're being tricky and hiding the real size.
$endgroup$
– Charles
Apr 2 at 1:59
1
1
$begingroup$
@Charles I don't understand why there's necessarily a correlation between the size of the array and the size of the values within it. To me those are completely orthogonal concerns. It also doesn't seem particularly relevant here anyway, since Javascript's numbers are fixed-size.
$endgroup$
– Kyle
Apr 2 at 2:31
$begingroup$
@Charles I don't understand why there's necessarily a correlation between the size of the array and the size of the values within it. To me those are completely orthogonal concerns. It also doesn't seem particularly relevant here anyway, since Javascript's numbers are fixed-size.
$endgroup$
– Kyle
Apr 2 at 2:31
1
1
$begingroup$
@Charles I don’t think that’s entirely fair. Unlike algorithms and structures that meaningfully depend on bit width (radix sort, van Emde Boas trees, ...), this one only has a dependence on it in that it needs to store an array index and an array element (an offline version can also get away with storing two indices instead). That is, it needs as much space as an array access, and you generally want to count this as O(1). Yes, that means you’re counting words, not bits, but that’s the standard cost model, and it makes perfect sense outside of specialized applications.
$endgroup$
– Alex Shpilkin
Apr 2 at 14:17
$begingroup$
@Charles I don’t think that’s entirely fair. Unlike algorithms and structures that meaningfully depend on bit width (radix sort, van Emde Boas trees, ...), this one only has a dependence on it in that it needs to store an array index and an array element (an offline version can also get away with storing two indices instead). That is, it needs as much space as an array access, and you generally want to count this as O(1). Yes, that means you’re counting words, not bits, but that’s the standard cost model, and it makes perfect sense outside of specialized applications.
$endgroup$
– Alex Shpilkin
Apr 2 at 14:17
|
show 2 more comments
$begingroup$
@200_success's suggestion seems like the right play here.
That said, I thought it was worth pointing out a couple small improvements to your approach:
major
need only be the element itself (since you can look up its value in the accumulator)- Since you tagged this
functional-programming
, you can use expressions everywhere, and avoid theif
statement.
Revised code:
const findMajorityElem = lst => lst.reduce((acc, x) => , major: null).major
And just for fun, again based on your tag, here's a single-expression solution in Ramda. Again, I don't recommend actually using this given that Boyer-Moore exists:
pipe(
groupBy(identity),
map(length),
toPairs,
converge( reduce(maxBy(last)), [head, identity] ),
head,
parseInt
)(lst)
You can try it here
$endgroup$
add a comment |
$begingroup$
@200_success's suggestion seems like the right play here.
That said, I thought it was worth pointing out a couple small improvements to your approach:
major
need only be the element itself (since you can look up its value in the accumulator)- Since you tagged this
functional-programming
, you can use expressions everywhere, and avoid theif
statement.
Revised code:
const findMajorityElem = lst => lst.reduce((acc, x) => , major: null).major
And just for fun, again based on your tag, here's a single-expression solution in Ramda. Again, I don't recommend actually using this given that Boyer-Moore exists:
pipe(
groupBy(identity),
map(length),
toPairs,
converge( reduce(maxBy(last)), [head, identity] ),
head,
parseInt
)(lst)
You can try it here
$endgroup$
add a comment |
$begingroup$
@200_success's suggestion seems like the right play here.
That said, I thought it was worth pointing out a couple small improvements to your approach:
major
need only be the element itself (since you can look up its value in the accumulator)- Since you tagged this
functional-programming
, you can use expressions everywhere, and avoid theif
statement.
Revised code:
const findMajorityElem = lst => lst.reduce((acc, x) => , major: null).major
And just for fun, again based on your tag, here's a single-expression solution in Ramda. Again, I don't recommend actually using this given that Boyer-Moore exists:
pipe(
groupBy(identity),
map(length),
toPairs,
converge( reduce(maxBy(last)), [head, identity] ),
head,
parseInt
)(lst)
You can try it here
$endgroup$
@200_success's suggestion seems like the right play here.
That said, I thought it was worth pointing out a couple small improvements to your approach:
major
need only be the element itself (since you can look up its value in the accumulator)- Since you tagged this
functional-programming
, you can use expressions everywhere, and avoid theif
statement.
Revised code:
const findMajorityElem = lst => lst.reduce((acc, x) => , major: null).major
And just for fun, again based on your tag, here's a single-expression solution in Ramda. Again, I don't recommend actually using this given that Boyer-Moore exists:
pipe(
groupBy(identity),
map(length),
toPairs,
converge( reduce(maxBy(last)), [head, identity] ),
head,
parseInt
)(lst)
You can try it here
answered Apr 1 at 13:03
JonahJonah
3,521718
3,521718
add a comment |
add a comment |
$begingroup$
If the number exists, it should be done like this and shorter.
let result =
[2,3,4,5,1,1,1,2,2,22,2,2,2,2,2,2,2,2,1,1,33,3,2,1,1,1,1,2,2,2,2,2].reduce( (a ,b) =>
console.log(a)
return a.length == null ? ( a != b ? [] : a.concat(b)):
a.length == 0 ? [b] :
a[a.length-1] == b ? a.concat(b) :
a.slice(0,a.length-2) ;
)[0]
console.log(result) //2
$endgroup$
1
$begingroup$
Welcome to Code Review!and shorter
is a bit short on what deserves improvement in the code in the question and why the way proposed is better.
$endgroup$
– greybeard
Apr 2 at 5:42
$begingroup$
Shorter means in Javascript, you may write in a neater way. It’s an implementation of voter algorithm. Just compare the last element in result with a new element, if they are different, just cancel them. Then the final survived element will be the result. Time is o(n) and if in-place space is o(1).
$endgroup$
– E.Coms
Apr 2 at 11:41
add a comment |
$begingroup$
If the number exists, it should be done like this and shorter.
let result =
[2,3,4,5,1,1,1,2,2,22,2,2,2,2,2,2,2,2,1,1,33,3,2,1,1,1,1,2,2,2,2,2].reduce( (a ,b) =>
console.log(a)
return a.length == null ? ( a != b ? [] : a.concat(b)):
a.length == 0 ? [b] :
a[a.length-1] == b ? a.concat(b) :
a.slice(0,a.length-2) ;
)[0]
console.log(result) //2
$endgroup$
1
$begingroup$
Welcome to Code Review!and shorter
is a bit short on what deserves improvement in the code in the question and why the way proposed is better.
$endgroup$
– greybeard
Apr 2 at 5:42
$begingroup$
Shorter means in Javascript, you may write in a neater way. It’s an implementation of voter algorithm. Just compare the last element in result with a new element, if they are different, just cancel them. Then the final survived element will be the result. Time is o(n) and if in-place space is o(1).
$endgroup$
– E.Coms
Apr 2 at 11:41
add a comment |
$begingroup$
If the number exists, it should be done like this and shorter.
let result =
[2,3,4,5,1,1,1,2,2,22,2,2,2,2,2,2,2,2,1,1,33,3,2,1,1,1,1,2,2,2,2,2].reduce( (a ,b) =>
console.log(a)
return a.length == null ? ( a != b ? [] : a.concat(b)):
a.length == 0 ? [b] :
a[a.length-1] == b ? a.concat(b) :
a.slice(0,a.length-2) ;
)[0]
console.log(result) //2
$endgroup$
If the number exists, it should be done like this and shorter.
let result =
[2,3,4,5,1,1,1,2,2,22,2,2,2,2,2,2,2,2,1,1,33,3,2,1,1,1,1,2,2,2,2,2].reduce( (a ,b) =>
console.log(a)
return a.length == null ? ( a != b ? [] : a.concat(b)):
a.length == 0 ? [b] :
a[a.length-1] == b ? a.concat(b) :
a.slice(0,a.length-2) ;
)[0]
console.log(result) //2
edited Apr 2 at 0:37
answered Apr 2 at 0:27
E.ComsE.Coms
1113
1113
1
$begingroup$
Welcome to Code Review!and shorter
is a bit short on what deserves improvement in the code in the question and why the way proposed is better.
$endgroup$
– greybeard
Apr 2 at 5:42
$begingroup$
Shorter means in Javascript, you may write in a neater way. It’s an implementation of voter algorithm. Just compare the last element in result with a new element, if they are different, just cancel them. Then the final survived element will be the result. Time is o(n) and if in-place space is o(1).
$endgroup$
– E.Coms
Apr 2 at 11:41
add a comment |
1
$begingroup$
Welcome to Code Review!and shorter
is a bit short on what deserves improvement in the code in the question and why the way proposed is better.
$endgroup$
– greybeard
Apr 2 at 5:42
$begingroup$
Shorter means in Javascript, you may write in a neater way. It’s an implementation of voter algorithm. Just compare the last element in result with a new element, if they are different, just cancel them. Then the final survived element will be the result. Time is o(n) and if in-place space is o(1).
$endgroup$
– E.Coms
Apr 2 at 11:41
1
1
$begingroup$
Welcome to Code Review!
and shorter
is a bit short on what deserves improvement in the code in the question and why the way proposed is better.$endgroup$
– greybeard
Apr 2 at 5:42
$begingroup$
Welcome to Code Review!
and shorter
is a bit short on what deserves improvement in the code in the question and why the way proposed is better.$endgroup$
– greybeard
Apr 2 at 5:42
$begingroup$
Shorter means in Javascript, you may write in a neater way. It’s an implementation of voter algorithm. Just compare the last element in result with a new element, if they are different, just cancel them. Then the final survived element will be the result. Time is o(n) and if in-place space is o(1).
$endgroup$
– E.Coms
Apr 2 at 11:41
$begingroup$
Shorter means in Javascript, you may write in a neater way. It’s an implementation of voter algorithm. Just compare the last element in result with a new element, if they are different, just cancel them. Then the final survived element will be the result. Time is o(n) and if in-place space is o(1).
$endgroup$
– E.Coms
Apr 2 at 11:41
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%2f216648%2ffind-the-majority-element-which-appears-more-than-half-the-time%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$
In the example
[1, 2, 1, 1, 3, 4, 0]
, 1 appears 3 times,floor(len(lst) / 2.0))
is 3, and since 3 is not more than 3, therefore 1 is not the majority element, and the example list doesn't have a majority element.$endgroup$
– janos
Apr 1 at 16:47
$begingroup$
@janos the example is inaccurate. However it explicitly says I can assume that there exists a majority element
$endgroup$
– thadeuszlay
Apr 1 at 16:54