I took "on its own" to mean that it didn't need any additional prompting or guidance from the person sitting at the AI console. If so, then the originality of its work or the resources it used isn't the point. They're reporting that it did whatever it did without requiring supervision.
"Frontier" may be jargon, but by this point it's definitely established AI jargon. In the context of AI, it's clear what it means. It means the same thing as the last billion times you heard someone mention "frontier models".
The current situation with AI is that everyone is going as fast as possible. So, we can logically eliminate speeding up because it's impossible by definition. And we can practically eliminate staying the same speed because why make a big fanfare and coin a special term to announce that you're keeping the status quo. By process of elimination, it must mean slowing down.
The word can also mean to “keep up with” or “lead” so a downward direction isn’t the only way to go even in an “as fast as possible” scenario. If the frontier is outpacing them, they could be saying they’re going to go faster. They could also be sharing the intention to go faster in order to lead.
You take a picture of your wife with your phone. You show it to a coworker. They tell you that your wife looks like a reptile wearing a rubber face mask.
Your reaction is?
a. “Yeah, the slight over processing definitely turned my wife into a lizard person.”
It helps that it's not very big. In the working demo, the image is 132x26, and the actual JPEG file size is about 2-4 kB (depending on the text).
So even on a 56k modem, it might take less than 1 second to load each image.
You could also optimize it so it skips intermediate images if the user types fast. Suppose the user mashes "12345" in a fraction of a second. You start loading "1.jpg" on the first keypress. When you've finished loading "1.jpg", the field contains "12345", so skip straight to loading "12345.jpg".
The demo page's JS doesn't seem to include any optimization code like that. It just updates the img src whenever the text changes. Yet my browser seems to do it automatically! If I mash several keys, the console network log shows only some intermediate images get loaded.
I guess the browser is smart enough to know that, by the time it would have started the download, the resource no longer exists in the page. I'm not sure if browsers ~20 years ago did this, but it would have been worthwhile given how slow networks were.
Practically speaking, I might just allocate an array of 100 pointers. That's only 400 bytes. Then as you encounter each filename, allocate just enough memory for the actual length of the string (plus null terminator) and store the pointer in the array.
> it’s more efficient because it reduces the amount of calls into the file system
OK, but isn't the kernel keeping the directory listing in the disk cache? Won't that prevent extra physical I/O if you do just read the directory twice?
If so, then in the second pass, it's all cache hits, and you're just paying the cost of calling into the file system. Hopefully that's pretty fast. But even if not, it's still absolutely dwarfed by the physical I/O required for the first pass. Windows XP era storage was spinning hard drives, not flash.
And if not, then I'm probably going to put my user icon coding task on the back burner and go ask the kernel team why a seemingly very common usage pattern isn't optimized.
(I realize he's not claiming the performance benefit was significant. I'm just trying to see it in the right perspective.)
It took me a while to figure out I had to click "Explore" to get to the specs, so I'm saving you the trouble.
As long as I'm griping about the web site... Apple, when you introduce a phone with a new and different form factor, please just tell me the dimensions straightaway. This one is shorter and wider than most phones. Is it too wide to fit in my pocket? I need the dimensions to answer that question.
It's a bit disappointing that it's 50g heavier than the Z Fold 8, and similar to the Pixel 9 Pro fold in weight and thickness, at 254 g / 5.2 mm / 11.3 mm.
reply