How Calculators Crunch the Integrals You Cannot Solve
Audience:
Tags: numerical-analysis
This is a brief introduction to numerical analysis — the art of programming computers to do mathematics quickly and in a stable manner —, all with the objective of understanding the integration method behind HP calculators of the 1980’s (HP-34C, HP-15C, HP-42S, …); it contains many figures to develop intuition, and some interactive exercises for the reader to practice.
Analytics
Comments
I think that overall, this was a good article. It provided a good summary of some numerical methods for integration which built off of each other well. There is a level of formality which will benefit some audiences more than others. The exercises were also helpful and engaging although for some of them I think some discussion of the answer might be useful, especially those like the second one which asks “why does this happen?” Kahan’s technique probably should have been elaborated more. It is a non-obvious trick and is framed as the climax of the article but is not proven nor are examples provided in the main text. The rest is very informative but the article would have benefited from more exposition being put into the last part.
One of the best ways I’ve seen to integrate (ha) numerical methods and pure math. Wonderful!
I would have liked to see a full implementation of the methods.
Overall, great piece! I thought everything was fairly clear and well structured. I especially loved the interactive coding blocks, that’s definitely the aspect that stands out the most and has a lot more interesting room for growth in future pieces. Every numerical analysis textbook feels like an outdated and boring endeavor to work through. Maybe more broadly, that’s true for every coding book out there! This method of teaching concepts with coding by interspersing integrated and easily approachable coding examples within the document itself is great! I’m excited to see more of what you do with this pedagogical tool going forward. Now enough good stuff, here are some of my criticisms throughout:
In the newton interpolation section, your description of how the divided difference notation works in works is very cumbersome, a visual aid would be better instead.
What do you hope to achieve with the example code sections? Is it for familiarity with the code and commands themselves so people can use this as a resource to return to when writing their own code? Or is it to mess around with examples to gain intuition for the math? If it’s the latter I don’t think you need to have people type in the code following your directions for the more complex steps like in Newton interpolation, you could just have the code block already written and ready to execute/edit. This would also avoid the annoyance of not being able to copy paste the commands you suggest. Alternatively, simpler code like in the trapezoid versus simpson’s section is easy to play around with right away and avoids this issue altogether. If the point is in some part to introduce numerical analysis coding know-how, you might give a code block example with more explanation and ask the reader to write their own code for a variation/extension of the example.
I might make the example prompts in the interactive code sections separate from the actual command line so they’re always readable. For certain sections it became annoying to have to scroll back and forth to the prompt as the command line history got longer.
Small typo in Trapezoids and Simpson’s rule: “interopolating”
Great concise and clear proof of the exact math of interpolating polynomial integrals with the next higher degree. Never understood that intuitively until now.
Once I get to the Richardson extraction section, I’m starting to feel that there’s a bit too broad a focus on content. I’d recommend trimming your piece to dig deeper into fewer topics.
Lastly the Kahan substitution feels like a somewhat weak ending, narratively speaking at least.
the english is hard to follow, tbh
the best part of the post, maybe, imho:
A plot will explain it better than 100 paragraphs of my prose.
which should’ve happened waaaaaay earlier
the mathematics is rigorous, the figures are communicative (albeit there are too few of them), and the “interactive” web-cli is fascinating. but the overall article loses me way too quickly
i think the biggest issue for me is the storytelling/readability rather than the mathematics itself. i often found myself wondering whether i was missing something in the english, rather than being pulled along by the problem
for a math-communication post, maybe relax on the rigor a bit. let the reader experiment with the figures and web-cli. (otherwise you’ll end up being one of those “scary” textbooks that no one enjoys reading)
tl;dr: more figures, earlier figures. intuition first, rigor later.
The graphs are really hard to see/read. (Line weight and line colour vs. background colour in general. Dashed grid lines in black in particular are way too harsh.)
Also, footnotes on a blog should hoverable. I.e. a small pop-up when you hover the footnotes that show the actual footnote text. Or they should be hyperlinks. No one is scrolling to the end of a blog and back again.
That aside, the article itself is very well written.
It was an interesting blog post to read, which gave me more insights into numerical integration methods and why they work so well. I have encountered Romberg’s method in code, but up to know I did not understand why it is so efficient. I also appreciated the possibility to try out code in the terminal and play around with the presented methods. However, I felt there was a bog detour from stating that you will look into Kahan’s method to actually presenting Kahan’s method. I am not sure if all the information in the bog post would have been necessary to understand Kahan’s method.
Some things that could improve the work:
- It would be good if it were possible to copy&paste code from the terminal into the terminal. For example, when trying out Newton interpolation I could not copy and paste the code from the terminal, which made testing the suggested functions a bit cumbersome.
- When explaining IEEE 754, it is a bit confusing that the bit representation of 2.875=1.4375*2^1 only represents 2^1 and 0.4375. After some searching, I realized that there is apparently an implicit hidden bit, which represents the number 1 of 1.4375. This should maybe be explicitly mentioned
- After the definition of the big-O notation a figure is presented. Maybe I didn’t understand the definition but based on the definition, I don’t understand how in the figure. To me there does not exist a lambda such that because is a oscillation function, while seems to grow monotonically.
- The divided differences method is hard to understand because it mentions a table but the table is never shown. While one can create a table in the terminal, the table is hard to read (at least on my laptop screen)
- When comparing different methods it would be good to show how their approximation looks graphically for the same function. For example, comparing the trapezoid rule and Simpson’s rule on the same function instead of having different functions in the figures.
Great, though I didn’t really bother with the console thing.