Live data from Hacker News

Gears

ciechanow.ski

211–220 of 230 posts

Re: Gears

#211
post #34

This is an absolutely phenomenal 'explorable explanation'. It methodically layers concepts to foster understanding, deploys interactivity to build intuition, and on top of all that provides crisp, clear narrative on top of all of the amazing visualizations.

We are all sitting here in collective awe, and the JS source contains this header: > /* Dear explorer, this code works, but is by no means of high quality. Once a post is written I don't go back to the source code again and the formatting, robustness, DRYness and abstraction choices reflect that. */ https://ciechanow.ski/js/gears.js

What is your point? Are you saying that it's bad he didn't tidy up the source?

Re: Gears

#212
I would need additional proof that gears were designed with many of these mathematical considerations in mind and didn't just arise out of trial and error by the machinists

Re: Gears

#213
post #146

Earlier quoted context omitted.

Thanks for the JS files. Would be nice to know about his process. Here it appears he is importing the graphics from somewhere else converted to imperative drawing code: https://imgur.com/jFpN0f3.jpg

That's just a function that draws a spanner.

Obviously, but my point is that if you look at the coordinates these do not seem to have been handwritten.

Re: Gears

#214

The most important section is on involute curves. It's the curve formed by unwinding a string against the circle: https://ciechanow.ski/gears/#strings-attached It creates a constant angular velocity ratio at all points where the gears mesh (the law of gears). In layman's terms, the tip of the tooth gets thinner so that the angular velocity there is reduced at that larger radius. Otherwise the gears advance/retreat as…

I wrote a CAD package in Go that has a function for it.

https://github.com/deadsy/sdfx

  func InvoluteGear(
   numberTeeth int, // number of gear teeth
   gearModule float64, // pitch circle diameter / number of gear teeth
   pressureAngle float64, // gear pressure angle (radians)
   backlash float64, // backlash expressed as per-tooth distance at pitch circumference
   clearance float64, // additional root clearance
   ringWidth float64, // width of ring wall (from root circle)
   facets int, // number of facets for involute flank
  )

Re: Gears

#216
The writing and interactive examples are really amazing. Would deffo read the entire series of articles. Gonna bookmark it.

Re: Gears

#217

The most important section is on involute curves. It's the curve formed by unwinding a string against the circle: https://ciechanow.ski/gears/#strings-attached It creates a constant angular velocity ratio at all points where the gears mesh (the law of gears). In layman's terms, the tip of the tooth gets thinner so that the angular velocity there is reduced at that larger radius. Otherwise the gears advance/retreat as…

Cycloid gears are used in roots-style superchargers. I learned about the shape back in college when I thought I was going to build one from scratch.

https://en.wikipedia.org/wiki/Roots-type_supercharger

Re: Gears

#218

Earlier quoted context omitted.

We are all sitting here in collective awe, and the JS source contains this header: > /* Dear explorer, this code works, but is by no means of high quality. Once a post is written I don't go back to the source code again and the formatting, robustness, DRYness and abstraction choices reflect that. */ https://ciechanow.ski/js/gears.js

What is your point? Are you saying that it's bad he didn't tidy up the source?

I think potentially pointing out the humility of the author. But unsure.

Re: Gears

#219
post #162
post #154

Earlier quoted context omitted.

That's true, and like everything I'm sure writing JS visualizations gets faster with practice, and you become more familiar with the tools. Still, after finishing the article, I'm impressed by not just the the number visualizations, but by their legibility and smoothness. I can't in any universe imagine it taking less than a week of full-time work. If you told me it took a month of full-time work I wouldn't be surpri…

> Still, after finishing the article, I'm impressed by not just the the number visualizations, but by their legibility and smoothness I think the author probably had to try a lot of things before hitting on such a well-balanced set of visualizations: not too much detail, not too little, not too many degrees of freedom, not too few, usable on hand computers, usable on laptops. But I think that if you gave someone the…

I'm with you that there can be an illusion of fluency, but I don't think that casts any doubt on the value of the article.

Most people will read it and say "fun" (including me, since I don't work with gears) and maybe 5-10% will go on to do something else with it, but that's working as intended.

I agree you can't really say you know something without testing the knowledge. You need to do more work to test whether you know it or not, but having the concepts and words at hand is a prerequisite for that. I'm certain if I were to actually work with gears I would come back to this article. (I would probably also learn where it falls short in practice, but I would learn that about any resource AFAICT.)

-----

Testing your knowledge is one reason my brain flipped from math to programming over 20 years. Math is hard to test but programming is easy to test.

However, one thing I found surprising is that publishing tests your knowledge, but writing does not. I would categorize Dercuano as writing but not publishing at the moment.

It tests it in exactly this way:

https://news.ycombinator.com/item?id=22033792

Blogging is a public act. Anyone can read this. When I write a blog post, I imagine my supervisor, a respected colleague, or a future employer reading my explanation. These imagined readers force me to ask myself honestly if I understand what I am writing.

I found the same thing while writing my posts on https://www.oilshell.org. If someone digs this up in 5 years, is it going to look dumb? And of course simply not knowing something is not dumb, but pretending you know something you don't is dumb (likewise with promising something you can't deliver, which I've been careful not to do).

I can see there are a lot of great ideas in your notes, but I have 100% certainty that polishing those ideas will lead to a better understanding, more ideas, and forcing a focus. The writing alone alone doesn't cut it. (I know because I also have 3382 personal wiki pages with notes and URLs accumulated over 15+ years with overlapping research!)

I would definitely comment on drafts. I was paid to review the second edition of Effective Python last year, and am also reviewing a book for a friend currently, so I have some experience with that. I'm most interested in the posts on parsing, automata, languages, compilers, and (parallel) algorithms -- I have less experience with graphics. I didn't know you were working on HAMMER -- that line of research is also in my wiki pages and I have several thoughts about it. I'll send you a mail with the ones that jumped out at me.

Re: Gears

#220

Earlier quoted context omitted.

I think it definitely is more appropriate in some domains than others. Sometimes you can replace 1000 words with a picture, 100 pictures with a video, and 10 videos with an interactive visualization. In that case, it might not actually be more work. I think the problem is that it's very different work, that professors aren't trained for. Again, it's not easy, maybe impossible. But if it could be done... PS - I see yo…

Bear in mind that some people are more visual, so I think the interactive visualization should serve as a complement to the 100-1000 words that describe it, not an in-place substitution... (Also, let's not forget about the visually impaired, which need the interface to be accessible).

On average, vision is by far the most important sense for a human. Would you reduce the experience for most people in order to help the minority, especially when there already exist so many text-first books?
Post reply on HN