This reminded me of Elixir’s GenStage at first glance. Now I wonder how the underlying libs OTP and core.async relate conceptually and implementation wise.
I guess the issue is having to store the intermediate state somewhere. It’s true for the PID example that numerical integration is easier to compute - if you look at the comment with the closed form solution, you need trigonometric and exponential functions to evaluate it. It’s kind of fascinating that the iterative method approximates the same thing with just addition and multiplication.
> If a company decides to lay off, for instance, 40 employees, German law doesn’t prevent this.
At least this part is partially wrong. There is an entire law about how lay offs are only allowed if they are “socially justified” with definitions of acceptable circumstances. An employer can not fire you “at will” in Germany.
No, they could literally not send on the frequencies they listen on in case of FDD. Enabling this would require extra radio hardware. Also there would need to be a some kind of encryption key exchange between devices which is not needed in the centralized setup. They could not easily route to one another without adding extra stuff.
They are not entirely orthogonal. You need a central base station with scheduling, high dynamic range and power control to maximize performance in an OFDM system. In addition, most cells used to use frequency division multiplexing meaning that the base station and phones send and receive on different frequencies. So lack of point to point capabilities can at least in part be explained by the design goal of optimizing for throughput and user density.
You can cast video e.g. from the QuickTime app or a <video> tag in the browser too which won’t just mirror your screen. In fact the cast video won’t even show on your device’s screen but only on the receiver in that case.
“That means the conventional predictions are largely inference—and worse, they result in unquantified uncertainty.”
Wild claim given the fact that Gaussian process regression / Kriging was invented in the 1960s in geoscience to do exactly what the article claims only their models do: “quantify uncertainty, which in turn guides our data collection, as the most uncertain rocks often represent the most valuable ones to sample”
That’s one way to frame it. The other would be the candidate being able to understand that the “apart from money” part is implied in the question and the answer given the social context. This makes the money answer go from straightforward and honest to blunt and cringeworthy.
Maybe “an automated thing that moves to do stuff”. Generally there are manipulators and mobile robots like vacuums. An interesting edge case would be a CNC machine which has degrees of freedom similar to a pick and place robot but is seen as a whole static thing with moving parts. Also if the mobile platform transports people it’s usually not called robot.
The German federal government alone will pay 1.28 billion Euros to Microsoft until 2025 [1] so I’m pretty sure they do care about their government contracts.
I don’t think commonly used LLM architectures have internal state that carries over between inference steps, so shouldn’t that be none? Unless you mean the previously generated tokens up to the context limit which is well defined.
You could also use a single receiver with a small antenna array (GPS wavelength is around 20 cm) to estimate the angle of arrival of the incoming signals.
I’m listening to some podcasts published through Acast and 95% of the time, my injected ads are about how I don’t have to listen to said ads if I buy Amazon prime.
I appreciate the build step in setups like Vite/Vue because the development server can automatically and accurately hotpatch the application when I make changes. I don’t think you’d want to change the standards to couple DOM and js in the way that makes this possible in Vue but it’s an iteration speed improvement nonetheless.
I had similar issues with the Dask scheduler a few months ago. The docs say it encourages depth first behavior in the computation graph but in my case it kept running out of memory on a large ETL task by first trying to load all the input files into memory before moving on to the next stage.
I’m not familiar with the Python lib but it could be waiting for streams to acknowledge each message reception/persistence before sending the next one. Some clients allow transactions to run in parallel e.g. with futures.