sansseriff

Can anyone clarify what is meant by "Mythology: we are modifying the meaning of each token based on what we've seen before it in the context, with similar meanings reinforcing each other." At this point in the text, it seems like the kernel smoothing is being applied to each embedding vector in isolation. I don't see why any one y_t vector derived and smoothed from token x_i would be influenced by the nearby tokens in the sequence.

When you add the r_t tokens, sure then I see how context matters. But is that the only think that takes into account context?

The laser spot can reach half the size of the continental united states. Though I'm not sure how large it is now because psyche is still relatively close to earth.

What's a good place to learn about all the networking jargon in this article?

Also, a nitpicky point: As a community it would be nice to stop thinking of 'links to wikipedia pages, mdn docs, or github issues' as useful or pertinent forms of citations or footnotes. If I'm immersed in an article and I come across a term I don't know like 'SCTP', do you think a link to some dense proposal standard webpage is appropriate in this context for providing the background info I need?

Of course academia is guilty of this too. Canonical citations don't tell the reader much else beyond 'I know what I'm talking about' and 'if you want to know more spend 30 minutes reading this other article'

But since we're web based here I think we can do better. Tooltips that expand into a helpful paragraph about e.g. SCTP would be a start.

Yes I can run about 200 jellyfish in this demo with similar GPU load, resolution, and frame rate. https://akirodic.com/p/jellyfish/

Maybe not the most helpful comparison haha. Anyways, great work, this is very impressive

This is hitting my gpu super hard (Radeon Pro 560X, near-4k) with just the default ball scene. Frame rates are dipping very low just orbiting around. Does anyone know if there could be a WebGL optimization issue?

We can expect a quantum computer with 20 million noisy qubits to break RSA 2048 [1]

I can't speak to coherence time or circuit depth concerns, but qubit counts are doubling roughly every year. Current chips have thousands of qubits, so the exponential scaling implies we'd have 20 million qubits by 2035-2040.

edit: And from the paper, the required quantum volume ("megaqubitdays") scales bewteen O(n^3) and O(n^4) with RSA key length. So a few years after breaking RSA 2048, you'd have a computer five times larger that could break RSA 3072.

[1] https://quantum-journal.org/papers/q-2021-04-15-433/

Optical to Orion (O2O) is a plan to do a lasercomm demo on one of the future Orion moon missions.

When the Psyche spacecraft launches and heads to the asteroid belt (was supposed to launch in august) it will do the farthest (by far) lasercomm demo. I work in the group that made the SNSPD ground receiver. As my boss says, with a distance 1000x farther than previous space laser comm demos, closing the link is 1 million times harder...

Fun fact: when the Phyche comm laser is pointed at earth, the size of the spot will be roughly as large as California. Even with the largest optical telescopes, the loss in this link will be insane. That's why you need single photon detectors.

As you get to farther and father distances, one thing you can do is shift from on/off keying to large-M Pulse Position Modulation. This way you can save up the power on your satellite to send fewer but higher power laser pulses, each of which carries more bits of data. I believe the DSOC mission will go up to M=256. Meaning each pulse of photons received on earth will carry 8 bits of information based on when it arrives within an alphabet of 256 time bins.

SNSPDs have lower dark count rate, and especially lower timing jitter in the near-infrared than APDs.

The deep space optical demonstrations I know of all work in the near infrared (e.g. 1550 nm), just like most of terrestrial fiber optics used for communication. Probably because there's lots of infrastructure at that wavelength already, and it's a good passband through earth's atmosphere.

In my experience, numba's killer feature is fast looping over numpy arrays. It does this extremely well. I work in an applied physics research lab, where we eschew matlab wherever possible. So we rely a lot on python, numpy and scipy. Even if we wanted to move to something like julia, it wouldn’t be practical. Every time we buy a new piece of equipment that has a python api and outputs a lot of data (we do a lot of work with picosecond resolution event timing), it’s going to use numpy.

Though if any numba developers come across this, I’d advise them to plan their upgrade process a little more carefully. The current numba conversion for python lists is due to be depreciated in favor of typed lists. But the typed list (List()) method is still too buggy. I experienced huge delays when popping and appending elements. Please flesh out these new methods before adding a bunch of warning messages about depreciation to the current builds.