esrh
Joined 6 years ago
Joined 6 years ago
In my case, I had worked in Japan for a year at a domestic megacorp (which is how I met my prof), had attended a few conferences, was very fluent in Japanese, and knew with certainty that the enjoyment of living in Japan would make up for any objective drawbacks.
My main issue with grad school is that except for an exceedingly small number of labs that regularly aim for top conferences, the process feels very un-serious. I think the standards are low; very few professors care a lot about doing really good work; the classes are unnecessary, low quality (nobody cared about teaching much, in my dept), mostly surface level; and there's not much of a bar for student research. I'd argue that domestic conference work is not only less prestigious an the author says, but it's also in most cases worse and less interesting, which is the bigger problem. This might be exacerbated by the fact that the vast majority of undergrads begin research in their last year and continue into the MS program by default so there are generally a lot of less motivated students. I still had a few exceptionally smart colleagues, but I never collaborated with them (in fact, our lab has hardly ever published a paper with >2 authors). I generally felt that their hard work was misplaced.
About a year into my MS, after pushing a bit of slop at international conferences, I more or less gave up on working on my project and got a remote job based in the US. Like the article says, it is exceptionally convenient that you can work for 28 hours a week on a student visa, since 28 hours of a US tech job is more than enough to support a nice lifestyle for 1 in tokyo. I might genuinely have dropped out and moved back home if it wasn't for it. DO get the auth at immigration time, it's much more annoying later.
In any case, I really enjoyed it in hindsight. As a final note, Science Tokyo is very simple to enter for international students -- the only requirement is that you find a professor willing to take you in. There are many structures in place for international students and I'd say it's fairly nice and comfortable.
PS: Maybe someone will enjoy reading my blog post about life at Science Tokyo/Japan: https://esrh.me/posts/2025-11-15-year-recap
This is not really relevant to your question, but I regret choosing janet for this, it's too opinionated and hacking on C is not as fun as lisp. I started writing my own version of schemesh in racket, but I never got far enough.
- I see that `sh` does not take in strings but instead lisp forms. How do you distinguish between variables that need to be substituted and commands? In my fork, the way to do variable substitution involves quasiquoting/unquoting. - Almost all of the features that make your language good for shell scripting are essentially syntactic features that can easily be implemented as a macro library for say, scheme. Why'd you choose to write in C++? Surely performance is not an important factor here. (I'm interested because I am currently working on a scheme-based shell scripting language).
The more space you take up in the frequency domain, the higher your resolution in the time domain is. Wifi sensing results that detect heart rate or breathing, for example, use even larger bandwidth, to the point where it'd be more accurate to call them radars than wifi access points.
The encoder itself is trained on latent embeddings of images in the same environment with the same subject, so it learns visual details (that are preserved through the original autoencoder; this is why the model can't overfit on, say, text or faces).
As for low level:
The most common early hardware was afaik esp32s & https://stevenmhernandez.github.io/ESP32-CSI-Tool/, and also old intel NICs & https://dhalperi.github.io/linux-80211n-csitool/.
Now many people use https://ps.zpj.io/ which supports some hardware including SDRs, but I must discourage using it, especially for research, as it's not free software and has a restrictive license. I used https://feitcsi.kuskosoft.com/ which uses a slightly modified iwlwifi driver, since iwlwifi needs to compute CSI anyway. There are free software alternatives for SDR CSI extraction as well; it's not hard to build an OFDM chain with GNUradio and extract CSI, although this might require a slightly more in-depth understanding of how wifi works.
I think the results here are much less important and surprising than what some people seem to be thinking. To summarize the core of the paper, we took stable diffusion (which is a 3-part system of an encoder, u-net, decoder), and replaced the encoder to use WiFi data instead of images. This gives you two advantages: you get text-based guidance for free, and the encoder model can be smaller. The smaller model combined with the semantic compression from the autoencoder gives you better (SOTA resolution) results, much faster.
I noticed a lot of discussion about how the model can possibly be so accurate. It wouldn't be wrong to consider the model overfit, in the sense that the visual details of the scene are moved from the training data to the model weights. These kinds of models are meant to be trained & deployed in a single environment. What's interesting about this work is that learning the environment well has become really fast because the output dimension is smaller than image space. In fact, it's so fast that you can basically do it in real time... you turn on a data collection node and can train a model from scratch online, in a new environment that gets decent results with at least a little bit of interesting generalization in ~10min. I'm presenting a demonstration of this at Mobicom 2025 next month in Hong Kong.
What people call "WiFi sensing" is now mostly CSI (channel state information) sensing. When you transmit a packet on many subcarriers (frequencies), the CSI represents how the data on each frequency changed during transmission. So, CSI is inherently quite sensitive to environmental changes.
I want to point out something that most everybody working in the CSI sensing/general ISAC space seems to know: generalization is hard and most definitely unsolved for any reasonably high-dimensional sensing problem (like image generation and to some extent pose estimation). I see a lot of fearmongering online about wifi sensing killing privacy for good, but in my opinion we're still quite far off.
I've made the project's code and some formatted data public since this paper is starting to pick up some attention: https://github.com/nishio-laboratory/latentcsi
The worst part is that they namedrop many other tangentially related and/or outright fraudulent "ai experts" like Hinton, Bengio, and LeCun.
I wrote something similar on a smaller scale for the keihin-kyuukou line in japan: https://rail.esrh.me. Now I live in tokyo and there's several transit options closeby so I would love to have some always on display like this in my room.
Unfortunately, while public transit in the US and Europe seem to be tracked by services with developer friendly APIs, this is not the case in Japan as far as i know -- not that much of a problem back then, i just needed to do some light web scraping.
I wrote all of the scraping/data and processing/frontend code in clojure and clojurescript, and wrote a small blog post about it here: https://esrh.me/posts/2023-03-23-clojure
When you use racket and clojure specifically, you're kind of walling yourself into one compiler and ecosystem (two, for clj/cljs). This is a significant disadvantage compared to scheme and CL.
CL the way most people write it is way too imperative and OO for me; it reads like untyped java with metaprogramming constructs. Clojure and scheme in my opinion guide you towards the more correct and principled approaches.
Out of all the lisps, regardless of which ones I like the most, I objectively write emacs lisp the most. This is has definitely influenced my opinions on CL syntax; like my weird love hate relationship with the loop macro: on one hand it's a cool, tacit construct that's impossible in a non-lisp, but on the other hand it hides a lot of complexity and is sometimes hard to get right.
> Smile 3.x is GPL-licensed, which poses some potential conflicts for some end users...The community consensus is converging around moving away from Smile due to the GPL-relicensing issue, focusing instead on Tribuo...
(tribuo is developed by oracle)
It's a really great thing that the java community has a high performance and well accepted (~5x stars than tribuo) ML package that's GPL. CF python where the top two libraries are developed by google and facebook. The GPL protects individual, independent developers.
I don't think it's right to recommend that new users move away from the package because of licensing issues; the fact that it's GPL now is a good thing for everyone except corporate users (probably a great part of readers). The people who might have GPL problems already know themselves when they'll have a problem.