tbabb

Here is some context: Early in the aphantasia discourse, someone asked a group I was in to do a mental exercise: Imagine an apple. Can you tell what color it is? What variety? Can you tell the lighting? Is it against a background? Does it have a texture? Imagine cutting into it. And so on.

For me, not only was the color, variety, lighting, and texture crystal clear, but I noticed that when I mentally "cut into" the apple, I could see where the pigment from the broken skin cells had been smeared by the action of the knife into the fleshy white interior of the apple. This happened "by itself", I didn't have to try to make it happen. It was at a level of crisp detail that would be difficult to see with the naked eye without holding it very close.

That was the first time I had paid attention to the exact level of detail that appears in my mental imagery, and it hadn't occurred to me before that it might be unusual. Based on what other people describe of their experience, it seems pretty clear to me that there is real variation in mental imagery, and people are not just "describing the same thing differently".

They don't mention Twitter, but that's where Willison got it from.

Recruiters use automated tools to scrape LinkedIn profiles and send what amounts to customized spam.

On the one hand, yes.

On the other hand, clock time is entirely a social construct whose whole purpose is to coordinate social and business activity, so it should be specifically designed around social customs in order to serve that purpose.

Aha! That was a bonehead miss on my part. Very nice, and very slick interface. :)

EDIT: Author has pointed out that the interpolation mode can be changed. Very slick!

It looks like this is interpolating in HCL or HSV space— that tends to produce unexpected results, including intermediate colors with unrelated hues (pink between orange and blue?), or sharp discontinuities if one of the endpoints changes slightly (try mixing orange and blue, and then shifting the blue towards teal until suddenly the intermediate pink pops to green).

This document[1] also illustrates pretty well.

Interpolating in RGB space has its own issues (more so if gamma is not handled correctly) due to the human visual system's differing sensitivity to different colors— the result is often that two bright colors will have an intermediate color which is darker than either endpoint.

There's a known solution, thankfully: Mix colors in a perceptual color space like Lab or Oklab[2]. The behavior is very predictable and aesthetically pleasing.

[1] https://observablehq.com/@zanarmstrong/comparing-interpolati... [2] https://bottosson.github.io/posts/oklab/

Pixar used RCS at the time. Problem is, when you run `rm -rf /`, that deletes the RCS directories as well.

Ed Catmull.

I play sports. I may be able to catch a ball with one eye

I would love to see a sports game where one team can use both eyes, and the other team only has one eye uncovered. I imagine it'd be downright funny.

Humans don’t really use stereopsis beyond the reach of their arms

This is outright false. A person with acute vision can perceive stereopsis out to 1/4 mile. Trivially, 3D movies are projected onto screens which are 10m away.

which is why we can also understand pictures

We don't drive using pictures.

The failures will continue indefinitely, until Tesla decides to use stereopsis for ranging.

Requiring multiple sensors means that all of your sensor systems need to notice a danger

This is the opposite of true. In well-designed sensor fusion algorithms, every new piece of sensor data, however noisy, helps to overconstrain the estimate. Each sensor reading helps to inform the interpretation of the other readings. If your system is designed such that more information worsens your inference, you have designed a terrible system.

Why don’t I just connect directly to my friend, not through some third party content server, and pull the desired content directly off my friends hard drive?

That, my friend, is called a "web page", and thanks to the open design of the web, literally nothing stops you from setting one up.

And that's the biggest doublespeak lie about it.

The web is already open and decentralized by its very design, and that openness and decentralization is a major reason for its incredible success.

Web3 people want that stuff not to work. They want you to be unable to right-click save. You can already openly save, modify, and share images. Web3 people want to lock it down and charge you for memes.

It is the biggest, greediest grift in recent memory. If you are working on this, don't be fooled by all the empty words about "decentralization"; you are working on DRM for giant hedge funds who are trying to take over and own the entire web. Its current openness is their enemy.

Victim-blaming comments like this make me see red.

"The fact that I am able to exploit these people means that I am entitled to" is everything wrong with Silicon Valley.

"Innovation" and "scam" are not incompatible.

It's not clear that the impression is false.

Sometimes it's hard for me to tell when a Hacker News comment is being sarcastic or not.

60 miles

To match a human, it needs to go half a million miles without an accident, and 100 million miles without a fatality.

Tesla autopilot use nowhere near competitive with a human driver, no matter what they claim.

I'm bullish on self-driving in general, but Tesla's misrepresentation of their self-driving capability has always been just shy of "fraud".

What was the requirement that was satisfied by the battery swap?

You're completely free to decide you're unbothered by it in your own particular application, but it would be unhelpfully misleading to other readers to say that a 10^6 performance difference is "negligible", or that they should expect the particle filter to give better results.

Particle filter is very cool, and it's great that someone mentioned it because it's quite useful in the right circumstances. But it is not a panacea (nor is the Kalman filter), and we don't need to misrepresent it in order to advocate for it in cases where it's applicable.

but in practice the difference is negligible [...] A particle filter with a million points is trivial

This will be O(millions * state_size) of flops per frame. A Kalman filter of the same state size will have the expense of a matrix invert, which will be O(state_size^3). So for a state size of, say, 12 floats, the Kalman will be about O(2000)-ish flops. A particle filter with "millions of points" modeling the same system will be O(state_size * millions * flops_per_state_update) which could be literally billions of flops, a six order of magnitude difference.

While there are absolutely applications where the particle filter is a more appropriate choice, it's just false to say that the performance difference is negligible. The difference is quite large.

Author here. The particle filter has its own strengths and drawbacks. It makes more sense to use a particle filter in situations where the state search space is highly nonlocal and/or nonlinear, for example locating a drone on a map by matching radar features to topography.

If the process is linear and the estimation error is Gaussian (or approximately so in practice), the Kalman filter is known to be the optimal algorithm, and the particle filter would not only perform worse, but be more expensive to implement.

The article says that there is an audio cue.

The cow will hear a beep long before it gets zapped. It's the same as for invisible fences with pet collars.

I suspect from personal experience that companies underestimate how much business they are truly losing due to spite alone.

If a dollar is defaulted, I'm not sure it's accurate to say that one dollar is destroyed (as opposed to moved), let alone ten? If the borrower defaults, it is the same as the borrower owing the depositor $1 (the bank is in a sense acting like a risk-absorbing and expertise-adding middleman between the depositor and the borrower).

And doesn't whether that dollar is "destroyed" depend on why the borrower can't pay it? If it's because someone else got ≥ $1 richer off the borrower, then it seems to me like the supply of money in the economy as a whole hasn't actually gone down.

Again, maybe dumb question, but what sense is "every dollar leveraged 10x"?

Also in 2008, it looks like money velocity decreased during the recession (as it's been doing almost monotonically since the mid 90s). It looks like after the crash, velocity increased slightly, and indeed the supply contracted just slightly at basically the exact same time.

Maybe a stupid question, but if the velocity goes up, couldn't/wouldn't the Fed contract the supply?

It seems like having large supply is desirable/correct when velocity is low.

The "browser" is a blank execution sandbox with a rendering context. The remote server sends programs (using something like WASM) with a standardized ABI. The program can use the rendering context to put stuff on the screen or receive user input.

Indexing and page interoperability is done by exposing standard functions which yield the necessary metadata. For example, if you want your site to be indexable by a search engine, you expose a function "contentText()" which crawlers will call (and which the client browser might also call and display using the user's own reader app). In the simplest case, the function simply returns a literal.

Core resources like libraries would be uniquely identified, cryptographically signed, versioned, and shared.

If someone wanted to make use of a browser pipeline like the standard one we have today, they might send code which does something like "DOMLibrary.renderHTML(generateDocument())". But someone else could write a competing library for rendering and laying out content, and it might take hold if it's better, and it wouldn't have to be built on top of the first one.

Also, the browser wouldn't necessarily be a separate app (though someone could make one); it would be a standard built-in feature of operating systems, i.e. the sandboxing would be done at the kernel level. With security properly handled, there'd be no difference between a native app and a web app, except whether you load it from your own filesystem or a remote one.