Live data from Hacker News

Gears

ciechanow.ski

161–170 of 230 posts

Re: Gears

#161
post #147
post #35

Earlier quoted context omitted.

Having been down this road, yes, it does take time, but you can save some time by using SVG and some DOM library. Although canvas is faster, most diagrams don't really need it, so I use SVG unless I really need to switch to canvas. SVG also adjusts for screen dpi automatically. The things I like: 1. Reactivity (ObservableHQ, Vue.js, hyperactiv.js, etc.). There's usually some underlying data and then a corresponding v…

Thanks for these tips -- I've seen your visualizations and it's nice to hear from people who have done it! It's cool that you were able to reproduce the diagram quickly and in a small amount of code. It looks a bit foreign to me, probably because I don't know much about SVG (or canvas for that matter). And as I understand it Observable is almost another language on top. (I do know HTML, CSS, and JS pretty well, but t…

SVG is declarative. You write to make a red circle at (300,400) with radius 100. You can then change any of these properties and the system will redraw automatically. Canvas is imperative. You write ctx = canvas.getContext('2d'); ctx.fillStyle = "red"; ctx.beginPath(); ctx.arc(300, 400, 100, 0, 2 * Math.PI); ctx.fill(); and the system will draw that circle. You handle redraw yourself by redrawing everything on that canvas, so you need to keep track of it all. The DOM helpers (React, Vue, etc.) help you with SVG but not with Canvas.

I usually mock visualizations on paper! I'm interested in using WYSIWIG interactive diagram tools like http://aprt.us/ but I never seem to get into them. When I started, making the visualizations was the largest part of the work, but now I've gotten better at it, and making the explanation is now the part that takes the most time.

After paper, I often use SVG to make a non interactive diagram, either by hand, or in inkscape. One of my guiding principles is that the page should be usable without interaction, so the static diagram is a test of that. If it looks promising I can then gradually transform it into an interactive diagram. For example if I had the circle above, and I am using vue.js, I can change it to (note the ":" before attributes), and then vue will fill those values in from the object I give it. I can give it {x: 300, y: 400}, and any time I change x or y, it will automatically redraw. I can then hook up x or y to a slider to try out the interactivity. This allows me to start with a static diagram, gradually add interactivity, and then build reusable abstractions that I can apply to multiple diagrams. ObservableHQ and React/JSX allow something similar, with slightly different syntax.

I'd love to see an article about regexes with interactive diagrams. There's a standalone diagram tool https://regexper.com/ and an interactive tutorial https://regexone.com/ but neither is an essay in the style of the Gears article. If you're pursuing this, let me know at redblobgames@gmail.com and I can send over more resources.

Re: Gears

#162
post #154
post #43

Earlier quoted context omitted.

Writing a small program takes much less effort per line than writing a large program, especially if it doesn't have to be maintainable and extensible, especially by other people. http://canonical.org/~kragen/sw/dev3/circlegrid.html only took me three hours of JS hacking, and it's like 200 lines of code. The simplified version of the basic COCOMO model in David A. Wheeler's "SLOCCount" is Person-Months = 2.4 * (KSLOC…

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 web page to look at and asked them to make similar visualizations, it would probably take them a day or two.

> I would say you can go a lot further than you think in bridging the gap.

You might be right, but I'm kind of cynical about it. I think it's easy for people to fool themselves into thinking they understand things after seeing a good explanation. Nova on PBS resulted not in rapidly advancing physics from the generation of kids who grew up watching it, but instead Deepak Chopra and The Secret — the fruit of the illusion of fluency without the corresponding skill.

Worse, the educational system is in many ways optimized to promote the illusion of fluency. You have textbooks of the variety Feynman complained about, with the wakalixes. You have semester-long self-contained courses, discouraging spaced learning. You have pre-announced big-bang exam dates for those courses, so students game the system by cramming to get better grades. In many cases you have multiple-choice tests to make grading easier, so guessing the teacher's password is the highest-return gaming strategy, even if often insufficient by itself. The whole educational experience is compressed into a degree program of four years or thereabouts, further discouraging spaced learning. Students rarely attend any classes they aren't getting credit for, even though this is technically permitted at most universities I've visited. It's a commonplace observation that students forget almost everything they "learn" within a few years. So the idea students get of learning is very different from what learning is; schooling systematically distorts their ability to evaluate whether they are learning or not. (Paul Graham has explored this theme from a different angle in http://www.paulgraham.com/lesson.html as well.)

How would we distinguish a universe in which this beautiful post on gears successfully transmitted learning to its readers from a universe in which it only transmitted the illusion of learning to them? In both universes the post is popular. In both universes people say things like "I wish I had this in high school!" But in one universe people are able to do things they couldn't do before; perhaps design gear trains for 3-D printing that show up in Hackaday projects, or perhaps laser-cut unusual gear-tooth profiles with different pressure angles or different depthing/ripple tradeoffs or something. But that could take a while, and it might be really hard to trace back. Is there a lower-latency indicator we could observe, even if it's something hackable like school exams?

I don't want to sound like I'm above all this. I feel like I have new gear knowledge from reading this post, despite having read hundreds of pages about gears and watched hours of gears videos previously; it happens to be something I can state, namely that the pressure angle always needs to point at the point of tangency of the pitch circles. But I'm not yet sure if that's really true or what happens if it's false (you can definitely design gears for which it is false). I'd need to struggle with the problem for a while in order to really understand it.

(A different learning effect would be that people learn that posts like this are very popular and make more of them, having been inspired by this one. I'm pretty sure that will happen whether or not people learned things about gears from this post.)

> This ties in nicely to your Dercuano notes which I have had open in my browser for awhile! There are many interesting topics there. But I also feel like you went to the other extreme and there's a lot of interpretive labor involved in reading them :)

Thanks, that's flattering! I'm glad you're enjoying it. Are you using the HTML version or reading the raw Markdown?

> Why did you decide to polish and publish the "memory models" post?

I don't know. I think it was just random chance. I enjoy doing that kind of thing but I don't do it very often. Even memory-models is pretty unfinished and has some parts that are pretty raggedy.

> I could send you the notes that jumped out at me if interested.

Sure, that would be wonderful! If you wanted to commit to commenting on further drafts within some timeframe, that would probably help motivate me to work further on them.

----

I want to be careful to disclaim a particular interpretation here. In "Real Programmers Don't Program in Pascal" it says, "If it was hard to write, it should be hard to read." I don't believe that. I don't believe that if something was hard to discover, it should be hard to learn. I think we should make learning as easy as possible, and I agree with the post you linked that this benefits from improved explanations, and that improving those explanations takes a great deal of work.

But I have been burned many times even by my own illusion of understanding, let alone those of Freud and Chopra, to the point that I am wary of it. It is well that we remember, as Euclides said, that there is no royal road to geometry; a good tutor can save a student from remaining in error and from failing to notice the importance of something they could learn, but ultimately the student is the one that must do the hard work of constructing the knowledge within their own mind.

Re: Gears

#163

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…

Geartrax software, it will draw perfect involute splines.

Re: Gears

#164
post #136

Earlier quoted context omitted.

Have you considered fibre reinforced plastic? I'm not an expert but I'm curious if that's a good option.

I’ve seen fiberglass reinforced nylon gears used with success in commercial injection molded gearboxes. It can definitely help by increasing gear stiffness. However 3D printing with fiberglass causes rapid nozzle wear, and recently people are saying that fiberglass reinforced 3D printing filaments represent a human hazard. Since I’ve managed to get my gears to work without reinforcement, I’ve not tried it. One thing…

[deleted]

Re: Gears

#165
post #136

Earlier quoted context omitted.

Have you considered fibre reinforced plastic? I'm not an expert but I'm curious if that's a good option.

I’ve seen fiberglass reinforced nylon gears used with success in commercial injection molded gearboxes. It can definitely help by increasing gear stiffness. However 3D printing with fiberglass causes rapid nozzle wear, and recently people are saying that fiberglass reinforced 3D printing filaments represent a human hazard. Since I’ve managed to get my gears to work without reinforcement, I’ve not tried it. One thing…

Have printed many spools of CF and glass filled nylons using nozzles with tips made from ruby.

Check out “Hardcore Ruby” nozzles, now there are even diamond nozzles.

I print with 0.25mm nozzle in nylon, fine enough for Module=1.5 teeth.

A 0.15mm nozzle would make an acceptable Module=1 gear I would guess.

Re: Gears

#166
post #134

Earlier quoted context omitted.

Anyone that is fascinated by gears owes themselves a visit to This Old Tony's video on YouTube titled "Gears! - But Were Afraid To Ask" https://www.youtube.com/watch?v=Q-XOM4E4RZQ He goes into the nerdy depths of gear make-up, metallurgy, meshing, machining and mistakes as he manufactured metal gears on a mini-lathe.

I second TOT, his videos are just fun to watch. Plus, you learn something.

Going through his page, I immediately thought of his video on gears. Suprise! when it was mentioned at the end.

Re: Gears

#167
post #45
post #35

Earlier quoted context omitted.

Having been down this road, yes, it does take time, but you can save some time by using SVG and some DOM library. Although canvas is faster, most diagrams don't really need it, so I use SVG unless I really need to switch to canvas. SVG also adjusts for screen dpi automatically. The things I like: 1. Reactivity (ObservableHQ, Vue.js, hyperactiv.js, etc.). There's usually some underlying data and then a corresponding v…

Thanks for sharing these tips! I didn't realize you were trying out ObservableHQ too.

I love ObservableHQ! I think it's a neat model that fixes a lot of things I didn't like about notebooks. I don't use it much though. It makes the simple things easier but it makes the complex things harder. Examples:

1. I often start making a diagram interactive by adding a slider connected to some state. The slider/state is in one "viewof" cell and the diagram is in another cell. But for more polished work I often want to use direct manipulation, where you move something around in the diagram itself. In my usual JS+Vue code it's a small amount of extra work. But in ObservableHQ it seems like a lot of work: the diagram has to modify state defined in a different cell (breaking the simple spreadsheet model in my head), and the diagram is being re-rendered while it has event handlers active.

2. I often start out by making one diagram. This is nice and easy. But then I want to make multiple diagrams with some shared state. In my usual JS+Vue code I can lift the diagram code into a function, pass in a shared object for shared state, and instantiate objects for non-shared state. In ObservableHQ those properties are in cells, and I can't generate multiple cells programatically (afaik).

I also would prefer to host things myself, both because of longevity, but also because I sometimes work offline (e.g. in a park or on a train). And the biggest reason I'm not using ObservableHQ is that I'm so much slower editing text on it than I am in Emacs. So I continue to use ObservableHQ for some simple projects/prototypes but I don't do a lot with it.

Re: Gears

#168

While I appreciate the beauty this piece, I can't help but think of the irony of such a complicated piece to explain something which mechanics and engineers, who actually use gears, understand completely intuitively.

I'm not sure this is intuitive for many mechanics. I can remember studying for the ASVABs in high school (it has, or at least it did, have a whole section on spatial orientation and gears and pulleys), and it was pretty common for people to be flummoxed by the questions about picking which direction a gear in a set would turn when another was rotated. And this was with a set of people that tended to tinker on cars and snowmobiles all the time for fun.

Re: Gears

#169

sigh If I don't post it someone else will. Here's the spinning levers video you've all already seen a million times: https://www.youtube.com/watch?v=JOLtS4VUcvQ

It's been posted on HN a few times too, although without much discussion.

Re: Gears

#170
post #106
post #67

I didn't know anything about gears until someone filed an issue to tell me that a graphic on the Caddy homepage was wrong: https://github.com/caddyserver/caddy/issues/2949 Wish I saw this earlier!

It's funny how often that happens. A favorite example: https://en.wikipedia.org/wiki/Two_pounds_(British_coin)#Desi...

In case anyone else couldn't tell from the image and didn't want to read all of the history:

> An oddity of the design is that it depicts nineteen interlocking gears. Because there is an odd number of them, the mechanism could not actually turn.

Post reply on HN