Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

http://www.amazon.com/Measurement-Paul-Lockhart/dp/067405755... (by guess who) looks like the best starting point since this resonated with you. (I've dipped into it but not seriously tackled it yet.)

It's hard to keep at it, learning on your own. I sometimes find problems where the usual solutions or explanations feel kind of ugly, and try to make them cleaner, like rewriting someone's code. (A couple days ago it was Snell's law: this optics tutorial http://www.bigshotcamera.com/learn/imaging-lens/refraction linked from HN just dropped this formula down, and to most kids it's going to be magic. Can you formulate the law of refraction in a more elementary way and derive it from some simple assumptions? I did come up with a version that never mentions sines, but I'm not really satisfied and it's gone back on the to-do list to try to take it further. See: hard to keep at it.)

More generally, this kind of work can come up all the time when programming if you say, "No, I'm not going to look up the algorithm, I'll work one out for myself and then see what's been done." Occasionally you find something kind of new that way, besides often deepening your appreciation of the usual solutions. For example, last week I found a new way to avoid the epsilon-loops in Thompson's regular-expression search algorithm -- new to me, at least. This has minor significance and came out of a ridiculous amount of work rediscovering things taught in automata-theory classes, but Lockhart wasn't kidding: it's a rush when you figure it out.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: