I think they mean it like this: imagine you ask me a random number sequence. I give you a random number sequence. Little did you know, I used a very specific PRNG to generate it, so later I can prove with certainty that your number was generated by me, and you can't say you came up with it yourself.
There is no room for false positive here in the same way you can't randomly find a collision in a hash function if it's strong enough. Like the rate is so infinitesimal that it is effectively zero.
Now replace random number sequence with prompted string of words. And instead of using the PRNG on every word I use it every n words. If the generated text is sufficiently long I can tell by matching the expected deterministic pattern.
You can defeat it by changing the words yourself and triggering a false negative but there isn't really any room for a false positive if the text is long enough and the pattern matches perfectly. If the pattern doesn't match then I can compute a probability.
LLMs can be very good at 2. Finding the best architecture, data structures, algorithms, looking on arXiv to see other ways to solve the problem, etc.
You have to work in design mode and stop it from pissing code. Describe the requirements as detailed as possible and refine them based on the responses. It's quite rewarding and helps structure the way you think about the problem.
What do you mean you don't remember, your repo is from 8 months ago, this release is from 18 hours ago. And how does "Gemini couldn't get it to work" translate to "it's broken"? It sounds like your vibe-coding session didn't work first try and you haven't tried to understand what the problem was.
You could also look at other repos in github to see what they do to do the same task.
It's used by most users, that's what they are saying, it doesn't matter that the file format is obscure.
If you make a video player based on ffmpeg you take input videos. The attacker can share a specially crafted video with the victim. Same kind of attack as sharing word documents.
when it comes to security popularity doesn't matter all that much. If something is not used and insecure then the decision should be to drop the feature, not to ignore the security issue.
If Big Deployment is using a stock ffmpeg build rather than one that actually enables only the things they actually use, I feel like that's on Big Deployment.
But the point of ffmpeg is that it can consume pretty much any format. If you let end users upload videos, that is exactly what you need, it’s not desirable to have a very restrictive list of formats you will accept.
Not having massive exposed and untested surface area is very much desireable. Every platform has a highly restrictive list of formats and containers for this exact reason.
Just a point about precision, Google Maps fire overlay is based on NASA Firms + some processing, and it's not perfectly accurate.
It is currently marking my little town as under fire / burned down, but it's not and hasn't been so far. (north west front of the fire, next to the lake). It looks like their contouring algorithm is very greedy and any hot spot marked in the past few days has become part of their fire perimeter.
The massive fire clouds probably contribute to the difficulty of measuring ground temperature from satellite.
How interesting I was just reading yesterday his paper "An enduring error" about how we have been miscounting the Archimedean solids for two thousand years.
But also, for this conjecture to be wrong is quite surprising to me. Intuitively I would think any convex polygon to be topologically equivalent to a circle, and any convex n-gon should be deformable into its regular version, then back to the other one…
He was an incredibly great man, and it remains a privilege to have learned from him. While I left mathematics for engineering, his audacious asking of the right questions around the philosophical foundations of an endeavor remains a large influence on me and has become a hallmark of my engineering work. It makes me smile that you are familiar with him as well. :)
---
Here's the full puzzle, as best I remember it:
Suppose you have two convex polygons with the following very specific relationship: one has been created from the other by making one side stretchy, moving an adjacent side on a hinge, and keeping the remaining sides fixed. For example, imagine a square with a top side made of rubber, and a rigid right side hinged at the lower right corner. You can make a series of convex polygons in a continuous fashion by rotating that right side on its hinge.
The question is, if you have two convex polygons that differ only by this one stretchy side and this adjacent hinged side, can you guarantee that you can always smoothly deform the one into the other by this hinging method while keeping the whole thing convex?
That is to say, if you are deforming one polygon into another by this hinge and rubber band method, if your starting polygon and ending polygon are both convex, are all the middle ploygons guaranteed to be?
The answer is intuitively obviously yes, but in point of fact, it is no.
---
To bring this back to the original story, the question was a small step in a larger constructive proof he was working on. The overall result was already known - in fact, we had just discussed it in class - but the proof had this distressingly jerky, discrete movement to it, and he was hoping to construct a more pleasing and smooth algorithm as a more satisfying proof.
As for me, I would not have known how to begin to prove even the smaller question... but I sure could doodle a counterexample. ;) I therefore looked for a one with all the gusto of a young grad student hoping against all odds to do something helpful. You may look with all the confidence of knowing there is something to find, which is also a tremendous help.
I only know his side of the story because he started Monday's class with this line: "I spent the entire weekend trying to prove the result, without success, and it was a good thing too, as there was a counterexample in my box this morning." He did seem genuinely frustrated, but I also wouldn't have put it past him to have exaggerated that part for the laugh.
Anyway. Asking an AI to find counterexamples under such circumstances seems to me similarly reasonable to asking grad students. In my engineering work, I find there is a balance between using the AI to improve and augment your work (especially to call on the diverse perspectives in its training set), and using the AI to avoid your work. I do think the best experience and results are found in that balance. I would expect the same to be true in mathematics.
I thought an industry standard was to use proxy files. Open source editor Shotcut use them for example. Create a low resolution + intra-frame only version of the file for very fast scrubbing, make your edits on that, and when done the edit list is applied to the full resolution rushes to produce the output.
Often but not always. Sometimes you’re just working with proxies directly, audio mixing and the like. VFX workflows, finishing will be online full res often.
But even so everybody is often making their own proxies all the time. There’s a lot of passing around of ProRes Proxy or another intermediate quality format and you still make even lighter proxies locally so NLEs and workstation apps will still benefit from this
Proxy files have issues when doing coloring, greenscreens, effects shots. The bit depth, chroma resolution, primaries/transfer/colorspace gets changed. Basically only really usable when editing.
With this, you don't need proxy files at all.
