There and back again scary solution for Clock Angle by veky - python coding challenges

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

There and back again solution in Scary category for Clock Angle by veky

def clock_angle(time):
    from cmath import rect, phase
    from math import radians, degrees
    h, m = map(int, time.split(":"))
    return degrees(abs(phase(rect(1, radians(30 * h - 5.5 * m)))))

Oct. 29, 2014

Comments:

hanpari on Nov. 8, 2014, 8:50 p.m.
Well, I thought SCARY category is something different. At least, I understood it like this: <a href="http://www.checkio.org/mission/clock-angle/publications/hanpari/python-3/awful-story/">http://www.checkio.org/mission/clock-angle/publications/hanpari/python-3/awful-story/</a> Am I wrong?

veky on Nov. 10, 2014, 7:42 a.m.
I have no idea whether you're wrong. And that's the problem. This whole category business is completely missing the mark as far as I'm concerned, and that's why I'm mocking it whenever I can. But hey, don't you find cmath.phase and cmath.rect scary? Oooh, it's trigonometry... BWAHAHA. :-D BTW nice idea about a story, but it can be taken much further. All the operators can be renamed, for instance. ;-) <pre class='brush: python'>something_scary = int.__add__ </pre>

hanpari on Nov. 10, 2014, 12:19 p.m.
I suggested long ago some category for beginners. In fact, it might be SCARY :) I just check cmath modul and it seems to have useful functions not even for complex number. Thank you. All the time I learn something new from you :) It is fine idea with renaming operators. I was actually surprised by myself when I saw the resulting non-pythonic jibberish. I have to try describe my solutions directly in code like this :) By the way, I have question about map and filter functions. Are they useful anymore when comprehensions do the same trick?

veky on Nov. 10, 2014, 1:55 p.m.
<blockquote> I just check cmath modul and it seems to have useful functions not even for complex number. </blockquote> Well, it's complex math. It's almost all functions from math module, but working correctly on complex numbers. E.g. math.log(-1) is ValueError, but cmath.log(-1) is ipi. :-) <blockquote> Thank you. All the time I learn something new from you :) </blockquote> Glad to hear that. ;-) <blockquote> By the way, I have question about map and filter functions. Are they useful anymore when comprehensions do the same trick? </blockquote> Excellent question. <h2>First let's say the obvious.</h2> <pre class='brush: python'>map(sum, matrix) </pre> is nicer to see than <pre class='brush: python'>(sum(row) for row in matrix) </pre> especially when you need that outer parentheses, for example when it's a nononly argument of another function (then it starts to look LISPy:). Especially, <pre class='brush: python'>filter(cond, seq) </pre> is much nicer to see than <pre class='brush: python'>(item for item in seq if cond(item)) </pre> with its bulky threefold repetition of item name. This goes together with another thing: map and filter are composable in any order, comprehensions require filter first. If you want to filter mapped values, you must repeat the transformation, or resort to ugly code like extra iteration over one-element list. <pre class='brush: python'>filter(cond, map(trans, seq)) </pre> you can write like <pre class='brush: python'>(trans(item) for item in seq if cond(trans(item))) (result for item in seq for result in [trans(item)] if cond(result)) </pre> but the first is WET* (slow if trans is expensive, wrong if it has sideeffects) and the other is ugly. Beautiful is better than ugly. ;-) * If you haven't heard: <a href="http://en.wikipedia.org/wiki/Don't_repeat_yourself">http://en.wikipedia.org/wiki/Don't_repeat_yourself</a>#DRYvsWET_solutions <h2>And now for something not so obvious.</h2> Most people think comprehensions "do the same" - and probably the BDFL thought the same when he decided to remove map and filter (and lambda and reduce) from Py3K. In the meantime he changed his mind - probably because he realized that in dynamic language such as Python, things might not be so equivalent as one might think. First, do you know why I wrote () above instead of []? If you didn't, you should learn the difference between generator expressions and list comprehensions. Many people get them confused. The main difference is the point of evaluation. List comprehension <pre class='brush: python'>[f(x) for x in S] </pre> applies f to xes from S at the point of evaluating that list comprehension, while analogous generator expression applies f to them at the point of iterating through the result. It could make a difference if f has a side effect (try it with f=print:), but more importantly, it could make a difference if f changes in the meantime. <pre class='brush: python'>def f(x): return x+1 S = [5, 7] a, b, c = (f(x) for x in S), [f(x) for x in S], map(f, S) def f(x): return x+2 print(list(a), list(b), list(c)) </pre> Why would someone change (rebind the name, in fact) a function like that? Yes, it's not so usual. But if you look better, I didn't change the function very much: I just changed a parameter from 1 to 2. Let's formalize that: <pre class='brush: python'>def P(p): def f(x): return x+p return f S = [5, 7] p = 1 a, b, c = (P(p)(x) for x in S), [P(p)(x) for x in S], map(P(p), S) p = 2 print(list(a), list(b), list(c)) </pre> (Of course, P(p)(x) can be uncurried, but that's not important.) You see? map evaluates the function (and the iterable) at the point of construction, yet applies it at the moment of iteration. It's not so easy, and practically impossible in one line, to write it either as a genexp or a listcomp. Yet, in highly dynamic programs, it might be exactly what you need - for example, if f is a bound method, and self changes in the meantime. ;-) Clearer?

lsdda on Nov. 22, 2014, 8:38 a.m.
This is very helpful. Thanks Veky.

hanpari on Nov. 10, 2014, 3:17 p.m.
This is great article. You should publish it. Though I know differences in evaluation of list and generator comprehension, it never came to my mind I could use map and filter instead. This is maybe because I started with python 3.X and have never used 2.X. Thank you for your time and great learning source :)

veky on Nov. 10, 2014, 3:53 p.m.
I also started with Py3 and never used Py2 (except when explaining something to someone on CiO who won't use Py3 for political reasons:). But through experimentation and reading source, and reading mailing lists, and BDFL proclamations, I found out map and filter are not as simple as just a genexp, and also not as just a listcomp. :-) Maybe one day I publish something like this... many people are persuading me to. But I still don't think it's so interesting to someone outside CiO. :-)

hanpari on Nov. 10, 2014, 4:03 p.m.
I believe there is python world never touched by checkio. For example, I tried to find out how many checkio members is amongst blender pythonists. And I have failed utterly :( <a href="http://blenderartists.org/forum/showthread.php?351411-Do-you-know-checkio-org&highlight=checkio">http://blenderartists.org/forum/showthread.php?351411-Do-you-know-checkio-org&highlight=checkio</a>

veky on Nov. 10, 2014, 4:10 p.m.
Hm, here's one more point for your statistics: I never heard of Blender. :-D

hanpari on Nov. 10, 2014, 4:14 p.m.
What? This is not normal! <a href="http://www.blender.org/">http://www.blender.org/</a> We are living on different planets, then :)

veky on Nov. 10, 2014, 6:40 p.m.
Well, of course I checked it out when I read your previous post. But thanks for the link anyway. :-) Yes, and you're the only astronaut here, hopping between those two. :-D

hanpari on Nov. 10, 2014, 6:50 p.m.
There are a lot of challenge in 3d world. Do you think you can do in python retopology tool to substitute manual approach by automatic? If you have time, try to watch this to see the problem in question: <a href="https://www.youtube.com/watch?v=icqPZnD_3lA">https://www.youtube.com/watch?v=icqPZnD_3lA</a>

veky on Nov. 10, 2014, 7:16 p.m.
I think you don't realize how technical this video is, and completely nonunderstandable to someone who never did anything 3D (except primitive isogrid on a Casio calculator a long time ago in high school:) on a computer. I was completely lost after 2 minutes.

hanpari on Nov. 10, 2014, 7:37 p.m.
Sorry, about that. I was playing with this stuff for too long. You can see this picture: <a href="http://blenderartists.org/forum/attachment.php?attachmentid=279936&d=1388601589">http://blenderartists.org/forum/attachment.php?attachmentid=279936&d=1388601589</a> Retopology means replacing given mesh by more meaningful polygon model. Imagine for example result from 3d scanner. It is set of 3d points scanned by cameras or laser sensors. <a href="http://www.robotshop.com/media/files/images/makerbot-digitizer-desktop-3d-scanner-9.jpg">http://www.robotshop.com/media/files/images/makerbot-digitizer-desktop-3d-scanner-9.jpg</a> Then, you make them into polygon mesh. But it is too dense and you want it simplify. And there are many ways to make retopology (as shown on the stone picture). Best retopology is made manually by graphic as seen on the previous video. And the challenge I was speaking about is to make python addon to simplify 3d mesh to have mesh similar to perfect human-made topology as seen in this example: <a href="http://tomparkersartdump.files.wordpress.com/2011/07/topology_breakdown.jpg">http://tomparkersartdump.files.wordpress.com/2011/07/topology_breakdown.jpg</a>

veky on Nov. 11, 2014, 6:49 a.m.
Ok, now I understand the problem, but of course I have no idea how to go about solving it. :-) But few very general things come to mind. First, if best solution right now is human, then obviously we're not trying to find anything exact, we're just trying to approximate something that looks good enough. And second, for the same reason, the algorithm doesn't have to be fast (it just need to be faster than a human clicking here and there:), it only needs to be possible. So, these two things are telling me that some kind of heuristic approach might be best. First, use ordinary gradient variation as a first approximation. Then show that to people and ask them to fix it. Look at them work. Ask them how they went about it. And try to incorporate that vague rules into some kind of neural network that will collectively decide what polygons to merge, and what to split. I don't imagine I have been useful, but maybe I gave you some ideas. :-)

hanpari on Nov. 11, 2014, 7:34 p.m.
I like your observation about needed time. All retopology tool are working rather fast and this is why the result might be not exactly useful. But it is for sure that tool which works slower but more precisely can safe human time. "Ordinary gradient variation" is out of my knowledge but I believe you are right in the sense that gradient would be useful to solve the surface changes. My last impression reading your lines is related to one addon in which his author is trying import numpy which is not included in Blender with remark it would be great to have tool like this. In fact, I am not using numpy but sometimes I have impression that python is not good equipped for work with matrices. Tuple of tuples or list of list are really painful. Thank you for your time. I hope you liked this small tour to Blender. By the way, I believe you might like video of physical simulation from Blender. It is really impressive :) <a href="https://www.youtube.com/watch?v=KQMZ2mE-8HI">https://www.youtube.com/watch?v=KQMZ2mE-8HI</a> <a href="https://www.youtube.com/watch?v=f4mbi_GOvm0">https://www.youtube.com/watch?v=f4mbi_GOvm0</a>

veky on Nov. 11, 2014, 9:23 p.m.
By "ordinary gradient variation" I just meant a horribly naive algorithm, like: <pre class='brush: python'>fix maxgradvar and minarea pick a yet unpicked polygon P (e.g. one with greatest area) of all polygons adjacent to P, choose one with gradient closest to P and join it with P updating gradvar with gradient difference repeat that until gradvar > maxgradvar and area(P) > minarea repeat the above until there are polygons left </pre> <blockquote> numpy which is not included in Blender </blockquote> OMG. I thought you 3D people (yes, I anticipate the pun, I'm flat:) eat matrices for breakfast. You don't have numpy? Are you sure there's oxygen in the atmosphere of your planet? :-D <blockquote> I have impression that python is not good equipped for work with matrices. Tuple of tuples or list of list are really painful. </blockquote> That's why I use dicts with complex keys. ;-D Joking aside, I agree with you. The standard excuse is "it can be emulated using a dict with tuple keys". But that's like removing list as a type, since it can be emulated using a dict with keys from range. list is much more than that, and the fact that its indices are restricted is incredibly useful for many operations - slicing, for just one example. Python needs a type that is to dict with tuple keys as list is to a dict with keys from range. There are many contenders, but none is just right. It is a hard task, since there are much more design decisions to make (for example, how to iterate through that? Is rectangularity essential?...). Dataframe from Pandas is too bureaucracey, array from numpy is too value-semantical, custom classes are lacking standardization and always missing something,... But I'd be optimistic. Eppur'si muove: Py3.5 will get @ operator for matrix multiplication, which is a precedent since no builtin type implements it. It seems everybody is waiting and preparing for arrival of such a type. :-)

Dropbox

0 %

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