Adjustment clear solution for Weekend Counter by veky - python coding challenges

Enable Javascript in your browser and then refresh this page, for a much enhanced experience.

Adjustment solution in Clear category for Weekend Counter by veky

def checkio(d1, d2):
    w1, w2 = d1.weekday(), d2.weekday()
    count = (d2 - d1).days // 7 * 2
    while True:
        count += w2 > 4
        if w1 == w2: return count
        w2 = (w2 - 1) % 7

Sept. 25, 2013

Comments:

bunnychai on Sept. 25, 2013, 3:09 p.m.
very readable...

veky on Sept. 25, 2013, 5:23 p.m.
You mean, considering I wrote it? :-)

Cjkjvfnby on Dec. 17, 2013, 8:59 p.m.
There is still some space to improve readability, variable names and return on same line as if. :)

veky on Dec. 17, 2013, 11:02 p.m.
Really? How would you name variables here? :-) And that return is just playing the role of break. I refuse to give it a separate line. It's the same, conceptually, as having the condition after the while keyword on a separate line. :-P

Cjkjvfnby on Dec. 17, 2013, 11:22 p.m.
Same as in my code :) Return is not playing roles it is returns:) And I don't see "same, conceptually" with while.

veky on Dec. 17, 2013, 11:42 p.m.
It also breaks the while loop. :-P You don't? Well... If exit is at the beginning, you write: <pre class='brush: python'>while not stopping: blah </pre> If exit is at the end, you write: <pre class='brush: python'>while True: blah if stopping: break </pre> If you insist on writing <pre class='brush: python'>if stopping: break </pre> then you have to insist on writing also <pre class='brush: python'>while (not stopping): blah </pre> for "while not x" has the same effect as "if x break". :-)

Cjkjvfnby on Dec. 18, 2013, 7:59 a.m.
On second example I will write break on next line. And in fourth in one line. I don't mix code logick and code style. Puting new line after colon makes code more readable. In c style languages do you use braces around single statment after if?

veky on Dec. 18, 2013, 8:26 a.m.
Depends. Relevant question here is: do I use braces around single statement after if, if that statement is a break (or return, ok) statement. And the answer is no. There's no point, since nothing can be added after it anyway.

bryukh on Sept. 25, 2013, 10:54 p.m.
<pre class='brush: python'>count += w2 > 4 </pre> Nice, if honestly, i didn't get it at first. It's not obvious type conversation, but interesting.

veky on Sept. 26, 2013, 4:31 a.m.
Same as my previous remark to you: bool can count. The fact that True == 1 and False == 0 is very useful for summation, not only in Python. See <a href="http://en.wikipedia.org/wiki/Iverson_bracket">http://en.wikipedia.org/wiki/Iverson_bracket</a> Iverson is a genius, however he was almost a century before his time. Many of his ideas we still don't understand. But bracket is very simple and useful. Knuth endorsed it (see <a href="http://arxiv.org/pdf/math/9205211v1.pdf">http://arxiv.org/pdf/math/9205211v1.pdf</a> for very nice exposition), what more to say? :-)

mlb00 on March 21, 2015, 4:18 p.m.
very cool to know, thanks!

lesenv on Oct. 28, 2013, 6:12 p.m.
on the point! very cool :)

veky on Oct. 28, 2013, 9:03 p.m.
Thanks. See also my other solution. :-)

Zantoo on Nov. 6, 2013, 3:45 p.m.
can you explain your synthax ? <pre class='brush: python'> while True: count += w2 > 4 if w1 == w2: return count w2 = (w2 - 1) % 7 </pre>

veky on Nov. 6, 2013, 8:19 p.m.
Try reading my comment (5th) below: bool can count. After that, if there are any more questions, ask freely.

Zantoo on Nov. 7, 2013, 2:03 p.m.
<pre class='brush: python'>count += w2 > 4 </pre> I don't understand '+=' with '>'

veky on Nov. 7, 2013, 2:47 p.m.
You don't understand what it does, or why I use it here? I'm trying to count all those passes through loop where w2 is greater than 4. Why += enables me to do it? When w2 is really greater than 4, w2>4 is True. When True is added to a number, increments it. When w2 is not greater than 4, w2>4 is False. When False is added to a number, leaves it alone. ok? Why it works like that? Because bool is a subclass of int. When a bool is treated in arithmetic context (for example, with arithmetical operators, like +), it is treated like an int: True like 1, and False like 0. Why did BDFL choose such a convention? Because it's incredibly useful, not only for counting (for example, "a if b else c" is functionally just (c,a)[b]). Now see my comment about Iverson below. :-)

Zantoo on Nov. 7, 2013, 2:52 p.m.
Thx :-)

drejcek on Nov. 24, 2013, 7:43 p.m.
Awesome

veky on Nov. 25, 2013, 6:42 a.m.
I'm really discouraged from writing long code here. When I golf something short, people give it a few thumbs and that's that. But when I write in long form, people just comment about how "awesome", "perfect", "really nice" and so on, my solution is, but thumb count doesn't change. ;-/

ysenko on Dec. 6, 2013, 3:10 p.m.
The code is hardly readable, thus only one thumb. Sorry.

veky on Dec. 7, 2013, 10:48 a.m.
No reason to be sorry, but I have the impression you haven't seen other solutions of mine. ;-]

Anomander on Dec. 7, 2013, 1:59 p.m.
A short, efficient and extremely unreadable solution. As long as this does not go into production, I like it :).

veky on Dec. 7, 2013, 6:21 p.m.
I promise. :-D BTW, may I ask how would you code the same solution in production? Is it only a matter of line 5, or something else?

Anomander on Dec. 8, 2013, 4:27 p.m.
I prefer code that is very easy to read and understand in production, even if it is not very efficient. In your particular case, line 5 should be quite easy to understand for a C/C++ developer (and other languages in which booleans are treated as ints). Line 4, with the "infinite" while loop, raised a red flag for me. This, and the fact that it took me at least 5 minutes to understand what your code is trying to do :).

veky on Dec. 8, 2013, 8:33 p.m.
<blockquote> I prefer code that is very easy to read and understand in production, even if it is not very efficient. </blockquote> Oh well, never to satisfy everybody. :-D Just yesterday, I was arguing with a man who doesn't admit any other criteria than speed. Yes, in Python. :-P <blockquote> In your particular case, line 5 should be quite easy to understand for a C/C++ developer (and other languages in which booleans are treated as ints). </blockquote> (Python is also such a language. Even formally, bool is a subclass of int.) <blockquote> Line 4, with the "infinite" while loop, raised a red flag for me. </blockquote> Hm. How would you write loop with exit in the middle? With code repetition? Or if "return" was "break" (with return later), would it be better for you? <blockquote> This, and the fact that it took me at least 5 minutes to understand what your code is trying to do :). </blockquote> That's not disputed. The question is why. :-)

floord on Dec. 9, 2013, 10:13 a.m.
"Oh well, never to satisfy everybody. :-D Just yesterday, I was arguing with a man who doesn't admit any other criteria than speed. Yes, in Python. :-P" hihihihi

Anomander on Dec. 10, 2013, 10:06 p.m.
For me, speed is the last concern when writing code. Usually. There are exceptions in which starting with a slow algorithm is not nice and can lead to major issues down the road, but, in my limited experience, these situations are quite rare. Regarding the exit in the middle of the while loop, why not use the <pre class='brush: python'> while w1 != w2 </pre> condition and return outside the loop? Break instead of return would not have helped much in this situation. Finally, it took me so much to understand your code because that while loop is not obvious at all. The count initialization is ok, even if you could improve its readability by using something like this: <pre class='brush: python'>count = (d2 - d1).days // weekDays * restDaysInWeek </pre> But the while loop is quite criptic. To better understand what I'm trying to say, I think I can break it in 2 parts that need to be deciphered in order to understand it: <ol> <li>what your loop is trying to accomplish -> counting the "missing" rest days from the possible incomplete week between the 2 dates</li> <li>how are you achieving this -> by moving the start date to the closest to the end date day (let's call this endStartDate) that is the same week day as the start date (this is not done explicitly in your code and it must be inferred by the reader) and then going back one day at a time from the end date (which is a litte bit stranger than going forward in time) to that endStartDate and checking for rest days.</li> </ol> I hope this clarifies my thought process. :)

veky on Dec. 10, 2013, 11:39 p.m.
Why not use "while w1!=w2"? I told you: because I'd have to duplicate code "count+=w2>4", which has to execute even when (including) w1==w2. That's what I was saying: when a while loop has exit in the middle, I always consider explicit break (or return) at the precise place more readable than contorting the loop to "persuade" it to think it actually has exit at the beginning. Especially when such contorting duplicates code. Yes, here the duplication is tiny, but the whole program is tiny. :-) About naming 2 and 7: well, I thought it was pretty obvious what they meant, considering what the program is for. If I was naming any constant, I'd much rather name that "4" in line 5. :-) BTW, I see even you haven't named 5 nor 6 in your code. ;-] About loop: yeah, if you think of it that way, it surely sounds complicated. :-D The thing is, I didn't ever think about dates here, I just thought about weekdays. So there is no "endStartDate" or any such thing in my head. There are just two weekdays, and I'm trying to get from one to the other (cyclically mod 7), counting how many weekend days are between them. I still think that's the most obvious way to do it. The only thing I'm willing to admit is that it would read nicer if the loop was going forward instead of backward, which is left as an excercise to the reader. ;-D

Anomander on Dec. 12, 2013, 8:08 p.m.
You are right about the while check leading to duplication. I realized that right before going to bed. And I very much prefer your current solution than the one involving duplication. I don't like duplicated code at all. You are correct about the fact that I also didn't name 5 and 6, but this happened because in my solutions I usually skip the refactoring step. But I don't do this at work, I promise :D. And I was almost certain that you didn't think about that loop in those explicit terms as I wrote in the previous post. You went one level up in abstraction and only thought about weekdays which might be easy for some people but a little harder for others. And for this you get the second thumbs up from me. Being able to understand and produce code at a high level of abstraction is a skill every programmer should have.

CyroAvernus on Jan. 3, 2014, 10:22 a.m.
Well nice but I recommend the use of toordinal() andd fromordinal().......

veky on Jan. 3, 2014, 10:31 a.m.
For you, I have another solution. Haven't you seen it? :-) But really, why? What I want to know is what days of week those dates fall on, not what their ordinals are in some arbitrary system. BTW, my solution is O(1), which means it always completes in some fixed time. Your solution can execute arbitrarily long, depending on how many days are between two dates. Not that it matters much to me, but maybe interesting to know. :-)

CyroAvernus on Jan. 3, 2014, 10:34 a.m.
Another solution?? :p

veky on Jan. 3, 2014, 10:38 a.m.
Yeah, maybe you didn't notice it since it is so small. :-P <a href="http://www.checkio.org/mission/weekend-counter/publications/veky/python-3/shortest/">http://www.checkio.org/mission/weekend-counter/publications/veky/python-3/shortest/</a>

CyroAvernus on Jan. 3, 2014, 10:35 a.m.
Yeah...that's for sure...your solution is O(1)....Maybe I should also try a constant time solution....

CyroAvernus on Jan. 3, 2014, 1:37 p.m.
the value of count will depend on the diff between the two dates...So how an it be O(1)???

veky on Jan. 3, 2014, 1:40 p.m.
O(1) is just an upper bound, it doesn't mean program always executes same number of instructions. My while loop executes a variable number of times, but that number is always less than 8, no matter what the dates are.

gflegar on Jan. 24, 2014, 1:53 p.m.
Nice. O(1) and readable. But i thought a mathematician would find a closed formula for this. :)

veky on Jan. 24, 2014, 2:33 p.m.
Closed formulas are overhyped anyway. :-P (In fact, this is a closed formula, just with 7 cases.:)) But see <a href="http://www.checkio.org/mission/weekend-counter/publications/Cjkjvfnby/python-3/publication/">http://www.checkio.org/mission/weekend-counter/publications/Cjkjvfnby/python-3/publication/</a>

gflegar on Jan. 24, 2014, 2:39 p.m.
<blockquote> But see <a href="http://www.checkio.org/mission/weekend-counter/publications/Cjkjvfnby/python-3/publication/">http://www.checkio.org/mission/weekend-counter/publications/Cjkjvfnby/python-3/publication/</a> </blockquote> Meh, I like my closed formula (with 0 cases) better :P

gflegar on Jan. 24, 2014, 2:50 p.m.
<blockquote> with 0 cases </blockquote> Pardon, 1 case :)

veky on Jan. 24, 2014, 8:08 p.m.
Yeah, 0 cases wouldn't be so great. :-D

zoharek on Jan. 30, 2014, 11:48 a.m.
6 lines? Srsly? ;p I expected oneliner..

veky on Jan. 30, 2014, 5:05 p.m.
<a href="http://www.checkio.org/mission/weekend-counter/publications/veky/python-3/shortest/">http://www.checkio.org/mission/weekend-counter/publications/veky/python-3/shortest/</a> Happy? :-)

zoharek on Jan. 30, 2014, 7:57 p.m.
Oh yeah, noticed it later ;p

TomTerebus on Oct. 2, 2014, 2:21 p.m.
Awesome + double thumbs up. 8)

veky on Oct. 3, 2014, 3:26 a.m.
Thanks. :-)

viktor.pecheniuk on Nov. 27, 2014, 2:07 p.m.
good, but look in one line :) return sum([1 for daydelta in xrange(0, (end - start).days + 1) if (start + datetime.timedelta(daydelta)).weekday() > 4])

veky on Nov. 27, 2014, 7:02 p.m.
Let's say you wrote this before you saw that other solution of mine. Otherwise it would not make much sense. :-) But of course, there's an important criteria by which this solution is better than that one: algorithmic complexity. This is a constant time solution, it executes in bounded time no matter what dates you input. Oneliners are usually (but not necessarily;) linear in difference between dates.

Happiness on Feb. 20, 2015, 5:01 a.m.
Interesting how did you come to this? :)

veky on Feb. 20, 2015, 6:20 a.m.
Approximate and ajdust, a well-known technique for solving such problems. I know weekends are two sevenths of every week, so if I floor-multiply difference in days by 2/7, I'll get a good lower bound for my number. How wrong can that lower bound be? At most by two, if there happens to be another weekend in the "rest" (not divisible by 7) of day difference. How to see if this is the case? You go from one weekday to the next, modulo 7, and count how many weekend days you've encountered. It's constant time, since `while` suite can execute at most 7 times. Clearer?

Happiness on Feb. 20, 2015, 8:24 a.m.
Yeah thanks a lot - its nice way of thinking) How many time it takes for you?)

veky on Feb. 20, 2015, 9:11 a.m.
Well, I wrote this a year and half ago, I really don't remember how much time this took. But I think about half an hour (including everything: reading the task, designing solution, testing, and inventing a nice name:).

Happiness on Feb. 20, 2015, 9:20 a.m.
Cool :D I doing mine almost all night, look at yours and others and... so was surprised)

veky on Feb. 20, 2015, 9:39 a.m.
It's just a matter of practice. I write at least 10 lines of Python every day. :-) It really helps when you don't have to look at the documentation every few minutes. And for a while I also don't even have to run Python interpreter, I just write code in a text file and it works. :-))

nemoyatpeace on Feb. 21, 2015, 1:32 a.m.
Beautiful! Perfectly readable and teaches an amateur like me some tricks for making things work smoother. My conditions for adding in the extra days were quite ghastly.

kryksyh on April 27, 2015, 7:47 p.m.
I wonder if there is loopless solution?

veky on April 28, 2015, 5:56 a.m.
Yes, there is. IIRC, @gflegar has one.

dunpealer on Aug. 27, 2015, 6:58 p.m.
Very nice, clear solution. One question: Why decrease w2 instead of increasing w1? Seems clearer.

veky on Aug. 27, 2015, 7:07 p.m.
Try writing it that way. ;-)

dunpealer on Aug. 27, 2015, 9:19 p.m.
I did, and it passed the tests: <pre class='brush: python'>def checkio(d1, d2): w1, w2 = d1.weekday(), d2.weekday() count = (d2 - d1).days // 7 * 2 while True: count += w1 > 4 if w1 == w2: return count w1 = (w1 + 1) % 7 </pre> Perhaps there's something I'm missing?

veky on Aug. 28, 2015, 3:55 a.m.
Hm, obviously no. :-) I had a feeling that, since range(a, b) is not the same as range(b, a, -1), you'll need additional adjustments here, and it would be ugly. I forgot that intervals are closed here, so both w1 > 4 and w2 > 4 are counted eventually. Oh well, it's not the first nonperfect solution of mine here. :-)

jake-g on Jan. 24, 2016, 1:11 p.m.
better than mine

veky on Jan. 25, 2016, 6:15 a.m.
Not very surprising. :-)

Master of the Time Stone

0 %

You ClassRoom Demo is Ready With the new tool CheckiO ClassRoom, you will be able to analyze your students' progress, have your own leaderboard, change missions order on the map, and so on.