I can play Bach to some extent with practice. I'd qualify that though by saying a multi-part fugue from say The Musical Offering would be a tall order.
I've never had any pretense at being good enough to entertain people with those works as everyone knows them so well (from professional recordings). Even Mozart's a problem here. For example the Romance in the D Minor Concerto, K.466 looks deceptively simple (at least in parts) but it's anything but after hearing someone like Brendel play it. Everyone knows it so well it's not worth the embarrassment of even trying (except perhaps in secret).
(Mozart has a habit of looking simple until one tries to play it, Bach is none of that—one knows what one's in for at pretty much first glance.)
Also wow, for Solar the property taxes are OpEx. So if there's more sunlight because of good weather these "Operating expenses" decrease because they're based on taking fixed costs like property taxes and just dividing them by power output that's unrelated.
I assume property taxes for a gas turbine are likewise OpEx but they just disappear in the noise of buying enormous amounts of methane as fuel.
You just write "spent two years raising my youngest kid [building tree houses and whatnot]". If you keep a bit up with tech, why would anyone think twice about that? They wouldn't where I live.
Some years ago we ported some code from querying out the data and tallying in Python (how many are in each bucket) to using SQL to do that. It didn't speed up the execution. I was surprised by that, but I guess the Postgres interpreter is roughly the same speed as Python, which when you think about it perhaps isn't that surprising.
But Python is truly general purpose while the core query stuff in SQL is really specialized (we were not using stored procedures). So if Pypy can get 5x speedup, it seems to me that it should be possible to get the same kind of speed up in Postgres. I guess it needs funding and someone as smart as the Pypy people.
That's curious. I regularly get speed ups when moving processing from Python to postgres. At least when using indices properly and when the shift reduces the amount of data carried back and forth.
Not sure, but I solved a similar problem many years ago, and ended up concluding it was silly to send all the data to the client when the client didn't have the visual resolution to show it anyway. So I sampled it adaptively client-side by precomputing and storing multiple zoom-levels. That way the client-side chart app would get the points and you could zoom in, but you'd only ever retrieve about 1000-2000 points at the time.
Yeah I agree, I'd like to get an idea of the order-of-magnitude of difference between the two approaches by trying it out but realistically I don't think there's an easy way to get a i16 raw array into the browser runtime with minimal overhead (WebRTC maybe?)
I once had to deal with many million data points for an application. I ended up mip-mapping them client-side.
But regarding sampling, if it's a line chart, you can sample adaptively by checking whether the next point makes a meaningfully visible difference measured in pixels compared to its neighbours. When you tune it correctly, you can drop most points without the difference being noticeable.
I didn't find any else doing that at the time, and some people seemed to have trouble accepting it as a viable solution, but if you think about it, it doesn't actually make sense to plot say 1 million points in a line chart 1000 pixels wide. On average that would make 1000 points per pixel.
We routinely face this in the audio world when drawing waveforms. You typically have on the order of 10-100k samples per second, durations of 10s-1000s of seconds, and pixel widths of on the order of 1-10k pixels.
Bresenham's is one algorithm historically used to downsample the data, but a lot of contemporary audio software doesn't use that. In Ardour (a cross-platform, libre, open source DAW), we actually compute and store min/max-per-N-samples and use that for plotting (and as the basis for further downsampling.
> In Ardour (a cross-platform, libre, open source DAW), we actually compute and store min/max-per-N-samples and use that for plotting (and as the basis for further downsampling.
I discovered flot during my academic research career circa 2008 and it saved my ass more times than I can count. I just wanted to say thank you for that. I wouldn't be where I am today without your help :)
> But regarding sampling, if it's a line chart, you can sample adaptively by checking whether the next point makes a meaningfully visible difference measured in pixels compared to its neighbours.
uPlot basically does this (see sibling comment), so hopefully that's some validation for you :)
The specialization goes both ways, though, I'm much better playing Alberti bass with my left hand compared to the right.