larsrc

8 ms·

61.
by larsrc 2y ago
One of me and my PhD advisor got it wrong. When "120% slower" is vastly faster than "80% slower", there will be confusion.
62.
by larsrc 2y ago
Looking at that map of sites in France alone, randomly distributed is a good first approximation for figuring out the probability. Pondered the estimation a bit more. The first two points of a group of 7 define a line. The probability of th
63.
by larsrc 2y ago
The rules are more like guidelines, you see. The universe has had a lot of opportunities to come up with wacky stuff.
64.
by larsrc 2y ago
I would say the next logical step is figuring out the probability that with this many points, what is the likelihood of 7 of them being this close to being on a line? We can assume a uniform random distribution on the unit circle or square
65.
by larsrc 2y ago
It's still a SPOF, though.
66.
by larsrc 2y ago
You understood what they meant, though. But yeah, it's confusing. I argued with my PhD advisor over this several times. "50% slower" or "10% slower" is ready to understand, but "96% slower" is harder to fi
67.
by larsrc 2y ago
Disclaimer: never was a game dev You're conflating unit tests and functional/integration tests there. A unit test should test that a single function/method/class does what it's expected to do. The game design change
68.
by larsrc 2y ago
That's unavoidable for anything even slightly complex. The FairMouse project ( https://www.nager-it.de/en/maus#language ) shows the full graph for a plain computer mouse. Microwaves are more complex.
69.
by larsrc 2y ago
Even if most didn't live in caves, if enough of them spent enough time there they would surely end up painting something. And caves are good places for paintings to survive. I'm not even sure one could separate religious and non-r
70.
by larsrc 2y ago
Me too. Don't name your thing with diacritics most people don't know how to make on a keyboard.
71.
by larsrc 2y ago
Because that was home? The caves provided shelter for predators and the elements, and a fixed place for a fire. So sitting around when there was spare time, of course one would scribble on the walls. Also, survivorship bias.
72.
by larsrc 2y ago
Some related articles with hardware implementations: https://arxiv.org/pdf/2211.04053 https://hal.science/hal-01327460/document https://archive.ll.mit.edu/HPEC/agendas/pr
73.
by larsrc 2y ago
Design docs are the _mise en place_ of software development.
74.
by larsrc 2y ago
Googler here. I used to hate writing design docs, even though I have several published papers. But a few years back I realized the main benefits for me: * It empties my head of the immediate parts of the idea, letting me move on to deeper p
75.
by larsrc 2y ago
> Worst case scenario is when by improving the problem definition a simple solution appears that doesn't require a complex design. The author having invested a lot of time in a complex design (that historically and many committees s
76.
by larsrc 2y ago
> You have a point in that bureaucracy can needlessly get in the way of meaningful change. What a good early design doc can do is turn meaningless changes (e.g., doing a project for the sake of promo) into meaningful non- or minimal chan
77.
by larsrc 2y ago
Caveat: Googler here. One of the things that had been problematic at Google is the creation of many more products than are really needed, leading to the infamous Google Graveyard. One of the reasons I have come to like writing design docs f
78.
by larsrc 2y ago
Wolfram's "A New Kind of Science" posited the study of cellular automata as a revolutionary new field of science. Did you agree then? Do you now? If you changed you mind, why?
79.
by larsrc 2y ago
Usually an invariant is something you explicitly state about a data structure or algorithm, and which must hold before and after an operation, but can be temporarily violated. What you are talking about here are assumptions, which are usual
80.
by larsrc 2y ago
Thanks to Titus Winters for the phrase "Software engineering is programming integrated over time". Handling evolution of software is different from just writing it.
81.
by larsrc 2y ago
Some "required" fields in very commonly used protos ended up being unused, but everybody has to fill them out all the time. If they didn't, the proto wouldn't even parse, by design. Protobufs explicitly do not have a bui
82.
by larsrc 2y ago
Protocol Buffers are the narrow waist of Google.
83.
by larsrc 2y ago
Why do amateur space craft and submarines go together? See Copenhagen Suborbitals.
84.
by larsrc 2y ago
Seems lots of people consider just getting high to be sufficient for them. /j
85.
by larsrc 2y ago
And "airmosphere".
86.
by larsrc 3y ago
Nice tests, but could you please use 0-based Y-axes in the charts? You're visually exaggerating the improvements.
87.
by larsrc 3y ago
A nice intro to making macros, which is one of the most powerful parts of LaTeX indeed. Autoref itself seems a fine way of messing up your references and making your source code less readable. The beauty of naming is that you have the conte
88.
by larsrc 3y ago
Google has 100000+ employees to create mess, and not nearly enough to clean up that mess. They have done a _lot_ to improve the coding culture over the years, without that it would have been unworkable. As for the generations, may I have th
89.
by larsrc 3y ago
Are these properties unique to printing in titanium? Doesn't sound like it. So hopefully we will see this as an infill option soon.
90.
by larsrc 3y ago
For an interesting and humorous tour of drinking across history and cultures, read Mark Forsyth's "A Short History of Drunkenness". Getting hammered had been crucial, even sometimes obligatory, in many places throughout histo

More ›