AlotOfReading

A different floating point hack makes exp() easier to compute in hardware (and consequently tanh). You cast the input to an int and take the first 2 bits of what would be the mantissa. LUT[Index] and LUT[Index+1] from your 5-entry table are used to either lerp or poly approx. the function, with the remaining mantissa bits to help.

There'd still be a correlation between spending and academic scores regardless of the actual causative mechanism.

I'm not sure how to square that with the very well-studied result that areas with higher income tend to have better schools. Students from lower income brackets also do better than their income peers at schools in less affluent areas. And because local property taxes are a major funding source for schools, those are also the schools I'd expect to spend more because they have more.

Michigan notably does not fund schools through homeowner property taxes. I suspect that's probably the difference here and a reason we shouldn't use it as a representative example.

Yeah, there's an implicit assumption was reasonability.

But a big part of the value in large clouds like GCP is the network's interconnectedness. Plus even if there was some global event that made communications impossible only for the billing service, I'd still expect charges to top out roughly proportional to the number of partitions as they each independently exceed the threshold. GCP only has 120ish zones.

It's the same fundamental problem as view counters, something Google is famously good at solving. Eventually consistent solutions are well-understood, and wouldn't have these kinds of massive cost-overruns.

Emissions regimes are complicated, but US tractors fall into the much less restrictive off-road category. As a result, they're a disproportionately significant contributor to things like NOx. A long time ago the off-road category was >20%, and I'm sure that percentage has only grown as regulations have forced emissions reductions in onroad vehicles.

You need electronics and computers for cost-effective compliance with emissions requirements. Emissions limits have been one of the most positive government policies in my lifetime, saving millions of QALYs.

There's lots of other electronics in most modern vehicles, but the public manufacturer rationales for electronic lockdowns almost always point back to emissions concerns because they're so defensible. How do you separate them?

It goes the other way as well. Usage data isn't equivalent to asking users either. A solid percentage of bad decisions in tech can be traced to someone, somewhere forgetting that distinction and trusting usage data that says it's it's okay to remove <very important feature> because it's infrequently used.

I'm not terribly familiar with graph databases, but perhaps someone who is can explain the advantage of this awfully complicated seeming design. There's gremlin, cypher, yjs, and zod, all of which I understand are different languages for different problems.

What's the advantage of using all these different things in one system? You can do all of this in datalog. You get strong eventual consistency naturally. LLMs know how to write it. It's type safe. JS implementations exist [0].

[0] https://github.com/tonsky/datascript

A LUT is pretty wasteful. You only have a one bit significand, so the mantissa and sign bits are boolean binops, and the exponent is a 2 bit adder.

I don't believe any AV software out there attempts to solve the trolley problem. It's just not relevant and moreover, actually illegal to have that code in some situations.

You can't get into a trolley situation without driving unsafely for the conditions first, so companies focus on preventing that earlier issue.

If you have a couple hundred dollars, you can get a chip made through tiny tapeout [0].

[0] https://tinytapeout.com/

Floating point determinism has been a personal bugbear of mine for a number of years. You still have to be careful, but it's at the point where it's less work than switching to fixed point (cheap as that may be). There are even libraries [0] [1] that implement full reproducibility with negligible overhead. Compilers shipping incorrectly rounded stdlib functions remains an issue, but they're slowly improving. Language level support for float reproducibility is in the C++ pipeline, and already a design consideration on the Rust side. In a decade or so determinism issues might be a distant memory once you've ensured same inputs to the same instructions in the same order.

[0] https://github.com/J-Montgomery/rfloat

[1] https://github.com/sixitbb/sixit-dmath

    i.e. the difference between having a limit for the absolute error or for the relative error.

The masking procedure I mentioned gives uniform absolute error in floats, at the cost of lost precision in the significand. The trade-off between the two is really space and hence precision.

I'm not saying fixed point is never useful, just that it's a very situational technique these days to address specific issues rather than an alternative default. So if you aren't even doing numerical analysis (as most people don't), you should stick with floats.

Fixed point and Floating point are extremely similar, so most of the time you should just go with floats. If you start with a fixed type, reserve some bits for storing an explicit exponent and define a normalization scheme, you've recreated the core of IEEE floats. That also means we can go the other way and emulate (lower precision) fixed point by masking an appropriate number of LSBs in the significand to regain the constant density of fixed. You can treat floating point like fixed point in a log space for most purposes, ignoring some fiddly details about exponent boundaries.

And since they're essentially the same, there just aren't many situations where implementing your own fixed point is worth it. MCUs without FPUs are increasingly uncommon. Financial calculations seem to have converged on Decimal floating point. Floating point determinism is largely solved these days. Fixed point has better precision at a given width, but 53 vs 64 bits isn't much different for most applications. If you happen to regularly encounter situations where you need translation invariants across a huge range at a fixed (high) precision though, fixed point is probably more useful to you.

    Note that he put "races" in quotes.

I know, but we both see how a random member of the public could easily read it. My argument, after all, is that the way he communicates is sloppier than it should be for the subject matter and prone to public misunderstandings.

     This is simply not true.

Yes, because it's not an argument the letter is making. Everyone can name a meaningful genetic patterns of genetic variation that follow ancestry like lactase persistence. The argument is in the second paragraph:

    But his skillfulness with ancient and contemporary DNA should not be confused with a mastery of the cultural, political, and biological meanings of human groups.

It's not an argument that Reich gets the science wrong, so other geneticists being on the list is neither here nor there. When he says things like:

    But as a geneticist I also know that it is simply no longer possible to ignore average genetic differences among “races.”

in NYT opinion pieces, it's that he's not understanding how terminology interacts with public discourse. The next paragraph goes on to use the unclear term "west african", not exactly a great example of careful language either.

The list is mainly people in fields that deal with these things, as you'd expect.

It's unfortunate that the URL happens to be buzzfeed, but there was an open letter to Reich by other academics about his terminology in the book you're quoting [0]. The short of it is that social categorizations we believe in like race intersect with genetics in a very complicated way. Reich is a world-class expert in genetics. He simply commits the same error as many other other experts in discounting the complexity of subjects he's adjacent to, but not directly an expert in.

I get that this is a high standard to hold him to (and I sure as heck don't meet it myself), but he should do better given his visibility in public discourse.

[0] https://www.buzzfeednews.com/article/bfopinion/race-genetics...

The reason no one wants to talk is that these discussions are always co-opted by racists wanting to affirm their beliefs, regardless of the underlying science. Reich in particular is borderline deliberate about attracting those sorts with his lab's research, because of how badly he chooses to handle the topic and terminology of race.

Berlin specifically has a few meters of soil separating it from that period, but that's not always true. I've excavated millennia-old sites barely centimeters under the surface. Others are buried under meters of soil overnight. There's also natural processes moving things around in the soil (e.g. rabbits, freeze-thaw cycles), and human processes (e.g. tilling).

I wouldn't jump immediately to modern collector, nor does the article.

The southwest has plenty of layers on layers. Tucson is built on a Spanish fort, which is built on native villages on top of yet older native villages going back almost 4,000 years, as one example.

For another example, most neighborhoods in eastern phoenix are built on top of old Hohokam villages, adjoining older basketmaker sites. The canals throughout the city often follow the old Hohokam canals. Fun fact, the Intel Chandler campus is on top of old hohokam suburbs of Pueblo de los muertos, which is buried under the modern suburbs.

There's plenty of middle ground between an unchanging SQL schema and the implicit schemas of "schemaless" databases. You can have completely fluid schemas with the full power of relational algebra (e.g. untyped datalog). You shouldn't be using NoSQL just because you want to easily change schemas.

Echoing the efficiency. I just returned from a 1mo trip living out of the 45L, including a supply of dead-tree books.

That said, I've only had it a year and it's clearly not new anymore. Paint wear on the rivets, for example. I expect it'll be in rough shape when it's accumulated as many miles as the travel bag it's partially replacing.

The argument is that a universal basis would be capable of solving arbitrary polynomial roots. The rest is an argument that the group constructed by eml is solveable, and hence not all the standard elementary functions.

It wouldn't be a math discussion without people using at least two wildly different definitions.

That makes much more sense, yeah.

You'd probably be better off not trying to navigate using GPS in China in the first place, given the whole mapping situation there.

I'm trying to understand the argument here. Are you saying that never releasing convicted criminals would completely eliminate crime?

That doesn't seem correct, even leaving aside the obvious moral issues with that.

They're not series, that's just a convenient way to think about defining and calculating them. I've never found it particularly useful to deal with the series definitions either, and none of the (good) approximation methods I'm aware of actually take that approach.

Moreover, EML is complete in a way that your suggested function isn't: If you take a finite combination of basis functions, can it build periodic functions? Hardy proved over a century ago that real (+,-,/,*,exp,ln) can't do this (and answering the paper's unresolved question about similar real-valued functions in the negative). EML being able to build periodic functions is a lot less surprising for obvious reasons, but still pretty neat.

A similar function operating on the real domain for powers and logs of 2 would be extremely hardware friendly. You can build it directly out of the floating point format. First K significand bits index a LUT. Do that for each argument and subtract them.

It gets a bit more difficult for the complex domain because you need rotation.

Anything discussing fast inverse sqrt will go over the logarithmic side [0], as it's the key insight behind that code. Exp is just the other direction. It's not widely documented in text otherwise, to my knowledge.

[0] https://github.com/francisrstokes/githublog/blob/main/2024/5...