Ce Guo (/tsə ɡwɔː/) is a programmer who occasionally attempts to write research papers. His interests include reconfigurable computing and computational risk management: making causal discovery and market simulation fast enough to be worth doing, searching hardware design spaces under resource constraints, and building models that can be asked why. These are, regrettably, less fashionable than chanting “LLM” a few times and treating the result as a considered opinion. Reviewers tend to find his papers heavy on hardware block diagrams, causal graphs, and untidy time-series plots, and rather too light on the confident storytelling that substitutes for rigour.

Fortunately, Imperial College London employs him as a Research Fellow in the Department of Computing, probably because he has little patience for compiler warnings, or for conclusions that arrive with no working shown. He supervises student projects, mostly by encouraging people to build things that actually run, and then to publish the code so that others can check whether they do. This has produced a worrying number of working systems, students who ask awkward questions, and the occasional publication. He likes trying odd ideas out in code, mostly because code is the cheapest way to find out that an idea was wrong.

More generally, Ce is less interested in answers than in the machinery that produces them. How an answer was reached usually tells you more than the answer does. His work looks scattered. He would defend it on the grounds that a market, a causal graph and a hardware design space are all large spaces searched under tight constraints, and that the same few shapes keep turning up in different fields under different names. Understanding something mostly means finding a shorter description of it. A shorter description is also a riskier one. It claims more with less, so it is easier to check and quicker to break. That is the kind of claim he likes. It is also why he does badly in places that reward confidence over correctness, or where you learn you were mistaken years later and at some expense. He would rather work where mistakes are cheap and the bad news arrives early. Machines are good at this. They answer quickly, they say exactly what went wrong, and they do not care who is asking.