Bruteforce clear solution for Disposable Teleports by veky - python coding challenges

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

Bruteforce solution in Clear category for Disposable Teleports by veky

nodes=set("12345678")
def solve(possible,been,am,path):
    path+=am
    if (am,been)==("1",nodes): return path
    for dest in nodes:
        edge=frozenset({am,dest})
        if edge in possible:
            sol=solve(possible-{edge},been|edge,dest,path)
            if sol: return sol
checkio=lambda t: solve(set(map(frozenset,t.split(","))),set(),"1","")

June 25, 2013

Comments:

kkkkk on Jan. 20, 2015, 4:32 a.m.
Why is this clear versus clever?

veky on Jan. 20, 2015, 8:49 a.m.
I don't know about clever, and I think it's a nondistinction anyway. But I would argue it is clear. It's a standard bruteforce way of recursively traversing all nodes. I track 4 things: <ul> <li>`possible`: edges I can still use. They start as given in the task, and are removed when I traverse them. I use this to branch further: where can I go from here?</li> <li>`been`: all the places I've been. This starts as empty set, and is updated with a place when I arrive to it. I use this for a stopping condition (together with the next one).</li> <li>`am`: where I am right now. This starts as "1", is updated on every hop, and if it becomes "1" again, together with `been` being all nodes, then I return the path all the way up.</li> <li>`path`: I log all the nodes I've been through, so I can return the path when I'm done.</li> </ul> What part do you find unclear?

kkkkk on Jan. 20, 2015, 5:20 p.m.
There's a sharp contrast in solutions where some are well-commented, written in a modular fashion and probably pass pylint standards, and other solutions that are dense and a bit obtuse. My guess is that the former is 'clear' and the other 'clever'. I also look at some of the solutions with the thought - if I had to maintain/update/debug this, how much hassle/work would it be? If it would be relatively simple, I consider it a 'clear' solution, if I have to puzzle out what the code is doing, I figure it falls into another category. I would have to puzzle out your solution. Your comments help, but they're not in the code itself. So by my standards, it's not clear. But that's just my opinion. BTW - I'm guilty of not including comments or pylinting my published solutions, but hope/assume the answer is clear as well.

veky on Jan. 20, 2015, 6:20 p.m.
You can think whatever you want. I'm telling you two important things. First, this is in no way clever code. It is what any remotely experienced programmer would write when trying to bruteforce this task. There is not a single point in this code that somehow signals any kind of cleverness. The code is totally boring. You yourself say the code is "a bit obtuse". Since when we have started to identify obtuse with clever?? Second, maintenance is a red herring. CheckiO is not written with the purpose of maintaining an illusion of a live production code. If you want to fix something, you have to make a brand new solution anyway. The code up there is frozen. On the other hand, the social comments here are almost a living organism: they grow and wither, branch and flourish in some directions, and show us all where the interesting stuff happens. With that in mind, do you seriously think it's better to freeze some aspects of explanation up there, where it wouldn't be able to be changed to reflect current understanding, instead of discussing here interactively what needs to be discussed at the precise moment? Whatever you want explained, ask and I'll explain. But I'll never try to just "imagine" what anybody might have a problem with when reading my code. Too diverse people with too diverse knowledge of Python come here and read these solutions. And some of them were written when I had no idea what the community would be like one day.

kkkkk on Jan. 20, 2015, 7:32 p.m.
Obtuse code isn't always clever, I agree. The term 'clever' here could mean cleverness in the algorithm or skilled use of programming constructs. I would say there's a little bit of both in your solution. We disagree and that's ok ... it's just a different point of view. My comment about maintenance was not literal. I understand the code is fixed and doesn't require maintenance. The term "maintainable code" is what I'm applying here and that can mean different things to different people. We don't have to agree on what that means, either. Re: freezing the comments, if the code is fixed or frozen, why not fixed or frozen comments? The 'social' comments can be used for clarification if there's still confusion.

veky on Jan. 20, 2015, 8:57 p.m.
<blockquote> I would say there’s a little bit of both in your solution. We disagree and that’s ok … it’s just a different point of view. </blockquote> Of course. But I would very much like to know what exactly do you find clever here. I use recursion, yes. But without it the code would be even harder to read. Other than that, I use ordinary looping, updating of strings and sets, and conditional returning. Oh yes, I use the fact that None is the default return value of a function, but that's perfectly aligned with the purpose of None object. <blockquote> My comment about maintenance was not literal. </blockquote> I know. I'm just telling you that illusion is very weak here. CheckiO doesn't even attempt to make people think they are maintaining something. When spec changes, your solution is usually just removed, and in many cases you don't even have access to your previous source. Granted, that doesn't happen often anymore, but it does happen. <blockquote> Re: freezing the comments, if the code is fixed or frozen, why not fixed or frozen comments? </blockquote> Why not - well, why yes? Social comments are infinitely better. Code is frozen because it has to be - otherwise the task wouldn't be marked as solved (and more importantly, social comments wouldn't be able to gather around anything:). But experience has taught me to expect anything to be asked here: from things like "Why do you use `frozenset`?" to things like "how can you write `if sol: return sol` in one line?". Anticipating everything up there is an exercise in futility.

kkkkk on Jan. 20, 2015, 9:21 p.m.
Ok - let's forget about clever. Looking at the code some more, I'd agree and say it's not clever. I would say your code is hard to read because it's dense with minimal use of white space, i.e., you have no spaces around the equal signs or commas, and you have a preference for one-liners. It's not consistent with PEP 8 standards or typical coding standards. The convention of capitalizing constants (e.g., node) isn't followed either. There are no comments - and I'm talking about a brief description of what the line is doing, not the kinds of comments you're talking about. So not clever, but not so clear if you place value on white space, coding standards and comments. At this point I'd rather code than argue, so I'm going to stop my end of this conversation.

veky on Jan. 21, 2015, 9:05 a.m.
Code all you want. But it seems to me we've reached an important conclusion: your preconceived notions about me and my code are clouding your judgment and making you see things that simply aren't there. Hey, we all know Veky likes writing clever code, so this one has to be clever - even if it's not, in fact it's painfully boring. Hey, we all know Veky likes oneliners, so this one has to be short - even if it's ten lines. This is no way to review code. Please try to stay away from prejudices, and see the code for what it is. If you mentioned lack of horizontal whitespace before, or inconsistent naming, I'd agree with you immediately. (And about PEP8 and comments, I wouldn't agree they are relevant here, but at least we would stay factual in the discussion.)

gmixo on March 31, 2015, 8:17 a.m.
good solution - set concatenation, comparison and substraction really inplace!

veky on March 31, 2015, 8:21 a.m.
Thank you. Yes, sets are often unjustifiedly neglected type in Python. :-) BTW "concatenation" of sets is spelled "union". ;-)

Paul-Yuchao-Dong on Jan. 7, 2017, 7:57 a.m.
Possible, been am, path - I think that summarizes the key elements pretty well.

veky on Jan. 7, 2017, 10:20 p.m.
`been` is the parody on <a href="https://logicgrimoire.wordpress.com/2016/10/13/scripting-language-idioms-the-seen-hash/">seen</a>. And then `am` is just analogy with present tense. :-D

Ice Base

0 %

PyCharm The Python IDE for Professional Developers. Enjoy productive Python, web and scientific development with PyCharm. Download it now!