claytonwramsey

It looks like the original publication of the timeline was on Avid (the video editing software)'s Facebook page on March 1 [1]. I haven't seen any publications older than that (yet).

The timeline was later published to their YouTube channel 4 days ago [2].

[1]: https://www.facebook.com/Avid/videos/-the-full-editing-timel... [2]: https://www.youtube.com/watch?v=upTs-HTThMM

This tracks roughly with my experience learning Esperanto. It's a very cool language with many interesting quirks, but there just aren't a lot of people who speak it, and nearly all of them speak English anyway. I don't regret learning it, but I would probably have been better served by learning another language.

By robot standards, $25k is not a bad. Most mobile-manipulator robots cost 5 digits or more, mostly due to the small market, high materials and engineering cost, and general headaches of robot building.

In terms of the theoretical guarantees, a PD controller is (nearly) always stable and pretty easy to critically damp. However, if the set point is moving with a nonzero velocity or there is some load, then the PD controller will not converge. A PI and a PID controller can converge even if the target is moving.

Practically speaking, I would recommend encoding as much model information as possible before pulling out the I term: for instance, if you know the velocity of your tracked object and assume an intertidal model, you can just include some of that data in your feed forward rather than the controller, which simplifies things greatly.

I started blogging this year, and so far, it's been a lot of fun! Most of what I write is a mix of personal projects and opinions. I recommend keeping a target audience in mind, ideally someone you actually know - in my case, I write for my friends from undergrad. I can't guarantee that you'll get job offers from your blog, but I've certainly received some nice emails. I got an offer because of a project I did before I started a blog, though.

I've gotten a little negative feedback, but that's by far in the minority. Most people on the internet are very nice and I've gotten lots of friendly emails from people I've never met. Definitely give it a try - I would suggest doing a github.io page to get started, but you can of course go the self-hosted route if you're into that sort of thing.

Yes, this is doable. Sharing an account across multiple devices is kosher to my knowledge.

Steam also has family library sharing, which allows games to be shared across accounts (with some restrictions).

It's an empirical result, derived from some testing by the US government in the 1950s [1].

[1]: https://en.wikipedia.org/wiki/Fourth_power_law

If you’re willing to implement your own mutex, it actually is possible to enforce! You could make disabling interrupts emit a token and then require the mutex to accept that token as a parameter to its locking behavior.

In my case, at the very least, I had a fair amount of support.

First of all, I explicitly signed up to teach. At my university, fewer than ten undergraduates per semester teach a class, and typically it's for students who want to hang out and teach something they like. In order to teach, they have to take an introductory class on pedagogy first, which mostly covers assignment and syllabus design.

The student-taught-course program at my university exists far more for the (undergraduate) instructors' benefit than to teach students; its job is to give students a chance to experiment with teaching early on.

Thanks for the kind words!

Yes, I'm fully aware of the fact that teaching isn't really a priority in academia - for that reason, I probably won't be reviving my class in the near future. I really do like teaching, but it doesn't get me much closer to any of my current goals.

These issues are currently handled by my library. It’s not mentioned in the blog post because it would be a little distracting. Dereferencing a “dead” GC during Drop currently yields a panic, while all GCs must be ‘static.

In Rust, macros work at the tokenization level. Making a macro do that would require the macro to fully parse and analyze the syntax tree - possible, but not very efficient. Additionally, there's no guardrail to enforce that the user doesn't move a `Gc` anyway.

I know of a lot of people trying to do "arena" GC in Rust using integer indices. I think that's an excellent approach, but it does mean you have to pass in the arena as a resource to every single function which produces an allocation. This isn't even necessarily a bad thing - the net result is a lot like Zig's allocator API.

I know there's a nontrivial overhead to using index-based references, especially since CPUs can't easily predict load operations. This gives me an idea: create a CPU architecture where pointers are actually (object, offset) tuples, enabling better on-metal performance with index-based references. I've neither the time, money, expertise, nor energy to implement such a thing, but it would be really cool if it existed - maybe CHERI is a close approximation, though I haven't looked very closely at it.

That's an interesting idea. Can you clarify some more on what the baseline memory model should be, if not a graph?

The big reason why this library exists is so that downstream consumers can be entirely memory safe in their allocations - it's the same way that the Rust standard library works. Library writers can use unsafe code to provide safe abstractions and APIs, so you end up with an unsafe core with a safe framework on top of it. I'm just continuing that tradition.

I actually haven't read that paper! Thanks for sharing it. What I'm doing is slightly different - it looks like they're building a conservative GC with an unsafe API, much like one might for C. My intent was closer toward building a GC which can be used with any safe Rust code more or less unconditionally.

That's really cool! Thanks for the kind words. I remember peeking at it while hunting for collectors to benchmark against.

This is correct, thank you. I'll fix it shortly.

Here's the actual paper that was summarized in the OP:

https://arxiv.org/pdf/2307.01850.pdf

The paper is quite approachable and worth a quick scan. In essence, reusing output from previous generations results in rather wonky results which are clearly separable from the original training data.

It's explained in the video. Rat neurons are more than enough for this application and are much cheaper to come by.

Never mind, it seemed to be a temporary outage. Here's an archive of the original post this paste claims to source from:

https://web.archive.org/web/20230710192244/https://semianaly...

The authors of that post also don't seem to have any links to OpenAI, or any real credibility on the topic other than "trust me bro."

I checked both of the linked sources and they no longer exist. In fact, the site linked at the bottom of the paste wasn't even reachable for me.

Yam Peleg's LinkedIn post appears to have been deleted, and even if it still existed, he's not exactly an insider to OpenAI. Without any real verification of these claims, it's hard to believe.

There is significant evidence that Neanderthals lived in communities which supported each other, even when they were wounded. Most notably, Shanidar 1 [1] was found with hearing loss, a severed (yet healed!) arm, and broken legs, indicating that someone else must have cared for him for some time.

[1]: https://en.wikipedia.org/wiki/Shanidar_Cave#Shanidar_1

The fastest way to learn how to make machinable parts is to machine them yourself :). DFM is often a hard-earned skill.

Unfortunately maker-spaces (the only kinds of places where you could get cheap access to good 3+ axis CNC mills) seem to have gone out of fashion. CNC mills in general cost about 5 digits just for the machine, and usually that again for the tooling.

I think the closest one can get to learning some DFM without working on a machine would be watching machinists on YouTube. Back in the day NYC CNC was great, but I think they post more hype content these days.

I'm far from an expert on the topic, but I spent a decent amount of time designing for and then fabricating stuff on CNC machines over the last couple years. To my knowledge, operations are cheap while setups are expensive: if you can design a part around a fixed orientation in a machine, it saves a lot of operator time.

It is! I tried using `static` as a test, and benchmarked the engines against each other.

The final result was that a `const` lookup table yielded +19 Elo over dynamic magic generation, while a `static` one yielded only +10 in a tournament between all three. Elo is non-linear and dependent on the set of competitors, so that's why it has no relation to the +6.6 from the end of my post.

My suspicion is that moving to `static` removes the ability to optimize against the magic table when the query is known at compile time, since I often use magic lookups from fixed squares and occupancies in places other than move generation.

I also found that it yielded no change in compile time or binary size, so it was basically all disadvantages to use `static`.

I'm the original author. Thank you!!!!

I thought about that. The big benefit of using `const` here is that I can lean on my existing abstractions (e.g. Bitboard, Square, Direction) which I was already using in the engine. In order to use those abstractions in `build.rs`, I would have to split out those base data structures into a separate crate. I found empirically that splitting out code into a separate crate resulted in an observable Elo reduction (though this was about a year ago, so I forget how much), even with `lto=true`.

Hi, I'm the original author! This is my first post. I might talk more about chess engines in my blog in the future...

Some background: I taught a class on chess engines this spring (at some point, I'll write up a postmortem on it, maybe). This post was originally derived from my lecture notes for the class, and was (if I remember correctly) the 5th lecture, so I could make more assumptions about the students being steeped in chess-engine lingo.

Josh Triplett is entirely correct here on the masking technique. There are two steps to sliding-piece move generation: first, creating the set of squares a piece can "see," and then the set that it can attack. Magic bitboards are used for generating the set of squares a piece can see.

In terms of where magic bitboards come from: there's not that much in terms of logical derivation. You just have to kind of squint and say, "yeah, I believe that'll work." Magic numbers are found by brute force trial-and-error.

Collisions are caused when the magic multiply doesn't actually yield a perfect bit extraction. Imagine if O * M >> 59 was instead some gross expression of all five bits. The magic number for B1 here is actually an exception - things are not usually so easy. However, if two different positions have the same attack set, and they get sent to the same index by a magic multiply, it doesn't matter that they collided because they map to the same value.