Firadeoclus

While you can use uniform registers to implement the uniform keyword from shading languages, the two are not the same. Uniform registers are not constants, and they are only uniform/shared across one warp. Nvidia architectures before Turing did not have uniform registers.

What makes a judge a "real" judge is that a sufficient number of people capable of enforcing judgments share the view that the judge is a real judge.

Visual programming languages are not prevented from using textual symbols, though. And many people use diagrams to communicate ideas more efficiently than they could with text alone.

> Any language can be expressed in S-expressions.

I'm not sure this is true for the C preprocessor, though, where macros can represent partial structure.

This is a really interesting system, and I'm excited to give this a try!

Without knowing whether the following cases would actually be useful/relevant, I'm curious if these things apply to Unison:

- Is there a way to "pin" a symbol to a specific hash/version so it won't automatically update when the referred function gets a change? I.e. I could write: A = B@ ++ "world" and when I store and retrieve it, it becomes (example syntax): A = B@a3yx ++ "world"

- Is there a way to refer to a function/symbol by name rather than by hash? I.e. a call site which uses B by looking up which hash is currently associated with the name "B", such that if I do two simultaneous renames, B->D and C->B, the code would now refer to the function previously known as C?

- Are there ways in which the way function updates "bubble up" through the codebase (I assume updating a function means updating every function that calls it, recursively) could become a problem? It would seem that changing one little function could have a knock-on effect that requires re-hashing most of the codebase.

> It's not a matter of identity, but explanatory power. To reiterate, the self-acknowledgement/'diagnosis' as autistic (not ASD) is 'useful from a self-compassion and tolerance standpoint'. So instead of, why do I find X difficult when everyone else finds it easy (or even laughs/condescends/points it out), I can say, I'm autistic, that's not easy for me.

It bothers me a bit that, if you turn it around, the lack of an explanation would be an impediment to self-compassion and tolerance. "I find X difficult" ought to be enough, whether that coincides with any other traits (autistic or otherwise) or not.

Which could be a coordination problem, though. Where initial high costs are due to a lack of scale whereas if everyone participated, costs would come down fast.

Putting fans on radiators should also increase the amount of heat that can be transferred, right?

>The whole point of interfaces is that you're not supposed to care how a method is implemented, only what it does which is explained by a combination of context, naming and documentation.

There are, however, cases where code is a better explanation of "what it does" than naming and documentation. Both naming and documentation are hard and can become out-of-sync. Code is less ambiguous than natural language.

One way to get deterministic output is to use integer/fixed point math. Quantised models already do that for matrix multiplication, but things like softmax may still be implemented using some floating point math. It's possible to replace that, just takes a bit of extra work and is probably slower than using the GPU's native float ops.

This. Being able to expand macros lets you learn what it does in context, and once you're more familiar with the abstraction it gives you the benefit of hiding the details and highlighting the moving parts within an otherwise static structure.

This makes sense but to be honest, how I'd really like to represent data to go along with code is as a table or a tree (i.e. presentation/interaction more like a spreadsheet).

> "More people with cards tend to be white and therefore the cards are racist" is such a weak take - there are more white people than minorities, for one.

But this is quite different from what the article actually says. What they're saying is P(Card|White) > P(Card|Minority), not P(White|Card) > P(Minority|Card).

>> White drivers in the borough, the complaint said, “are significantly more likely to have courtesy cards than minority drivers”. As a result of a ticketing quota system, this means “police officers are forced to disproportionately ticket minority drivers”.

Certainly, getting those elements in larger quantities will be important, but by the time we have the cargo capacity to build colonies on the moon it seems likely that someone would be very happy to trade, say, 100t of Earth-sourced C/N/H for 100t of Moon-mined Au, shipping included.

You could call the way the curriculum is organised "spaced repetition", but this isn't personalised and thus missing the feedback part of spaced repetition. Generally, children aren't taught the method of spaced repetition itself. "Learning how to learn" should be its own subject early on.