ziedaniel1

A little bit too concise IMO. E.g. it doesn't really explain where the normal equations come from and it mentions eigenspaces without ever defining them.

What are some others?

I did make sure to check before posting.

Good point about the signed integer overflow, though!

I used GCC and checked that it wasn't optimized out (which actually surprised me!)

Very cool idea - but unless I'm missing something, this seems very slow.

I just wrote a simple loop in C++ to sum up 0 to 2^30. With a single thread without any optimizations it runs in 1.7s on my laptop -- matching Bend's performance on an RTX 4090! With -O3 it vectorizes the loop to run in less than 80ms.

    #include <iostream>

    int main() {
      int sum = 0;
      for (int i = 0; i < 1024*1024*1024; i++) {
        sum += i; 
      }
      std::cout << sum << "\n";
      return 0;
    }

A couple details worth noting:

- `repr` often outputs valid source code that evaluates to the object, including in the post's example: running `datetime.datetime(2023, 7, 20, 15, 30, 0, 123456)` would give you a `datetime.datetime` object equivalent to `today`.

- Using `_` for throwaway variables is merely a convention and not built into the language in any way (unlike in Haskell, say).

Do you have a source for that? I thought it was closer to 5pJ/byte.

I enjoyed the easter eggs!

(Yeah, I was not a TA then -- I took it under Paxos in Spring 2014 but only TA'd it after the switch to Raft)

As someone who TA'd 6.824 (Distributed Systems) twice, I 100% agree. It's easier to halfway understand Raft than to halfway understand Paxos, but implementing a consensus algorithm correctly requires understanding it fully. Once you start talking about e.g. the "election restriction", Raft becomes a bit hairy.

(Hi Jeremy!)

This sounds like you're describing energy-based models, not diffusion models.

I think you misread slightly.

All of these algorithms take constant time, i.e., time independent of the input coefficients for any particular (n, c).

This means that once you have chosen a particular n and c, the time no longer varies. However, if n and c vary, the running time is definitely allowed to vary also (as the formulas n(c + n) and (c + n)(log cn)^2+o(1) clearly do).

Oh, good point, I didn't read what you wrote carefully enough.

Actually, the illegal memory access would be undefined behavior, so it's fine for the compiler to assume that it's living in a world where the segfault never happens. Thus, it can optimize away the extra reads. If this weren't allowed, it would be very hard for compilers to eliminate any unnecessary reads.

This sort of optimization reasoning can result in quite surprising behavior: http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

The center core is new, but the side boosters are both recycled. See https://en.m.wikipedia.org/wiki/List_of_Falcon_9_and_Falcon_...

I enjoy MealSquares: http://mealsquares.com . A bit expensive, but fulfills many of the same objectives.

The very same airport, in fact.

They accidentally turned off auto-throttle and took far too long to react to the falling airspeed.

I think you mixed up m/s and km/s. The speed of light is 300,000,000 m/s, so 30,000 m/s is only .0001c. At 1g, it actually takes a month to reach .1c. (Still, your point stands.)

Wow, can I read more about the circum-planetary superconductor idea somewhere? I thought this sort of thing wouldn't work because superconductors lose superconductivity once currents get too high, as you mention.

To get the key ideas behind many of these topics, you could try reading Evan Chen's Infinitely Large Napkin: http://www.mit.edu/~evanchen/napkin.html

I believe you use timing differences, not parallax (it takes ~40 ms for gravitational waves to travel through Earth).

Wasn't TSX only enabled on Xeons to begin with?

That's assuming that they're independent, though, which is certainly false. I'm curious by how much.

Great - sorry for the harsh words, I guess I've just come to expect people to screw up distributed systems :)

"Due to the nature of Raft, there is a very small window (milliseconds) where a node has been disposed as leader, but has not yet changed its internal state. Therefore, even with the leader check in place, there is a very small window of time where out-of-date results could be returned."

No, that's absolutely not inherent to the nature of Raft. It sounds like they're making the same mistake that etcd did, simply relying on whether a node believes it's still the leader rather than having it confirm that fact by committing a log entry: https://aphyr.com/posts/316-jepsen-etcd-and-consul

What's the biggest bottleneck for better forecasting: better observations, better models, or better supercomputers?

This is really cool! However, I was somewhat disappointed that it only models a linearizable memory (each low-level operation atomically acts on the same global state). It would be great to teach people that they can't actually think about memory this way, since various reorderings are possible. The UI design gets a lot trickier, but this could become a great way to teach people how to deal with things like atomic instructions, memory fences, and the differences between the x86 and ARM memory models.

The inability to edit or append to files is not really a fundamental limitation of this approach - it would just require some more bookkeeping. Reading back data, of course, is (by design) impossible.

It's understandable that many people see the disconnect between fears about strong AI and the much more limited capabilities of AI today, and think that the fears must be overblown. However, this article takes that gut reaction and uses it to justify labeling the views of many prominent philosophers and AI researchers as simply a "myth", without even beginning to address their arguments. I strongly recommend reading Superintelligence, by Nick Bostrom.

You misunderstood -- she was mortified that the reporter's story focused only on that.