dict FTW speedy solution for Roman Numerals by veky - python coding challenges

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

dict FTW solution in Speedy category for Roman Numerals by veky

def checkio(x):
    a,r="",{}
    for i in range(3):
        p,(j,c,d)=10**i,"IVXLCDM"[2*i:][:3]
        r.update({p:j,5*p:c,4*p:j+c,9*p:j+d,10*p:d})
    for k in reversed(sorted(r)):
        a+=x//k*r[k]
        x%=k
    return a

June 14, 2013

Comments:

veky on Dec. 12, 2013, 7:06 p.m.
If you're trying to see how it works: just print(r) between lines 5 and 6. I'm sure you'll see what r is, and then the rest is pretty obvious. (Of course, if there are any questions, just ask.)

infinitylX on May 28, 2014, 9:26 a.m.
Awesome.

veky on May 28, 2014, 12:31 p.m.
Thanks. Be sure to check other my solutions here. :-)

jehutyy on Sept. 16, 2014, 9:22 p.m.
How did you get the idea to build your dict this way Oo "people are smart and i'm sitting here typing the whole dict by hand..."

veky on Sept. 17, 2014, 6:27 a.m.
I just figured out what are "atoms" of building that dict (1, 4, 5, 9, 10, 40, ...), discovered the pattern (geometric supersequence with factor 10), and expressed that in Python code. As for the other half of your comment, you might want to take a brief look at <a href="http://www.checkio.org/mission/roman-numerals/publications/veky/python-3/lookup/">this</a>. ;-]

vikulin on Sept. 26, 2014, 3:46 p.m.
this is humiliating! :) i even employed recursion to solve this one, and yours looks so concise and ummmm... simple, when you get a hold of it... although, it's surely not the most "clear" one. ;-)

veky on Sept. 26, 2014, 7:39 p.m.
It has two parts... constructing r, and iterating through it. Which part do you find unclear?

vikulin on Sept. 27, 2014, 8:57 a.m.
for somebody, who knows Python by heart it's a great solution and is easy to read! i've learned a lot from it! thank you! but for a newbie like me, at first sight this code seemed very overwhelming. it showed me that i know nothing, that i am using python as if it was primitive basic, and that i must get back to reading tutorial, before attempting any new tasks. :)

veky on Sept. 27, 2014, 12:08 p.m.
No, not must. My aim is to show you that you want to. ;-) P.S. First sight can deceive. If you still find some part unclear, feel free to ask.

seb.hoarau on Oct. 9, 2014, 11:11 a.m.
Nice solution. To make it more readible maybe separate the construction of the symbols dictionary from the analyse of the number.

veky on Oct. 9, 2014, 4:34 p.m.
Well, the indentation obviously separates those loops - two walleys in the indentation are obvious. :-) You probably wanted me to give them names, and yes, that would be nice, but this was a long time ago, while I was still getting used to CiO (and CiO was getting used to me:)). In the first comment <a href="http://www.checkio.org/mission/roman-numerals/publications/veky/python-27/dict-ftw/#comment-7324">above</a>, i said that program really consists of 2 parts, separated between lines 5 and 6.

Hanna_Hofman on Oct. 15, 2014, 12:25 p.m.
Cool. I couldn't find way to form dict autoaticaly and didn't want to type in too much, so my solution is way more complicated. This makes me upset of being lame, but, well, I'm not a professional programmer, just learning :)

veky on Oct. 15, 2014, 1:51 p.m.
Whenever you copy-paste code, you're misunderstanding something. In most cases you should just write a loop. See what changes from pass to pass, name it, put all values in a sequence, and iterate through it.

Hanna_Hofman on Oct. 15, 2014, 2:35 p.m.
Yeah, DRY, I know. I assume you wrote it because you've found one of my solutions, and most probably it was the firs one. My first attempt to solve this task was, uhm, newbeesh. So after some time I made second attempt and solution was much better in my opinion (at least, it was DRYed), but it was really complicated. I've shown it to my fellow programmer and he said it's totally ugly :(

veky on Oct. 15, 2014, 3:50 p.m.
You should have shown him your first version. Compared to that, second is completely fine. ;-P Regarding horrible hoops you had to go through for mid_val: it's fascinating that when you copy-pasted code, you had no problem including values like 40, 900 and so on in iteration. But in your second solution, it seems you decided you'll avoid it no matter what. In fact your second solution would be much nicer if you at least preprocessed the values list to insert corresponding mid_vals. <pre class='brush: python'>for code, value in values: roman += n // value * code n %= value </pre>

Hanna_Hofman on Oct. 15, 2014, 8:06 p.m.
Yeah, it was one of my iterations in solving the task. But then I thought that I don't like adding all these 'IV's to dict, because I do actually have both 'I' and 'V' in dict, so I thought it would be better to combine them while iterating through dict. And that thoughts led to unclear and messy code. On the other hand, I think that if I would assign these mad i+i%2+1 (or whatever it was) to separate variables with understandable names, it would look much better. But I'm too lazy to refactor it now that I've got the point.

veky on Oct. 16, 2014, 2:07 a.m.
<blockquote> But then I thought that I don't like adding all these 'IV's to dict, because I do actually have both 'I' and 'V' in dict, so I thought it would be better to combine them while iterating through dict. </blockquote> You had a right intuition (DRY applies to data inasmuch as to code), up to but not including that "while iterating through dict" at the end. ;-P Preprocessing is much easier, as my code shows. It is even encouraged in Python through the use of generators: you don't need to separate preprocessing in time, just in space. ;-)

UndeadMonkey on Oct. 16, 2014, 8:06 p.m.
Interesting solution, but I'm not sure you can class this as 'clear'

veky on Oct. 16, 2014, 8:59 p.m.
Any particular problem with the code, or you just don't like the style?

UndeadMonkey on Oct. 16, 2014, 9:04 p.m.
Oh no, don't get me wrong - I think its very clever. I'm just not sure it should be classified here as 'clear' as it isn't immediately readable/understandable. EDIT: Sorry that sounded extremely sarcastic. I really do think its a clever implementation, and far more elegantly solved than mine; I just think its a 'clever' solution rather than a 'clear' one.

veky on Oct. 16, 2014, 9:20 p.m.
All my solutions are clever. If you don't see that in some particular solution, it just means you're clever too. ;-) However, clever is not a category. For me, clever means something to person writing the code: "it was clever of you to think of that". But it can still be clear to readers, once they see it.

cactustictacs on Oct. 22, 2014, 12:32 a.m.
Out of interest, is there any solution that isn't "clear" by this metric? No matter how tortuous and byzantine the logic, if a person can manage to work out what's happening then the logic will be apparent. Everything is "clear" by that definition. It just makes the categories seem kinda meaningless

veky on Oct. 22, 2014, 10:27 a.m.
I think you misunderstood the verb "see" in the comment above. I meant really "see" as in, person sees the code and says "oh right, that's clear". Not "see" as in "understand after an hour of intensive thinking". :-)

cactustictacs on Oct. 22, 2014, 6:45 p.m.
Oh ok, I see what you mean! But in that case, is this solution "clear"? I don't think the majority of people would look at your code (which is a clever and complex way of generating a pattern of assignments, instead of just writing them out normally) and immediately grasp what's happening. Even your first comment recommends writing a debug statement to poke around in the internals! Don't get me wrong, I love your work and I always learn something - either about the language or about logic in general - but I absolutely wouldn't put this in the 'clear' category, especially in the newbie section of a 'learn to program' site. I know the line between complex and clear is subjective, and it moves as you grasp the language fundamentals better, but this is complicated because the (unnecessary) dict generation algorithm is complicated, you know? I know you hear this kind of thing a lot, but I honestly think you're doing yourself a disservice (and maybe worrying a few new people) by putting this kind of thing under 'clear' instead of 'creative' or whatever. If you care what I think! Great solution though, I was trying to think of a way to generate something similar, and this is really slick and compact. Neat!

veky on Oct. 23, 2014, 10:34 a.m.
<blockquote> your code (which is a clever and complex way of generating a pattern of assignments, instead of just writing them out normally) </blockquote> If you look at them as assignments, of course it's complicated. It's practically metacoding (writing code that generates code). But you don't have to look at it this way. It is just a mapping between "atoms" of Roman numerals, and their values. In that way, it is kinda like a periodic table. Surely you think periodic table is a nontrivial structure of elements, not just a list of them with their atomic mass? You go through shells (p numbering 1, 10, 100, 1000), and orbitals (letters j, c, d; measuring 1, 5 and 10). Possible configurations in each shell are j, j+c, c, j+d and d; with values 1, 4, 5, 9 and 10. Surely there is a way to exploit that structure, instead of just writing the numbers in a row? <blockquote> Even your first comment recommends writing a debug statement to poke around in the internals! </blockquote> "debug", "poke", "internals"... such strong and unpythonic words. ;-) Am I debugging my phone connection internals when I pull out my little notebook with phone numbers, to see who's calling me? :-D <blockquote> I love your work and I always learn something - either about the language or about logic in general </blockquote> Then I achieved my purpose. :-) <blockquote> but I absolutely wouldn't put this in the 'clear' category, especially in the newbie section of a 'learn to program' site. </blockquote> Don't underestimate newbies. ;-) Ok, what's the worst that can happen? Someone comes along, sees my solution in the Clear category, and runs away scared, thinking "OMG, this Python is so complicated, I'll never get it"? What an overreaction, not to mention unjustified generalization. But even if they do, don't they at least see some other solutions too? Would it help if I put a sentence "Please look at other people's solutions too" in my profile? :-D Python newbies are just that: people who don't know much Python. They are not social newbies; they know social dynamics very well. I'm sure they'll figure out what's going on, and how this works. Don't forget they are almost surely reading these comments too. ;-) <blockquote> this is complicated because the (unnecessary) dict generation algorithm is complicated, you know? </blockquote> It's funny. Algorithm has two parts: generating r, and using it. I'm pretty sure they are of approximately the same complexity. If you don't believe, just look how many builtins and operators I use in the bottom part. But why do you think the upper part is more complicated? My theory: only because you can visualize yourself writing 13 assignments <pre class='brush: python'>r["I"] = 1 r["IV"] = 4 r["V"] = 5 ... r["M"] = 1000 </pre> yet you cannot realistically visualize yourself writing <pre class='brush: python'>while x >= 1000: a += "M" x -= 1000 while x >= 900: a += "CD" x -= 900 ... </pre> But the complexity is about the same. In both cases you're practically writing only highly structured data, instead of capturing that structure in the code. <blockquote> you're doing yourself a disservice (and maybe worrying a few new people) by putting this kind of thing under 'clear' </blockquote> About worrying a few new people, see above. About disservice, I'm (without fake modesty) one of most popular people here. I spend hours a day tutoring people and reviewing their code. I could use a little disservice. :-D <blockquote> If you care what I think! </blockquote> I really do. But I also care about other things. Zen says there should be (preferably only) one obvious way to do it, and if you hold on to this idealistically, all solutions in the Clear category would be the same. Too boring. :-P I solve this by postulating that Clear != obvious. As I explained above. <blockquote> Great solution though, I was trying to think of a way to generate something similar, and this is really slick and compact. </blockquote> As I said, that's important. I realize there are many people here who cannot stand me or my solutions, but there are also many more people who learn very useful things with every solution of mine they read. Thank you for giving my being here a purpose. :-D

cactustictacs on Oct. 23, 2014, 7:17 p.m.
Thanks for the reply! I appreciate you being good-humoured about the whole thing for the millionth time <blockquote> If you look at them as assignments, of course it's complicated. It's practically metacoding (writing code that generates code). But you don't have to look at it this way. It is just a mapping between "atoms" of Roman numerals, and their values. In that way, it is kinda like a periodic table. Surely you think periodic table is a nontrivial structure of elements, not just a list of them with their atomic mass? </blockquote> Right, but just because you can doesn't mean it's the best or clearest way to represent that data. The periodic table is the result of a highly structured set of observations about physical properties, but there's a reason it's presented in that finished form - so it's easier to read and easier to use! You could condense all that down into some algorithmic code, which would be useful in some situations, but the vast majority of the time the actual, resulting visual table is used. <blockquote> "debug", "poke", "internals"... such strong and unpythonic words. ;-) Am I debugging my phone connection internals when I pull out my little notebook with phone numbers, to see who's calling me? :-D </blockquote> I'm not sure how well that analogy holds up, but inserting print statements so you can monitor internal state at a watchpoint and work out what's going on is pretty standard debugging behaviour. You can even use the unpythonic Python debugger module to do it! <blockquote> It's funny. Algorithm has two parts: generating r, and using it. I'm pretty sure they are of approximately the same complexity. If you don't believe, just look how many builtins and operators I use in the bottom part. But why do you think the upper part is more complicated? My theory: only because you can visualize yourself writing 13 assignments </blockquote> The bottom part is fairly complex, yeah - but that's the algorithm that solves the problem. There needs to be something there! I'd argue that isn't necessarily clear either, but it's a matter of style. The top part though - it's completely unnecessary. It's 3 characters shorter than just typing out the finished (readable) dict, it's slower (because it has to generate it), and I'm guessing (pure speculation since I don't know anything about Python's internals) that it has a bigger resource footprint because of all the variables in place of a few literals. Not that performance matters even slightly here, but it's not an improvement! It doesn't confer an extensibility advantage since roman numerals aren't likely to get any bigger (at least not through this pure letter system), and it makes it harder to change for special cases like the IIII version of 4 you see on clocks. It basically trades readability and simple maintenance for no benefit whatsoever. Like I said, it's a creative solution and as an exercise in exploration and problem solving, it's fantastic! And I'd encourage everyone, newbie or seasoned pro, to have a look at it and at least try to work out what's happening. But it's not a clear solution, and if the categories are to have any meaning at all I'd recommend the 'clear' ones allow the reader to easily follow the logic of the program, as a priority. Plenty of whitespace, no dense chaining of functions and operators that make it hard for a Python newbie to isolate unknown parts and what they do, and helpful comments where necessary! Which is all a judgement call of course, but heavily encoding a basic 13-element dictionary just because it's possible is way over that line, in my opinion anyway. Whereas the Creative section... well that should be where people go to be inspired and learn some cool language tricks, whatever their level <blockquote> Zen says there should be (preferably only) one obvious way to do it, and if you hold on to this idealistically, all solutions in the Clear category would be the same. Too boring. :-P </blockquote> I disagree with this, there are often many different approaches to solving a problem, and then there are many more implementations for each of those approaches. My solution is pretty much identical to yours, but the implementation is different - a list of tuples instead of a dict (assigned explicitly of course ;) ), and the functional code is <pre class='brush: python'>for amount, letter in values: multiples = data // amount output += multiples * letter data -= multiples * amount </pre> I'm not saying it's elegant (and your version made me realise I forgot about modulo again), but I'd argue it's more readable. It's the same algorithm expressed more clearly, y'know? But there are other algorithmic possibilities, ways of solving the general problem, like going from digit to digit (for example) and mapping the 9-5-4-1 relationship to a moving window on the numerals list. Or using your generation algorithm while parsing instead of generating a lookup structure. Lots of ideas to try and lots of ways to express them!

veky on Oct. 24, 2014, 10:04 p.m.
<blockquote> Thanks for the reply! I appreciate you being good-humoured about the whole thing for the millionth time </blockquote> Same to you. I usually deal with people who either think they are absolutely right and nothing can change their mind, or they listen and accept whatever I say. People like you, who have attitude but are willing to discuss it, are rare. :-) <blockquote> Right, but just because you can doesn't mean it's the best or clearest way to represent that data. The periodic table is the result of a highly structured set of observations about physical properties, but there's a reason it's presented in that finished form - so it's easier to read and easier to use! You could condense all that down into some algorithmic code, which would be useful in some situations, but the vast majority of the time the actual, resulting visual table is used. </blockquote> Here you have a point. If people never saw that dict, of course it would be useful to show it to them. But they've seen it in many other solutions. "Finished form" is common knowledge. What I wanted to show is that it has the structure which is easily expressed in Python. To someone, knowing about finished form of periodic table of elements is surely useful, but knowing about shells and orbitals is strictly more useful, don't you think? Because it enables you to do all the things you can do with the finished form, and many more - like predict element valence, for example. <blockquote> I'm not sure how well that analogy holds up, but inserting print statements so you can monitor internal state at a watchpoint and work out what's going on is pretty standard debugging behaviour. You can even use the unpythonic Python debugger module to do it! </blockquote> Of course, but again you're overgeneralizing. There's no internal state, the only reason it's not possible to inspect r from outside is namespacing: it's a local variable. The same holds for your dict (I suppose - since you haven't published your solution). Would you say that your dict is "internal state"? It's just a lookup table. Also, there is no "watchpoint", in the sense of a point in the code that's visited many times, with a key variable changing from one to the other. This point in code is visited only once, and r is constant. You can print it at the end of function all the same (or leak it outside in any possible way), it's just that the place I suggested naturally divides the code into generating r and using it. <blockquote> The bottom part is fairly complex, yeah - but that's the algorithm that solves the problem. There needs to be something there! </blockquote> Ah, here I have you. There doesn't. :-) See <a href="http://www.checkio.org/mission/roman-numerals/publications/veky/python-3/lookup/?ordering=most_voted">this</a> (you'll notice that it was published much before our discussion;). Now let's try to be honest. You don't think that solution is very nice, right? Ok, why? Is it only because of length? I don't think so. My theory: because you realize that huge tuple has structure, that's completely ignored when written in this way. It's not something you can easily "fake". Well, that's the same how I feel with your 13-item dict. Python serves to write structured code, not just for serializing raw data. There are many benefits to that; more on this below. <blockquote> The top part though - it's completely unnecessary. It's 3 characters shorter than just typing out the finished (readable) dict, it's slower (because it has to generate it), and I'm guessing (pure speculation since I don't know anything about Python's internals) that it has a bigger resource footprint because of all the variables in place of a few literals. Not that performance matters even slightly here, but it's not an improvement! </blockquote> Of course it is not an improvement when you judge it by completely wrong criteria. :-P You yourself say that performance here is completely irrelevant anyway. And no, even length is not my main criterion (despite what it seems like sometimes;). As I said above, the point is expressing structure in data, not just parroting the data raw. It's true that when data is regular enough, and structure captured correctly, it usually results in shorter code, but it's just a side benefit. <blockquote> It doesn't confer an extensibility advantage since roman numerals aren't likely to get any bigger (at least not through this pure letter system), and it makes it harder to change for special cases like the IIII version of 4 you see on clocks. </blockquote> Ah, yes. I agree completely. But that's a medal with two sides. Yes, it's harder to smuggle irregularities in the structure. But for me it is a fantastic benefit, not a drawback. Remember the solution refered above? What if I made a mistake (intentional or unintentional) at one place? Horrible thought, right? How much time do you think would pass before it is caught? Yes, the risk is much smaller when data has 26 items instead of 3999. But the point stands. Looking at my code, you just know there are no special cases. Looking at your dict, someone needs to verify all 26 literals to see if there are any. Another warning: half-baked structure is often worse than no structure at all, since you think you understand it intuitively, and then it bites you long after. Yes, possibility of IIII for 4 seems nice. Until you realize that you don't want CCCC for 400, and no way in hell you want CDIIII for 404. As for 40, noone can really tell, and both XLIIII and XLIV are found in the wild. Maintainable? If by "maintainable" you mean "a ticking bomb"... That all being said, I must say one more thing. "It's harder to smuggle irregularities" doesn't mean it's hard to rewrite it your way. In fact it's trivial. Instead of print(r), you just <pre class='brush: python'>print("r =", r) </pre> and put its output instead of the first half of function. Done. That's the additional reason why I like writing structure exploiting code: going down the abstraction ladder is trivial, and best done by computers. Going up is why we humans are here, and what we're trying to learn on CheckiO. Yes, you lose information both ways, but going up you lose information you can afford to lose, since it can be regenerated mechanically. (Analogy: supposing you can have only one, what is more useful: a book of logarithmic tables, or Taylor expansion of log around 1? A century ago, it depended on what you wanted to do. Today, the question is settled beyond dispute.) <blockquote> Like I said, it's a creative solution and as an exercise in exploration and problem solving, it's fantastic! And I'd encourage everyone, newbie or seasoned pro, to have a look at it and at least try to work out what's happening. But it's not a clear solution, and if the categories are to have any meaning at all I'd recommend the 'clear' ones allow the reader to easily follow the logic of the program, as a priority. Plenty of whitespace, no dense chaining of functions and operators that make it hard for a Python newbie to isolate unknown parts and what they do, and helpful comments where necessary! </blockquote> Ah, well. Here you talk about something completely different. At least you can admit that? It is a nice discussion and I'm probably willing to concede many more points to you in it, but it's completely separate from the one we are leading right now. And this one is long enough IMO. :-D <blockquote> Which is all a judgement call of course, but heavily encoding a basic 13-element dictionary just because it's possible is way over that line, in my opinion anyway. Whereas the Creative section... well that should be where people go to be inspired and learn some cool language tricks, whatever their level </blockquote> Of course. But these are not language tricks. I'm sure you see it. In fact, I think we can agree that the bottom part of the code used more "tricks" than the top part. I think the only reason you focus your attention to the top part is that you feel that somehow, it shouldn't be in the code. It should be reduced completely, precomputed - not even in compile time, but in design time, that precious human time when we write code. It's not that the code to calculate it is too complicated - it's that you aren't willing to accept anything beyond a bare literal. Right? <blockquote> I disagree with this, there are often many different approaches to solving a problem, and then there are many more implementations for each of those approaches. My solution is pretty much identical to yours, but the implementation is different - a list of tuples instead of a dict (assigned explicitly of course ;) ), and the functional code is for amount, letter in values: multiples = data // amount output += multiples * letter data -= multiples * amount I'm not saying it's elegant (and your version made me realise I forgot about modulo again), but I'd argue it's more readable. It's the same algorithm expressed more clearly, y'know? </blockquote> Well, I said "idealistically". I hope you'll agree that "one obvious way" to code what's left after taking away floordiv divisors, is % operator. You're just using a slightly nonobvious way to write the code. Of course, it's so slight that noone would hold you responsible for that, but that's precisely why I said "idealistically". :-) <blockquote> But there are other algorithmic possibilities, ways of solving the general problem, like going from digit to digit (for example) and mapping the 9-5-4-1 relationship to a moving window on the numerals list. Or using your generation algorithm while parsing instead of generating a lookup structure. Lots of ideas to try and lots of ways to express them! </blockquote> Hm, until you write it more precisely, it's hard to be exact, but it seems to me they are just some other ways to express the same algorithm, and where they differ, it's just that one of them chooses a "slightly nonobvious" way of doing some step. Or, alternatively, of course it's possible that Python doesn't hold on to "only one obvious way" philosophy too idealistically, since of course, "practicality beats purity". ;-)

maurice.makaay on Oct. 29, 2014, 12:27 a.m.
The fact that there can be big discussions on whether this is to be considered part of the category Clear or not, tells me already that it might not belong in that category. I am also on the page of finding this a nice clever solution, but categorizing it as totally unclear, even though I am an experienced programmer who can read it... well... who is able to parse the code by carefully pretending that I am a Python interpreter and feeding myself some inputs to see how that would be processed. Code that is clear should be easy to read. When there is a bug in this little beauty, then it can be really painful to find and solve it when so much logic and tricky processing are crammed into a few lines of code. One good reason for making code as obfuscated as this, would be to increase the performance. I quickly checked the timing against my version and found that this code runs more than 6x as slow as my stupid simple version. So overall, sorry, but I am not a big fan of this coding style.

veky on Oct. 29, 2014, 5:28 a.m.
Your right is to not like it. But saying things like "When there is a bug in this little beauty, then it can be really painful to find and solve it" tells me you haven't read the discussion at all. The whole point of my stance is that bugs are more apparent, and easier to systematically fix, if you exploit the structure in your data. Have you read the part about IIII vs IV? And yes, thank you for the timing. Now tell that to cactustictacs. ;-) But ok, about the category, whatever. I still think that category (as currently conceived) doesn't make sense at all. Changed to Speedy. :-)

maurice.makaay on Oct. 29, 2014, 6:08 a.m.
I have read the discussion and you are entitled tot have a stance, but I simply am unable to see any advantages, except for making this code a fun puzzle to read. Changing a slow algorithm to category speedy... Well it is up to you. There was a smiley involved, so that probably makes it right.

veky on Oct. 29, 2014, 6:15 a.m.
I think I have provided very detailed arguments for my stance. As for you, I can't see anything except just proclamations without arguments. Ok, let's try to be concrete. Please give me an example of a bug that would be hard to detect and/or fix in my code. I can go first: For your code, imagine having "CX" instead of "XC" for 90. What do you think, how much time would pass before you notice it?

maurice.makaay on Oct. 29, 2014, 6:22 a.m.
My unit test would immediately detect it and any coder would be able to fix it in minutes. As for your code: change one or two operators somewhere in the code, then ask a random developer to fix the bug. That will show what I mean with "hard to fix". You don't have to believe me on this one. It is fine by me.

veky on Oct. 29, 2014, 6:28 a.m.
Can you provide an example of your unit test? And be honest: wouldn't it just copy the data from the same source as your code? <blockquote> change one or two operators somewhere in the code, </blockquote> Please be concrete. I must say I find this very hard to understand. Swapping X and C while typing is very plausible (look at the keyboard), but how does your thing happen? If I write "j-c" instead of "j+c", for example, Python will tell me what's the problem exactly.

maurice.makaay on Oct. 29, 2014, 8:16 a.m.
If I swap (j,c,d) to (d,c,j), the code will produce wrong output and the bug would be very hard to solve for a lot of coders (for starters, the variables are short and therefore meaningless, requiring the coder to first guess what they are about). I can come up with a lot more small changes like this, which would result in hard to solve issues. Your point seems to be "but the code does not have a bug". My point is "This style of coding makes bug fixing hell in case there is a bug". If I see this kind of coding on my team, I tell the coder to modify the code to make it look like it was an easy problem to solve. I am a TDD-addict, so what I normally do when I'm solving a problem, is write a lot of small unit tests which I let pass by writing my code. I added cases like this while going through both standard and special cases. Eventually, the TDD process drove me to the solution that I came up with. I am not sure what you mean with copying data from the same source as my code. My unit tests that touch '90' are simply: <pre class='brush: python'>assert checkio(90) == 'XC', '90' assert checkio(91) == 'XCI', '91' assert checkio(94) == 'XCIV', '94' </pre> When I accidentally switch "XC" with "CX" in my code, the test clearly shows a problem, it is really simple to decide if the test or the code is wrong, and in this case the code is fixed quickly.

veky on Oct. 29, 2014, 8:56 a.m.
Now you're changing the subject. Wasn't the original point about detecting bugs? Of course, if you write (d,c,j), almost all of results will be wrong, and the fact that there is a bug will be obvious. Now about fixing, of course this will be a problem, but precisely because of what you said: the code is not very readable, spacing is sparse, variables have single-letter names, and so on.* It is not hard to fix because algorithm is complicated. In fact, if variables had nicer names (nothing fancy, just "one", "five" and "ten", for example), it would be easier to see exactly what's wrong than swapping X and C in your code. * (I admit these are all very concrete problems, but these have nothing to do with the discussion. You can open a separate thread if you want to discuss that, but basically, it was a long time ago, I was new here and had no idea how things work. It's written in Py2, for goodness sake. If you know me here, you know I'd never consciously publish something written in Py2.:) No, my point isn't "the code doesn't have a bug". My point is that this style of coding makes bugs totally obvious, and affecting much of the problem domain on a structural level, while your style of coding is totally dependent on really good unittest coverage, and even then you can never be sure. Ok, let's say I believe you that before this discussion, you really wrote such a test suite, that has three tests affecting just XC token. First, you have to admit, now you're weirder (for a Python programmer) than I am.;-) I know of noone that would support such a simple problem with a battery of about thirty tests. And if you tell me XC was somehow specially overrepresented in your testing (before I pointed out how easy it is to swap X and C on a keyboard), then I simply won't believe you. ;-P But second and more important, what are you doing? Why haven't you published your test suite together with your function, if it is really such an integral part of code? My interpretation is that you're somehow embarassed by it. You're, in fact, trading structure for length, claiming that structure is hard to understand. But if I want to see if your code is really so good, I must read the tests, too, right? Now we're speaking about 10 vs. 50 lines. No, sorry, I don't think your code is five times simpler than mine. Third and not easily ignorable: how do you write those tests? By hand? And in the team, do you always take care that not the same person writes code and tests? If you do, great. But I still think my approach scales better. [Might be because I have tried your way, but I think you haven't tried mine.;]

maurice.makaay on Oct. 29, 2014, 12:36 p.m.
I did not publish the tests, since they are not required for the solution to work. To me, they are mainly a development tool and not an integral part of the solution. I didn't think I'd make anybody happy when I'd submit those as well. I am not in the least embarrassed by it. Yes, we almost always write tests by hand. For some cases, we use code generation techniques to generate tests, but that is a really small subset of our total test base. In TDD, the coder writes his own unit tests. That is a good thing. I am not sure why you would want the unit tests to be written by another person. That defeats the purpose. Pair programming could be a solution for what you would be trying to solve there. For integration tests, we always let somebody else create the tests for that. The code was from my actual test set for this problem. If it makes you happy, I am willing to admit that I am apparently weird because I love the TDD approach. I do not like that you imply that I am lying about this. Therefore, I think it is best to stop this whole thread, since it is pretty much fruitless. Maybe others are better at explaining the problems that I have with your solution. Feel free to call yourself the winner if that pleases you.

veky on Oct. 29, 2014, 12:54 p.m.
Winner? That's strange, since I changed the category, and as far as I see, that's all you wanted from me. And I admitted that code is not very readable, though it is tangential. And still I lost two thumbs. I think it's obvious who's the winner. :-)

ryan.n.goodner on Nov. 12, 2016, 5:58 a.m.
wow

veky on Nov. 12, 2016, 8:03 a.m.
Wat? :-)

GitHub

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.