there's scrollback search in the nightly build if that's an option for you (I've been using it a ton for a few months and haven't seen any bugs so far):
Uberfreight is also doing very poorly. From my understanding the Transplace acquisition was somewhat of a merger/UF trying to get out of only the 3PL business and Uber is just trying to get UF's losses off their books. There are not as many synergies as you might think due to the way freight brokerages and their deals with shippers+carriers work. One reason UF didn't acquire Convoy: it only makes sense for a brokerage to acquire another brokerage if they can get more customers (shippers) from that acquisition. But most customers of UF are also customers of Convoy, and are splitting their loads amongst multiple brokers to diversify risk and commoditize brokerages. So if you're a shipper giving 20% of your business to Convoy and 20% to Uber Freight, you won't turn around and give 40% of your business to UF now that they've acquired Convoy, you'll just go find another broker to give your business to.
Yeah it was pretty well documented that Snap's behavior on Android (literally taking a screenshot of the viewfinder) was way worse than on iOS, and features like e.g. video would always come out on iOS before Android
The problem in college is bad, but the problem is some high schools is even worse. At high schools without block scheduling, every day might be a 6 am alarm to get to school by 7:00.
Block scheduling was absolutely amazing, and I'm so glad I had access to it. My school did "modified block" with skinny classes (40 minutes) and blocks (85 minute). The only skinny classes were math, music, and foreign language, all of which seem to have a big benefit from going the full year. The concept of trying to do a chemistry or physics lab in 40 minutes sounded awful.
My high school ran from 8:45-3:10. Morning activities were typically 7-8 or 8:15, so you could still drop by teachers classrooms before school started.
This is the definition of the gambler's fallacy. However, if you look at a chart of the stock market vs. a chart of a coin being flipped many times, they will look very different. While a coin being flipped will either asymptotically trend towards zero or a positive slope of .5 depending upon how it is charted, the stock market will have large peaks and valleys, meaning that after a period of high growth (overvaluation), the market will not continue to value these stocks at a steady growth of 10% per year. Instead, the market will correct the value of these stocks, which looks like a short term undervaluation and so we should expect "more tails than usual".
I recommend you look at the random walk hypothesis, the chart (not the average) of a coin flipped does not trend towards 0 and looks surprisingly similar to stock charts
For anyone else wondering, like I did, why you would use a hexagonal indexing system instead of a (roughly square) latitude longitude system, from https://eng.uber.com/elk/:
"Data size matters in Elasticsearch; a large index means too much data, caching churn, and poor response time. When query volumes are large, ELK nodes become overloaded, causing long garbage collection pauses or even system outages.
To address this, we switched to hexagonal queries, dividing our maps into hexagonal cells. Each hexagonal cell has a string ID determined by the hexagon resolution level. A geodistance query can be roughly translated to a ring of hexagon IDs; although a hexagonal ring is not a circular surface, it is close enough for our use case. Due to this adjustment, our system’s query capacity more than tripled."
Discrete Global Grid Systems (DGGS), which is what this touches on, are a deceptively complex topic. You are optimizing for many performance dimensions, and some things that intuitively seem like they should be optimized for don't really matter, and other things people tend to ignore (like congruency) matter quite a bit.
For example, "equal area" subdivision of the surface is not a particularly useful property. This seems like it is wrong on its face such that most people try to achieve it but you have to remember that equal area only matters if your data is uniformly and predictably distributed. Geospatial data models are neither in a pretty severe way as a rule, which means you'll have to deal with data load asymmetry regardless via some other mechanism. If you can ignore equal area because it is handled by some other mechanism, it opens up other possible surface decompositions that have much stronger properties in other ways.
Compactness of representation and cost of computing relationships on the representation has a large impact on real-world index performance that is frequently ignored. The poorness of lat/lon grids in this regard is often significantly underestimated. A singularity-free 3D DGGS can have an indexing structure that is an order of magnitude smaller than a basic 2D lat/long grid for addressing, and the storage on disk of records encoded in these DGGS are also significantly smaller. This all adds up to a lot of performance.
Hexagonal grids tend to work particularly well for visualization. However, they do have their own significant weaknesses e.g. it is typically not a good representation for join operations and they are relatively expensive to search at large scales relative to some other DGGS tessellation systems.
Hi Andrew - You went to school for chemistry and chemical engineering. I'm still experimenting with ideas for binary codes of succinct/implicit geometric representations for similarity graph embeddings of non-spatial property data like text and numbers. I keep bumping into the crystallography literature -- the traditional lattice structures and also quasicrystal / fibonacci chain representations. How much of your chemical engineering background have influenced your designs?
Almost no influence as related to spatial structure; I tend to view spatial structure as an information theoretic manifestation.
On the other hand, chemical engineering had a big influence on how I reason about distributed systems. That discipline is essentially about the design of complex, continuous flow, coordination-free distributed computation systems that are robustly stable in an efficient equilibrium. It maps directly to computer science but has a concept of the problem space that I think is much more refined than what you commonly see in computer science though it is never expressed in computer science terms. But it makes sense, it is chemical engineering’s One Job.
I would like to read more about what this means and how it applies to distributed systems. I have a physics background, but I sense that chemists tend to have a much more intricate (and interesting) conception of "stability".
For those interested in the variety of uses for hexagonal / hierarchical indexing, Dr. Kevin Sahr at Southern Oregon University has produced an open specification and a number of ancillary research around the topic: http://www.discreteglobalgrids.org/information/
See sibling post for links, but the short answer: you can use 12 pentagons, strategically interspersed. Like a (soccer) football.
edit: Oops, that only explains the tiling. For explanations of how the hierarchy descends, Dr. Sahr produced some GIFs that give a little bit of an overview of how the resolutions overlay: http://webpages.sou.edu/~sahrk/dgg/images/topogif/topogif.ht...
Boundaries between all 6 neighbors are equal. With S2, four are on the sides and top are equal and the corner neighbors have only a single point as their boundary.
This means you can better simulate dynamic systems where there is flow between cells.
Of course a squareish grid can also be used to approximate a disc or ring. The approximation is not as pretty, but I don't see how it makes much difference for a query system.
A triangular grid (or if you like, a grid of hexagonal pixels) is more efficient and closer to isotropic than a square grid. Circles pack more closely in a hexagonal arrangement than a square one.
So there are a few reasons to favour hexagons (or triangles) over squares....
Squares don't pack as closely as hexes, meaning that you can get 18% more hexes into a space than squares for a given perimeter-size. Squares also degenerate badly over the surface of the sphere.... you can't keep a consistent size as you change latitude, and they turn into triangles when you reach the poles.
Google S2 (a square-based alternative to Uber's H3) works by projecting the surface of the sphere onto the surface of a cube, then subdividing each face of the cube. So there's still some distortion around the edges and corners of the cube, but nowhere near as bad as a naive longitude/latitude strategy.
https://github.com/ghostty-org/ghostty/releases/tag/tip