For various reasons, I believe the CFR defines flour as a food, not a food additive, but it may have additives that qualify. (I can't find any text that explicitly states that foods are not food additives, but either way, no form of wheat flour is listed in the Substances Added to Food database.)
Common culprits include chemicals added during the bleaching process and addition of "enzyme" / other ingredients that help improve baking consistency. Some examples:
> The bill itself calls out using USDA databases for various ingredients and various sections of federal regulations, so I can't comment too much about how they'd feel about xanthum gum without diving deep.
For reference: xanthan gum specifically would fall afoul of the rules, as... a (ii) stabilizer or thickener, (iv) coloring or coloring adjunct, and (v) emulsifier.
> I may use a third party std::function that doesn't have the weird copy semantics though
Note that C++23 brings std::move_only_function if you're storing a callback for later use, as well as std::function_ref if you don't need lifetime extension.
> google.com, youtube, chrome, android, gmail, google map etc
Of those, it's 50/50. The acquisitions were YT, Android, Maps. Search was obviously Google's original product, Chrome was an in-house effort to rejuvenate the web after IE had caused years of stagnation, and Gmail famously started as a 20% project.
There are of course criticisms that Google has not really created any major (say, billion-user) in-house products in the past 15 years.
Indeed Chrome included many relatively small acquisitions to be built. For example, GreenBorder for sandboxing and Skia for the 2D graphics engine. At that time sandboxing was novel for a browser.
Actually, we do have some of that data. You can just look at the H-1B employer datahub, filter by Google (or whichever other employer you want to scrutinize), and then look at the crosstab.
Looking at Google specifically, I observe two things:
1. The number of new approvals has gone down drastically since 2019 (2019: 2706, 2020: 1680, 2021: 1445, 2022: 1573, 2023: 1263, 2024: 1065, 2025: 1250). (These numbers were derived by summing up all the rows for a given year, but it's close enough to just look at the biggest number that represents HQ.)
Compared to the overall change in total employees as reported in the earnings calls (which was accelerating up through 2022 but then stagnated around 2025), we don't actually see much anything noteworthy.
2. Most approvals are either renewals ("Continuation Approval"), external hires who are just transferring their existing H-1B visas ("Change of Employer Approval"), and internal transfers ("Amended Approval").
I tried implementing A* using pointwise Hamming distance, found that it was inadmissible (since it yielded a suboptimal result on par with my manual attempt), then tried again with row-wise Hamming distance but was pretty sure that's inadmissible too (although it did yield an optimal result). I then tried min(row-Hamming, column-Hamming) but I'm not convinced that's admissible either.
I then switched to pure Dijkstra which ended up being faster because evaluation was much cheaper at each step, and despite these heuristics being inadmissible, they didn't result in substantially fewer nodes expanded.
That's almost certainly a function of the problem size -- if it were 5x5, this approach would not have been as successful.
You may need to add some factor for the Hamming distance to make it admissible. On a 4x4 board each move change at most 4 bits. So 4 x the hamming distance should be OK.
Edit: I 'm maybe getting this wrong confusing lower bound and upper bound. Sorry I'm a little rusty.
Edit2: For 4x4 one lower bound is hamming distance/4 , because you need at least these many moves to reach the goal. For 5x5 hamming distance / 5 and so on... But not sure how much this will reduce the need to graph.
Hamming distance doesn't strike me as a useful metric here because how "close" two rows are is entirely dependent on what the other rows are. E.g. if you have a row of all 1's then two rows with maximal hamming distance are only one move away and if on average you have a bunch of n/2-weight rows then two rows different by 1 bit are not close. The best you can do is count the number of total rows matching the target I think?
Yeah, that was what I tried with row-Hamming / col-Hamming (namely: treat entire rows / cols as matches or not). I then used the min of the two to address those issues.
Either way, I guess my implementation had a bug -- A* does yield a significant speedup, but adding the 0.25x scaling factor to ensure that the heuristic is admissible loses almost all of those gains.
For some concrete numbers: with the bug that basically reduced to BFS, it ran in about 7s; with the bug fixed but a wildly inadmissible heuristic, it ran in about 0.01s; with the heuristic scaled down by 4x to guarantee its admissibility, it ran in about 5s.
I think scaling it down by 2x would be sufficient: that lower bound would be tight if the problem is one row move and one column move away from the goal state, but potentially all four rows and columns would not match. In that case, it ran in about 1.6s.
I know of some work on trying out various heuristics for A*; Section 5 of https://arxiv.org/pdf/2201.06508 gives some examples of what works and what doesn't. I don't think D* Lite specifically has ever featured. There's plenty of room for trying to come up with other heuristics, and just for other takes in general.
> But for bigger boards you won't be able to materialize the whole graph.
If we restrict to boards corresponding to solvable puzzles, the number of vertices is https://oeis.org/A002884 (1, 1, 6, 168, 20160, 9999360, 20158709760, …) and indeed grows quickly. It's possible to manipulate the 7×7 case (https://arxiv.org/abs/2503.01467, shameless plug) but anything bigger than that seems hard.
One can ask, for example, how many moves are needed for the hardest n×n Swapple. For n = 1, …, 7 the answers are 0, 3, 6, 9, 12, 15, 18 respectively, but we don't know what the answer is for n = 8.
> The GPU implementation's logarithmic scaling becomes evident at longer sequence lengths.
I don't see logarithmic scaling, actually. From the table for GRU performance, going from 16384 -> 65536 (namely: increasing the input by 4x) is roughly a 4x increase in time whether looking at CPU-scan or GPU-scan. Okay, maybe the inputs need to be bigger. Looking at the next plot, which goes up to 524288, we see the same behavior: the delta between CPU-scan and GPU-scan doubles as we double the input. That's a constant multiplicative factor. Same holds for LSTM performance.
Is this an artifact of the benchmark setup? Are we actually measuring the amount of time needed to load the full context into RAM? Or perhaps we're bottlenecked on memory bandwidth?
> Success: The gate extraction kernel, which was a huge bottleneck, now only takes 8% of the total time and is memory-bandwidth bound, saturating L2 bandwidth at 1.9 TB/s. This is a good place to be.
Typically the fastest approaches for associative RNNs combine the advantages of the parallel O(n log n) algorithm with a recurrent non-parallel O(n) approach by computing results for subsequence chunks in parallel and moving to the next chunk in a recurrent manner. This blog post explains the method (chunkwise parallel algorithm) well: https://sustcsonglin.github.io/blog/2024/deltanet-2/
> San Francisco, San Jose, Los Angeles, Austin, and Phoenix are ~10% of US population.
Surely you're describing metro areas? There's no way those five cities add up to 34 million people within city limits, given that none of them have 6 million people.
- SF doesn't cover East Bay (two thirds of the MSA by population).
- Silicon Valley doesn't cover San Jose, and barely reaches into Sunnyvale (basically just covering the Google Moffett Park office buildings).
- The Phoenix area is missing most of the densest parts of Phoenix itself, as well as anything north / west of the city.
- Los Angeles doesn't even come close to covering the city, much less the rest of LA County or any of Orange County. (Maybe 2-3 million out of 13, from just eyeballing the region.)
On Uber (https://support.google.com/waymo/answer/16011725?hl=en) there's also Atlanta (which looks like it actually has very nice coverage, other than the western half of the city) and Austin (again focused on downtown / commercial districts) which help drive up the numbers.
The population that's had opportunity to see Waymo in the wild is probably higher because they're testing in quite a few cities now (a sibling commenter mentions NYC, for instance).
> if an argument fits into the size of a register, it's better to pass by value to avoid the extra indirection.
Whether an argument is passed in a register or not is unfortunately much more nuanced than this: it depends on the ABI calling conventions (which vary depending on OS as well as CPU architecture). There are some examples where the argument will not be passed in a register despite being "small enough", and some examples where the argument may be split across two or more registers.
For instance, in the x86-64 ELF ABI spec [0], the type needs to be <= 16 bytes (despite registers only being 8 bytes), and it must not have any nontrivial copy / move constructors. And, of course, only some registers are used in this way, and if those are used up, your value params will be passed on the stack regardless.
It works out for them because bandwidth gets cheaper over time but inflation eats away at that. $70 today is like $50 back in 2010 when GFiber first launched.
Common culprits include chemicals added during the bleaching process and addition of "enzyme" / other ingredients that help improve baking consistency. Some examples:
https://www.hfpappexternal.fda.gov/scripts/fdcc/index.cfm?se...
https://www.hfpappexternal.fda.gov/scripts/fdcc/index.cfm?se...
https://www.hfpappexternal.fda.gov/scripts/fdcc/index.cfm?se...