Hope you’re ready for another challenge! Let’s get started with Day 3.
Today’s challenge is modified from user @jayeshcp on CodeWars.
Write a function that returns the number (count) of vowels in a given string. Letters considered as vowels are: a, i, e, o, and u. The function should be able to take all types of characters as input, including lower case letters, upper case letters, symbols, and numbers.
In this challenge, you should be able to efficiently ignore spaces and symbols and discern between capital and lowercase letters. Beginners can start with only lowercase letters and move up from there. It’ll definitely get you ready for tomorrow.
Happy coding!~
Thank you to CodeWars, who has licensed redistribution of this challenge under the 2-Clause BSD License!
Want to propose a challenge for a future post? Email yo+challenge@dev.to with your suggestions!
Oldest comments (82)
[...'aeiou'].includes
Fixed, thanks!
Hi, i loved this solution. Took me a bit to get my head around the use of reduce here and it's awesome. Thanks. I learned something nice today.
Cool., I didn't know we can use spread on a string. 👍🏻
Oh I've been waiting for this one all morning! Decided I wanted to go all out on this on!
Come check it out while I work my way through this challenge! I'm live now and about to get started!
twitch.tv/coreyja
Here is my Rust solution all TDD'ed out!
I'm still live streaming as I type this out, but once I wrap up I'll post a link to the video here!
Ahhh! :panic:
Turns out OBS didn't want to behave for me today, and split my stream into 2 and dies before I finished, but we got almost all of it recorded! Learnings for next stream!
Links to the video that recorded for the longest here
Livestream - Dev.to Challenge Vowel Count in Rust
Corey Alexander ・ Jun 30 ・ 1 min read
JavaScript:
Demo on CodePen.
I think this is the best solution if you're ok with regex.
Nice solution, mine was similar in using regex match, but not as short. This one will error on a string without any vowels because
match
will return anull
which doesn't have a length.That's a good point. This could be avoided by checking if the result of the match is null and using an empty string instead. Something like this:
I also used template literals before the
match
so numeric values or null would be process too... and now the code is even uglier than before :PTypo
${s}
Good catch! I corrected it. Thank you for letting me know!
Thinking the string as a Set with O(1) for look up operations: solution is O(n), where n = len(str)
JS lambda way
Here is my try at it in JavaScript:
Ruby
Long Solution (my first solution)
Short Solution (my refactored solution)
It would be interesting to know if
str.count("aeiouAEIOU")
was faster, or if reordering the letters to try to get the most likely match first was better – e.g.str.count("eiaouEIAOU")
Not sure if I follow. O(n log n) is worst than O(n). Insertions in a binary tree are expensive to keep it balanced.
If you use a set or hashmap assuming zero collisions, the look up is O(1). Then the bottke neck is in the string iteration. Right?
TI-Basic Calculator, where the string is in
Ans
:And yes you can omit ending parens, which helps saves some bytes (:
We don't care about the vowels being ordered for this problem, so you'd be paying extra time (vs. a hash-based set, or just hard-coded equality checks) for a property you're not using.
Clojure:
You also have to traverse the tree to get to the next letter. But I see what you mean. Only counting equality checks, hard-coding behaves like a linear search. My bad.
I think you might still be missing Brian's point that a hash set has O(1) lookup time, which is faster than the tree set's O(log n).
(On paper. Real-world implementations vary. e.g. Ruby's hashes just do linear search at this size.)
JavaScript, using reduce:
Nim