NaiveBayesian

> Dyson CameraJet™ runs on 16 million lines of code

Yikes...

Yes, the Android app is particularly bad. For the past couple of weeks, it's gotten to a point where the app will take 30s to load on my phone. Nothing, not even reinstalling the app fixes this.

What really gets me is when an app highjacks a link to the site, and then doesn't know what to do with it, when just opening the link in the browser would have been perfectly functional. Email unsubscribe links are a particularly annoying example of this.

Mixture of Experts is already used by pretty much all modern LLMs to address exactly this phenomenon.

Hopefully, future models can be trained to be even more aware of external knowledge, accessible through web search / RAG / whatever it will be then, and might not need to internalize much knowledge at all.

Ah I stand corrected. Thanks for pointing that out!

For me it showed 400 fps in the top left corner and my laptop fans spun up immediately as well. Seems to render frames continuously rather than waiting for the screen to refresh. Would probably be much less load when limited to 60 fps.

I agree that this feels intuitive, that potential energy should increase linearly with height.

But in the end, it's all up to the units/quantities we choose to measure, no? If we, say, decided to measure "Squenergy" in Sqoules, with 1Sq² = 1J, then suddenly, squenergy does increase linearly with speed! The formula for kinetic Squenergy becomes sqrt(m/2)v.

Of course this complicates other stuff, like potential Squenergy becoming sqrt(MgH), it not being additive, etc.

I love nextcloud and have been using it for years. However recently I've considered taking my instance offline or at least behind a VPN because even if only 10% is true of what AI folks are claiming about LLMs finding exploits left and right, it seems super risky to be hosting your private data on nextcloud.

How do you folks deal with these massively increased threats to self-hosted open source apps?

Agreed, that's what I struggle to see as well. It's not really clear why the variance couldn't stay the same or go to infinity instead. Perhaps it does follow from some property of the underlying Gamma/Wishart distributions.

I believe that counterexample only works in the limit where the sample size goes to infinity. Every finite sample will have μ≠0 almost surely.(Of course μ will still tend to be very close to 0 for large samples, but still slightly off)

So this means the sequence of μₙ will perform a kind of random walk that can stray arbitrarily far from 0 and is almost sure to eventually do so.

There was actually a series of language models named after Sesame Street characters back in 2018-2020, starting with ELMo, then BERT, ERNIE (a different model from 2019), Big Bird, ... There are likely some more that I missed.

ELMo: https://arxiv.org/abs/1802.05365 BERT: https://arxiv.org/abs/1810.04805 ERNIE: https://arxiv.org/abs/1904.09223v1 Big Bird: https://arxiv.org/abs/2007.14062

These calls should be automated in most cases [1]. Still an impressive feat, but there is no way they are paying a large number of people to phone through all businesses in the world.

[1] https://support.google.com/business/answer/7690269?hl=en

If your data loading pipeline grows even slightly complex, then yes, you absolutely need concurrency in order to deliver your samples to the GPU fast enough.

The current workarounds to make this happen in python are quite ugly imho, e.g. Pytorch spawns multiple python processes and then pushes data between the processes through shared memory, which incurs quite some overhead. Tensorflow on the other hand requires you to stick to their Tensor-dsl so that it can run within their graph engine. If native concurrency were a thing, data loading would be much more straightforward to implement without such hacks.