I've just finished processing thousands of documents using the Gemini Pro 3 vision model and it outperformed every OCR and image model I've tested by a long shot, perfect markdown with latex for the math every time.

The `echo` part seemed interesting but it made me think, debuggers need this as a built in feature. If I have

    array
      .slice(0, 10)
      .filter(s => s[0].toLowerCase() < 'm') // a<->l
      .map(s => s.toUpperCase());

It seems like it should be a common feature to be able to view between each array operation in a debugger without having to augment the code with `echo`

The out of bounds handling didn't seem all that good to me. Sure you can filter out undefined. You could also just make a function that returns an empty array if out of bounds, or array of 1 element if not.

     // JS
     function getElemFromGrid(grid, x, y) {
       return (x < 0 || x >= grid.width ||
               y < 0 || y >= grid.height)
         ? []
         : [grid.elems[y][x]]
     }
     
     ...
     
     neighbors = [
       ...getElemFromGrid(grid, x + 1, y + 0),
       ...getElemFromGrid(grid, x + 1, y + 1),
       ...getElemFromGrid(grid, x + 0, y + 1),
       ...getElemFromGrid(grid, x - 1, y + 1),
       ...getElemFromGrid(grid, x - 1, y + 0),
       ...getElemFromGrid(grid, x - 1, y - 1),
       ...getElemFromGrid(grid, x + 0, y - 1),
       ...getElemFromGrid(grid, x + 1, y - 1),
     ]

     
        

I also find grids made of 2 dimensional array to be code small. An array of arrays is NOT A GRID as there is nothing enforcing the inner arrays to be the same length as each other. Also, in efficienct code it would be better to provide a 1 dimensional array and bounds. Now, out of bounds checks based on accessing outside the array won't work. You need to check actual bounds. Again giving preference using a helper

Going to compare this to our current solution of Amazon's Textract service for analyzing handwritten datasheets. Textract, when extracting tables (which is what we use it for) does not allow for providing any context or information about the tables and what we expect them to contain, but it is really good at correctly recognizing hand written characters. All of my attempts at less specialized, more general models allow me to provide that context, which is helpful in some ways, but fail at the basic part of almost always correctly getting the character.

Hopefully Google pro marries the two together.

I just realized that other industries are way larger than AI. Assuming they capture the entire advertising market, only $390 Billion was spent in the US last year. Compare that to health care, where 4.3 Trillion was spent in the US last year, or commercial banking's revenue of 1.5 Trillion, commercial real estate's 1.5 Trillion, gasoline stations' 1.10 Trillion, etc. What's amazing is, despite the fact that AI isn't making much money, is taking on considerable debt, and isn't even assured to be all that useful, one third of the stock market is now just AI crap. The economy is going to collapse because of a small, brand-new industry. This... shouldn't be possible.

One thing that needs to be emphasized with “durable execution” engines is they don’t actually get you out of having to handle errors, rollbacks, etc. Even the canonical examples everyone uses - so you’re using a DE engine to restart a sales transaction, but the part of that transaction that failed was “charging the customer” - did it fail before or after the charge went through? You failed while updating the inventory system - did the product get marked out or not? All of these problems are tractable, but once you’ve solved them - once you’ve built sufficient atomicity into your system to handle the actual failure cases - the benefits of taking on the complexity of a DE system are substantially lower than the marketing pitch.

I still want something no one has, which is the ability to launch agents in different git worktrees simultaneously and check the results out on my main branch for testing when they are finished.

To add to the existing answers - L2 losses induce a "blurring" effect when you autoregressively roll out these models. That means you not only lose import spatial features, you also truncate the extrema of the predictions - in other terms, you can't forecast high-impact extreme weather with these models at moderate lead times.