wging

Better link: https://slatestarcodex.com/2014/07/30/meditations-on-moloch/

The article links to a better article, https://news.sky.com/story/royal-navys-experimental-ship-car..., which calls the device an accelerometer. I think the article linked here got literally all its information from that other article. Apparently it's a small number of rubidium atoms, cooled to near-absolute zero, under which conditions they can apparently measure gravitational effects and make deductions from that ("measure extremely accurately the influence of gravity on their system, which in turn allows them to measure the speed and direction of its movement").

Haven't read Heinrich's latest, but his Why We Run (also known as Racing the Antelope, for weird reasons) is an amazing book.

If that’s true, then you’ll need to be careful to decouple the phrase “it doesn’t understand” from your predictions about its behavior. I think most people who say it doesn’t understand intend to imply a deficiency of capability, not just an internal state.

The Peace War is ambiguous: it leads into Marooned in Realtime, where civilization has disappeared, and the remnants that were sent forward in time don’t know why. It could have been a civilization-ending catastrophe, but not necessarily.

You can't see the underlying link? It's visible on old.reddit.com: https://www.richmond-news.com/highlights/church-of-the-flyin....

It seems inferrable, at least in broad strokes, from the other, non-technical meanings of the word. See for example "the court is now in session" or "I had a physical therapy session this morning".

The 'Cosmic' name also indicates that; see https://github.com/pop-os/cosmic.

I addressed this above: "... because it's applicable to Sowinski's work [meaning middle-distance pacing], far more so than your own pacing for the longer races."

> 4:30/mile pace is faster than all but the fastest amateur runners

The article is talking about middle distance running, typically 800m-3000m, not long-distance running. 1s/400m is actually pretty huge in competition.

> you'd be liable to kick each other.

Front-to-back contact happens sometimes, even in professional races.

Not necessarily! Leading is more tiring, especially at a fast pace. Even if you are the fastest athlete in the field, and know it, you can still lose by wearing yourself out at the front. So for some runners it's as you say, but for the top few athletes it can be more like "my margin of superiority isn't sufficient to pay the cost of leading a fast race". (Some made-up numbers. Suppose you're 1 second faster than the second-best runner under ideal conditions, but you lose 1.5 seconds by leading. Result: you lose by half a second.) Which is in fact why pacemakers are employed at so many non-championship races, it solves the problem of people thinking "if I push the pace at the front I may pull everyone to a faster time (including myself), but sacrifice place" that leads to results like what you saw in 2016.

That doesn't mean everyone played their hand well in 2016 - clearly they didn't. By the way, check out Centrowitz's little shimmy at maybe 450m to go/2:50 in that race - he made sure to be in front when it got going, that's what makes his run brilliant and not just lucky.

For real examples of leading being a cost in a fast race, see the most recent two major championships - worlds 2022 https://www.youtube.com/watch?v=QcRrBYx2XG8 and the Olympic final of 2020/21 https://www.youtube.com/watch?v=us9bM_WGYlY. Both are really fast as championships go, and in both the leader for much of the race loses. Would they still have lost if someone else had been in front? ...Maybe. But I think it would've been closer.

> Running in a pack is also just easier, not even considering the wind breaking potential depending upon speed and prevailing breeze.

It is worth noting that for mid-d races it's not just about countering wind, but also air resistance. There is a significant performance impact even if it's not windy. See for instance https://www.runnersworld.com/training/a20823445/does-draftin...: "Pugh runs some calculations to determine that at 4:30 mile pace, drafting one meter behind another runner on a still day saves about 80% of the energy you'd otherwise spend fighting air resistance. That corresponds to about 1 second per 400 meters at that pace, and more on windy days." (Highly recommend Hutchinson's other work on the running and sports science, btw.)

(I am sure you know this. I'm mentioning it for others, because it's applicable to Sowinski's work, far more so than your own pacing for the longer races.)

> Sometimes, races without pacers can have exceptionally slow splits (which-- admittedly, leads to a very exciting and tactical conclusion on occasion).

The classic example here is the 2016 Olympic 1500m final (https://www.youtube.com/watch?v=Grf_62s_95w). Centrowitz should not have won that on paper. It ironically seems to have revolutionized the event, in a sense - championships have gotten really fast since.

It's important to distinguish between the Breaking2/INEOS pacing (with a rotating team of pacemakers that drop in and out of the race) and the pacing that has been allowed in every world record (pacemakers that start with the field, but may drop out, as does Sowinski in his own pacing).

In fact Kipchoge's legal world record (the 2:01:09, not the 1:59) had pacemakers for the first 25km (of 42.2).

In some use cases you should be able to just use `var` for a simpler call pattern: https://docs.sympy.org/latest/modules/core.html#var

(it puts things in the global namespace, but for the typical calculator use case that's probably fine)

(Sage seems to work like this too - it may use sympy under the hood)

One lovely little thing: since everything is a buffer, autocomplete has more to work with. Specifically I'm thinking of hippie-expand's `try-expand-dabbrev-all-buffers`, which just uses all buffers as sources for 'expansions' for what's currently written. So you type "thi" -> M-/, and because another buffer has "thing-you-want", it is able to complete what you wrote out to "thing-you-want".

This is straightforward when you just think of buffers as being source files in your IDE, but it's not limited to that - you can also complete from a dired buffer, or your compiler output buffer, or your REPL. So you can get a filename to expand, even though no source code file actually contains that filename. If instead of dired and compile-mode you were using a separate file manager, and a separate terminal window to compile, you'd have text in three separate programs and no expectation that the text editor in your IDE would be able to see the other two.

> Switch to the scratch buffer (think there's a missing RET at the end)

In vanilla emacs you need a RET, but I bet that like many people, OP's using a mechanism that will just select the matching item if there's a unique match, rather than the built-in buffer selection mechanism.

I use ido (with flx-ido for fuzzy completions), and it works for me as stated: C-i in the minibuffer runs `ido-complete`, which selects the unique completion if there's only one. (By default, that is, this is emacs and so of course there's a variable `ido-confirm-unique-completion` that you can set to customize this behavior.)

> Recently, Timsort has become popular, also a variation of Merge Sort. However, Timsort was not invented yet in 2008.

Timsort is from 2002. Not sure where this comes from. Perhaps it wasn't as popular or widely known in 2008 as it is now, but I actually learned about it at about that time. See also:

https://mail.python.org/pipermail/python-dev/2002-July/02683...

(edit: timsort was introduced to Java in 2009, per https://bugs.openjdk.org/browse/JDK-6804124, and knowledge of it would probably have spread much further from that point, so maybe that's the source of confusion?)

sounds like you're talking about a specific company, or is this just a general Slack thing I've forgotten? by 'forced' do you mean they aren't able to create channels at-will?

I'm pretty sure that's just how the badging system works. Amazon is orders of magnitude too big for 'everyone has access to everywhere' to make sense. When I traveled I sometimes had to talk to people (or send email) to make sure my badge was activated in a new location, even for offices in a different city but the same business unit. There were also restrictions based on whether you actually worked on a particular thing, even for non-acquisition parts of the company.

Those 70k wouldn't all be on the same channel. Even at a small company you might want to have distinct channels with different purposes - maybe #sales, #sw-engineering, #announcements. A 70k-person company might have a few large channels but most of the activity would take place in much more focused channels, of which there would be thousands or tens of thousands. A software team of a dozen people might have their own channel, for example. (Actually, in my experience we had several for distinct purposes.)

(and of course yes, there can also be big general-purpose channels with a lower signal-to-noise ratio)

Those are cool properties. Another one is that you get a compilation error if your recursive call isn't in the tail position (and thus would actually grow the stack when you thought it didn't).

One thing I don't think you can do with loop/recur, though, is optimize more complicated bits of recursion than a single function that calls itself. I.e. imagine a recursive call pattern that goes like f -> g -> f -> g -> ...

(edit: I'm pretty sure this is why trampoline exists, though I've never really played with it... https://clojuredocs.org/clojure.core/trampoline)

Tail call optimization can get you that, too. If you've written Scheme and/or gone through SICP you might be familiar with this: you write a recursive function, with the recursive function call as the last thing the function does ('tail-recursion'), and the compiler/runtime is able to optimize those recursive calls out rather than consuming one stack frame of space per call ('tail call optimization'). Clojure has loop/recur at least partially because it doesn't support tail-call optimization.

See https://en.wikipedia.org/wiki/Tail_call for more. Or SICP might be a good resource. https://sarabander.github.io/sicp/html/1_002e2.xhtml

It is also caching requests on-disk. See for instance https://github.com/ianb/infinite-ai-array/blob/main/iaia/gpt...

The problem* is that if a prompt changes slightly then it won't be a cache hit.

* okay, one problem.

Per the README (and the source code), requests to GPT are cached. I know that doesn't solve the stability problem, since the cache is keyed on the exact prompt among other parameters, but it's something at least.

The source code shows that it's using pickling to store OpenAI responses on the local filesystem. See here:

https://github.com/ianb/infinite-ai-array/blob/main/iaia/gpt...

and here:

https://github.com/ianb/infinite-ai-array/blob/main/iaia/gpt...

Yes, it works, and yes, it requires drivers, but those are readily available as I understand it. Some of the Linux laptops the OP mentioned do have discrete graphics cards (Oryx, for example, has an Nvidia card; for clarity, like all of System76's computers it comes with Linux).

As I understand it, if you are willing to run proprietary code you can sometimes get better drivers. I would be fine with that, personally, but not everyone agrees. ("Proprietary" refers to availability of source code - some drivers are free-as-in-cost but not open source, and you might have worse performance with open source drivers. This might just be Nvidia, or it might be AMD/Intel too.)

I've got a last-gen Lemur that I really like. (lemp10 / 11th-gen Core i7-1165G7, one generation older than jart's link.) I'd recommend their new one on that basis. I'm pretty happy with Pop OS.

However, I'd say the decision between it and the Oryx (which OP has on their poll) is about OP's needs and preferences, rather than one strictly beating the other.

It has a long battery life even after a few years of use, compared to other laptops I've used (higher rated capacity, and probably lower power consumption than the Oryx). It's very thin and light, but still fast and doesn't get very hot.

One caveat though: it's got no discrete GPU, which may or may not matter for you. (Probably that accounts for a good part of the battery life.) If the Lemur were my only computer I'd probably regret it on that basis. Its specs, even setting aside the GPU, are also going to be less impressive than the Oryx.

But the Lemur is about half the weight - I would happily trade the performance for battery life and mobility. I also like the ability to charge with USB-C - a non-power-hungry laptop means you don't require a special power connector (or more advanced USB power delivery that IIUC isn't really widespread yet).

> All children of Feanor (the main contingent of the Noldor)

This makes it sound like most Noldor were children of Feanor or that most of them followed Feanor and his sons, but that's not the case. The sons of Feanor and their followers were first to Middle-Earth - is that what you mean by 'main'? It's stated a few times that there weren't as many of them. The Noldor were an entire people, and most were neither Feanor's children nor followers of his children. (They were technically all under Feanor as high king of the Noldor for a time, though.) This is from the Silmarillion, describing their travel through Valinor on the way to Middle-Earth:

> Fëanor and his following were in the van, but the greater host came behind under Fingolfin; and he marched against his wisdom, because Fingon his son so urged him

and then after those who didn't follow Feanor cross to Middle-Earth in the north, many die, but there are still more of them:

> for the agony of those that endured the crossing of the Ice had been great, and Fingolfin held the sons the accomplices of their father. Then there was peril of strife between the hosts; but grievous as were their losses upon the road, the people of Fingolfin and of Finrod son of Finarfin were still more numerous than the followers of Fëanor,

I disagree. The utility of short names is not just that it takes less effort to write them. They're also far easier to read and understand. IDE autocompletion doesn't help with that, nor does any other tooling, really. Since code is read much more frequently than it's written (including but not limited to any time that related code has to be changed), names should be as short as possible without sacrificing clarity. Excessively long names are harder to parse, and can slow you way down when trying to understand code.

(I'm arguing against what I see as your central point, but to be fair, 'without sacrificing clarity' is doing a bit of work in the paragraph above... your example is actually a good case of a bit of additional length being actually worth it. I would say timeoutMs or timeoutSecs are good shorter alternatives, "ms" and "secs" being widespread and clear abbreviations. You're completely right that 'timeout' is insufficiently clear for a purely numeric type, though I'd disagree that you need all that much type system magic to make it OK. For example calling a `java.time.Duration` `timeout` seems fine.)

I'm not so sure the input "errors" called out in this post qualify as errors in the dataset. I wouldn't necessarily call an input prompt with errors a dataset problem. It's important to be robust to minor input errors, rather than requiring perfection on the part of the user.

I'm thinking here about "People is around the field watching the game", and other input errors, not necessarily output errors, but maybe if I thought about it a little more I'd be able to make similar arguments for accepting weirder outputs? Not as confident about that. For inputs, the hopeful effect of training/validating against such examples would be to make the model somewhat able to deal with imperfect inputs when the overall meaning is clear.