1,667 karma · joined October 3, 2017
I haven't found a software solution for it. Instead, I bought a separate PC and just keep it running.
As long as there's nothing valuable in the technology itself why would I bother changing things?
I measured this for a contemporary Intel processor some maybe ten years ago and found out that 6th degree (actually, its 3 for x^2 since you can throw away all the even coefficients) makes sense performance-wise, yes the error is greater but that's the point of the trade-off. But even 8 or 10 is already doubtful.
Of course, there are architectures other than Intel and it might make sense to use higher order polynomials for better accuracy there.
E. g., you can get your approximation both smooth and continuous by adding the target derivatives in +-PI/2 into the Vandermonde matrix. The overall error may become higher with the same polynomial order but the approximation will be smooth.
This works fast, doesn't use the cache, and performs reasonably well precision-wise. It also has very small error in +/-PI/2 so, unlike with the Taylor's series, the continuation is virtually seamless.
Moreover, since cosine is symmetrical, you can throw away the even coefficients completely and it will become even faster.
I did plant a few trees myself but these were fruit trees and several years back.
This is fun!
For my wordsandbuttons.online , I have one rule - all the pages, no matter how interactive-rich, should take less than 64KB each. To get there, I write all my HTML, JS and CSS by hand. Should confess, I wasn't thinking much of the environment, it was mostly about user experience. But I'm happy that it pays of in this way too.
My average page produces 0.02 g of CO2, which sums up to a 1% of sumo wrestler over the year (or a full-sized sumo wrestler over a century), and it can be absorbed by only one tree (what a coincidence, I have my tree planted just last month).
So, who wants to turn it into a competition?
In 2017 I started https://wordsandbuttons.online/ as an experiment in unchitecture. There are no generic things there whatsoever. There are no dependencies, no libraries, no shared code. Every page is self-sustaining, it contains its own JS and CSS, and when I want to reuse some interactive widget or some piece of visualization somewhere else, I copy-paste it or rewrite it from scratch. In rare cases when I want multiple changes, I write a script that does repetitive work for me.
This feels wrong, and I'm still waiting when it'll blow up. But so far it doesn't.
Sure, it's a relatively small project, it has about 100 K lines along with the drafts and experiments. It is although inherently modular since it consists of independent pages. But still, this kind of design (or un-design) brings more benefits I could ever hope for.
Since I only code that I want on a page, every one of my pages is smaller than 64KB. Even with animations and interactive widgets.
Since all my pages are small, I have no trouble renovating my old code. Since there is no consistent design, I forget my own code all the time, but 64 KB is small enough to reread anew.
And since there are no dependencies, even within the project, I feel very confident experimenting with visuals. Worst case scenario - I'm breaking a page I'm currently working on. Happens all the time, takes minutes to fix.
I still believe in the golden middle, of course, I'll never choose the same approach in my contract work; but my faith is slowly drifting away from "design for the future" in general and "making things generic" specifically. So far it seems that keeping things simple and adoptable for the future is slightly more effective than designing them future-ready from the start.
However, since it's random, why do you have to stick to the daily regeneration? Could it be regenerated per request or is it somehow managed manually?
He also has a huge multi-volume textbook on differential geometry per se but I never read it. Probably brilliant as well.
1. Fishing an idea, investigating the details, programming a sketch of interactive elements. Then writing, and fitting the explorables to the narrative. Then editing. Then editing. And then editing. Then publishing, and apologizing for all the typos, errors, and mistakes that slipped through the editing process.
2. I started writing for the university newspaper back in college and the habit stuck. The hardest part for me is writing in English. I don't have the fully developed sense of language so it's like cooking without the sense of smell. Sometimes it's good, sometimes it smells fish. I just can't tell. Programming and maintaining my own "platform" appeared to be much easier than it looks.
3. There are two great motivational powers: making people you like happy; and proving people that don't believe in you wrong.
4. In my case it was simple. When I was young, I couldn't stay doing anything regularly. Not only writing but exercising, learning, going to work, all that things. But people around me who were older didn't seem to have any trouble with that. So I just decided to get older. And I did. Eventually. Now writing and programming for the blog is just something that I do daily after work and on Saturdays.
We can simply take what we want from English and incorporate it to our languages as specialized terms just as they do with Latin and Greek. I see this as a privilege.
So You Think You Know C And 10 More Short Essays on Programming Languages: https://wordsandbuttons.online/SYTYKC.pdf
But you don't want that. You want the underlying libraries to be fast and Python code to be cute. And that's the right way to go.
Part of my department's job is adopting the researchers' prototypes in Python and making them fast in C++. First of all, it's not about making them radically fast, it's about making them some 10% - 100% faster. I guess, the best I've heard about was 3x. Second, there were cases when C++ remakes were even slower than the prototypes in Python.
This phenomenon has an explanation. If 99% of what it does is done by NumPy, then we really compete with NumPy.
For instance, it might be built for more recent architecture and using better superscalars. Researchers can afford the very recent builds but we have to support a lot of users with a lot of PCs so we're basically stuck in 2010 with out target architecture.
And even this small detail matters more for the performance than the glue it was all brought together with.
But every once in a while I spawn them all across the code to hunt some bug, and then I think I got it, and I do the victorious "Aha!" and close the window. And, of course, it's not it and then yes it gets annoying to update the handlers.
But I tried that at the very beginning and it was rather inconvenient since I had to drag defines to every place I want to send a message from. "WM_USER + 'R'" might have worked but it's worse than "WM_USER, 'R'" aesthetically. And there is an extra parameter anyway.
PostMessage is also better for writing things to the counters since it's asynchronous. But it doesn't work for reading. It's just more convenient to have one function do both but of course you can post messages too.
It's a silly tool anyway. Basically made of compromises.
Not sure if it has its niche though. I mean, "stack based" is not really a feature on its own, and we have tons of options to do tensor processing in conventional languages; but the conception is awesome.
The only thing that bothers me is the possible schism in the culture. We will have communities where openness and meritocracy are valued more than being nice, and the ones with code of conducts. This would be hard to glue back together when the fashion for suppressing expression passes.
It's just you're getting older and it's time for you to find better balance in your life. Relax, you will not fall behind since we're all getting older. It's an even field.
And it's even worse with athletes. In engineering you're supposed to hit your prime at about 35-40. That's when an average footballer career is over. We're kind of privileged in that regard.
E. g. monitoring for mission critical servers. You really don't want the whole stack of unverified goodies on these machines, but since you already have TCP/IP for SSH, writing a simple web-server that reports machine health over HTTP is like a half-day job.
And it's verifiable since it's small. It doesn't drag the whole Python infrastructure with it.