suuuuuuuu

> I am saying that I am not aware of many things it successfully predicted ahead of observations being made.

CDM successfully predicted the CMB features that COBE could measure. LCDM certainly was a known model before supernova data in the 90s first provided evidence for it. CMB data shortly after detected a consistent fraction of \Lambda and have since provided evidence of multiple kinds (structure growth in addition to the original, the distance to the last scattering surface). Distances from baryon acoustic oscillations are another subsequent, independent test that corroborated the LCDM model.

2 and (especially) 1 are to me too speculative to place much weight on. I would also draw analogy to the Standard Model of particle physics: its predictivity and past success are not refuted by any deficiencies beyond the regimes we've been able to probe thusfar. (Of course, in the SM we fully expect those deficiencies.) Just to say that not every failed prediction falsifies a model's success in previously established regimes of energy/scale/dynamics.

> By the way, I am not saying LCDM is not massively successful. It can clearly be used to explain a lot of things.

Sure, I didn't think so.

> It does not have a great predictive record; it is good at explaining obervations after the fact (the CMB notwithstanding).

Can you elaborate on what you mean? LCDM hasn't been "tweaked" since \Lambda was established in the 90s (at least, not for large-scale cosmological observations). The current discrepancies are all at the precision level (<10%) rather than a qualitative O(1) difference. An important (but not dispositive) nuance is that LCDM well explains all observations individually; the percent-level tensions arise only between fits to datasets, meaning unknown systematics remain a viable explanation.

The unknown fundamental nature of CDM (as important a problem as it is) seems irrelevant to arguments about LCDM's predictivity (as a cosmological model).

> Sorry, not buying the argument from authority here.

You asked what I based my answer on, and domain expertise is the answer. The rest was an actual argument.

> Yes, this part I agree with, a cosmological constant has to be, well, constant.

This is a nominal fallacy, since the reason it must be homogeneous (rather than just time independent) is actually the same reason all other (w != -1) fluids must not be homogeneous.

> Not sure I agree with this as a sweeping general claim > I don't understand the argument here.

The argument is general because it rests on energy-momentum conservation and gauge invariance. The perturbed energy-momentum equations for a fluid have source terms \propto (1 + w) * <metric perturbations>, and therefore cannot be solved by fluid perturbations that are zero at all time and locations unless w = -1 or the metric is also homogeneous. The same guarantee of dynamics underlies the gauge invariance argument: while one can choose a frame in which a single fluid is homogeneous ~~at any instant, that gauge choice is only valid at all times if the fluid's energy density is time-independent~~ EDIT: that property is only gauge invariant when w = - 1.

> Unfortunately these links don't seem to be showing me specific excerpts, just the whole paper. Can you give page/section references or equation numbers?

Open in a chromium based browser or search the article for "perturbations".

Domain expertise. (I would ask the same of you!) Fluids always have perturbations, except in the special case of w = -1 (cosmological constant); otherwise, dropping them violates energy-momentum conservation and gauge invariance.

Here are a few excerpts from DESI:

* https://arxiv.org/html/2404.03002v3#:~:text=Although%20a%20c...

* https://arxiv.org/html/2404.03002v3#:~:text=Since%20the%20pa...

Pedantic point, but in the time-evolving model ("model"), dark energy is not uniform across space - but the non-uniformity turns out to be negligible.

What's referenced in the quote is a reanalysis of a single dataset (by the same team) that revised the combined significance downward.

I envy you that it admitted that rather than simply making up data and lying about it.

The arguments in the video are mostly misdirected, conflations of related but distinct issues, or (hypocritically) just opinions. Here are the unpacked issues as I see it:

1. Whether to summarize data by a handful of summary statistics or a full density. Obviously, some statistics reported in isolation can misrepresent the underlying distribution, but these considerations ultimately depend on what specific point one seeks to make with a plot. There's no reason a priori that visually annotating summaries/quantiles on a distribution plot can't be helpful (quite the contrary).

2. Whether to "smooth the data" (read: perform kernel density estimation). In some sense this is a long-solved problem: there are mathematically grounded methods for estimating the optimal KDE bandwidth (with varying degrees of assumption on the underlying distribution), which are what's used by any serious plotting library. And whether authors adequately describe what they're actually plotting is a separate matter. That said, there are many reasons not to show a KDE over, say, a binned histogram, especially with raw data and/pr small sample sizes, but these are entirely orthogonal to the choice of displaying a KDE as a violin plot versus something else.

3. How to normalize densities. With raw data, you probably want to compare frequencies (a proper pdf). If displaying just a single distribution, there's obviously no reason not to show the density (it's only a trivial rescaling of the axis tick values). When comparing multiple, the decision again depends on the point of the plot. Losing dynamic range for broader densities when compared with narrower ones can be counterproductive. E.g., in Bayesian parameter inference (where the data are MCMC samples), we almost never compute the actual normalization factor, but rather want to compare relative probabilities (i.e., within a single distribution) of different parameter values across different distributions. Of course, nothing forces one normalization over another for violin plots.

All of those are separate (and rectifiable!) issues from the defining characteristics of a violin plot:

1. Distributions displayed vertically rather than horizontally (both being harder to interpret and inappropriately suggestive). We almost exclusively visualize functions plotted vertically across a horizontal coordinate. I think this is the only valid, specific criticism of the common violin style itself, but the fix is of course trivial.

2. Horizontal violin are then only different from a ridge plot by a) not overlapping (which to me is a major improvement over standard ridge plots, but also trivially fixed) and b) being displayed symmetrically. I find it slightly easier to compare relative heights in the symmetric version, especially when comparing many distributions (such that each is relatively narrow). Even if not, the difference is so superficial/trivial that I don't find it worth arguing about.

Beyond this, the video's main argument (repeated every minute) seems to be that "it's bad, it's just bad", but there are only so many ways to make a 5 minute argument fill a 42 minute video. (This style of video is so grating to me.)

That's how you know it's just for show. A practically equivalent (for Fable) but infinitely more valuable contribution would've been to implement any missing lints as a PR to ruff rather than reinventing (copying) the wheel.

Your reference here is a 33 year old paper whose quoted observations and theoretical claims are totally out of date. The measured light element abundances are now consistent (and have been for decades).

The black body distribution of the CMB is the (confirmed, of course) prediction of the Big Bang. The structure, age, etc. all depend on the cosmological model, and the claims that no such model can explain observations is ridiculous, given the counterexample of the \Lambda CDM model, the cornerstone of the field for decades now, that explains them all.

It's almost impressive how obstinately you've convinced yourself of something so blatantly wrong and out of date, using only a reference predating the entire modern era of cosmology that you even admitted to not having read "for a while." A far, far cry from engaging seriously in a topic.

Like with the frontier LLMs, seeing commentary on this site on topics that I'm an expert in makes me seriously doubt whether I should lend any credence at all to what's said about those that I'm not.

I think people working on these abstractions would claim that an appropriate abstraction does involve the exact features you mention. Cache hierarchies and vectorization are common to CPUs and GPUs - in some sense, the numbers parametrizing them are all that differs. With a good abstraction, this machine-tuning can be automated.

See https://arxiv.org/abs/2512.17101. I've used some of the tools in the stack they describe (and see Sec 2 for an overview of others). JAX/XLA/etc. are somewhat similar, though still without user control over transformations.

Perhaps part of the reason for the bad takes in this thread is due to taking "language" overly literally (perhaps also the fault of the linked blog post itself). I think one thesis of the above tooling is that, when tuning and generating code (CUDA, OpenCL, what have you) at runtime, the best "languages" for these abstractions are, amusingly, scripting languages like Python. Having CUDA/etc. as a back end without having to hand-write/-transform/-optimize it is indeed the point.

Sorry, I wasn't aware of these developments (having abandoned CUDA for hardware-agnostic solutions before 2020). It doesn't change my point anyway, if it's specific to a single vendor.

I'm extremely dubious that such an opaque abstraction can actually solve the (true) problem. "Not having to write CUDA" is not enough - how do you tune performance? Parallelization strategies, memory prefetching and arrangement in on-chip caches, when to fuse kernels vs. not... I don't doubt the compiler can do these things, but I do doubt that it can know at compile time what variants of kernel transformations will optimize performance on any given hardware. That's the real problem: achieving an abstraction that still gives one enough control to achieve peak performance.

Edit: you tell me if I'm wrong, but it seems that std::par can't even use shared memory, let alone let one control its usage? If so, then my point stands: C++ is not remotely relevant. Again, avoiding writing CUDA (etc.) doesn't solve the real problem that high-performance language abstractions aim to address.

CUDA is not C++. CUDA for GPU kernels is its own language. That's the actual problem requiring new languages or abstractions.

CUDA is not C++. CUDA for GPU kernels is its own language. That's the actual problem requiring new languages or abstractions.

If you think C++ is the best here, then I don't think you've actually worked in this space nor appreciated the actual problems these languages try to solve. In particular because you can't program accelerators with C++.

Memory bandwidth is often the problem, yes. Language abstractions for performance aim to, e.g., automatically manage caches (that must be handled manually in performant GPU code, for instance) with optimized memory tiling and other strategies. Kernel fusion is another nontrivial example that improves effective bandwidth.

Adding on the diversity of hardware that one needs to target (both within and among vendors), i.e., portability not just of function but of performance, makes the need for better tooling abundantly obvious. C++ isn't even an entrant in this space.

Don't underestimate the willingness of physicists to skimp on literature review.

I myself tried a similar exercise (w/Thinking with 3 Pro), seeing if it could come up with an idea that I'm currently writing up that pushes past/sharpens/revises conventional thinking on a topic. It regurgitated standard (and at times only tangentially related) lore, but it did get at the rough idea after I really spoon fed it. So I would suspect that someone being impressed with its "research" output might more reflect their own limitations rather than Gemini's capabilities. I'm sure a relevant factor is variability among fields in the quality and volume of relevant literature, though I was impressed with how it identified relevant ideas and older papers for my specific topic.

The implication was that likely not all of the advice in this article, which was written by biologists, is actually attributable to McCarthy.

This is certainly too strongly worded to be correct. I use footnotes quite a bit in my papers (physics) as a strategy to handle the "two audiences" problem - that many or most readers just skim for main ideas, but some (and those whom I might argue are more important) try to follow the details closely. I presently use footnotes for the latter audience for certain supplementary details or technical qualifications that would break the reading flow or add unnecessary length for the former.

I do appreciate the arguments that footnotes can be distracting, or that one doesn't know whether to skip them, but at present I see them as the best option for keeping the main body streamlined/as short as possible without sacrificing points that I'd like to make that wouldn't make for or fit into an appendix.

I think it's just wrong. Related, linked recently here: https://dwest.web.illinois.edu/grammar.html

The authors are biologists, so I suspect they're not particularly versed in mathematical writing (and that McCarthy was not likely providing them much advice on it).

I like a lot of the advice here, except

> Keep sentences short, simply constructed and direct. Concise, clear sentences work well for scientific explanations. Minimize clauses, compound sentences and transition words — such as ‘however’ or ‘thus’ — so that the reader can focus on the main message.

Repetitive sentence structure is not engaging and lulls a reader to sleep, no matter the context. Clauses and transition words and nontrivial sentence structure allow for qualification and clarification, juxtaposition and contrast, and emphasis, often with many fewer words than if written as a series of single independent clauses. A short sentence following longer ones punctuates its point and can effectively lead into subsequent sentences that express more complex ideas/explanations.

In my own scientific writing I also frequently use compound sentences to indicate that the ideas are related (causally or otherwise). It's also unclear to me how one could more efficiently communicate logical or causal flow between ideas than with transition words like "thus" or "therefore."

This is certainly the case, but it does make it all the more amusing that the myth

> Commas denote a pause in speaking.... Speak the sentence aloud to find pauses.

made its way into this article. Hard to imagine that this particular point, to which I might attribute many of the comma splices I see in scientific writing, actually came from a professional writer.

I would consider replacing my jupyterlab usage with marimo were it less opinionated about workflow - it offers a lot of benefits that aren't tied to its execution model. I like the editor/interface and the representation as python files for portability, version control, and the ability to import from other notebooks, but I have no interest in changing my workflow (in particular insofar as marimo is restricted compared to python itself). E.g., I want to be able to redefine variables and use star imports in my personal, exploratory notebooks, and I'm happy to retain responsibility for top-to-bottom executability (as in regular python scripts). I would definitely consider marimo if these restrictions could be opted out of if one has reactive execution disabled.