dannyz

While `uv` works amazingly well I think a lot of people don't realize that installing packages through conda (or let's say the conda-forge ecosystem) has technical advantages compared to wheels/pypi.

When you install the numpy wheel through `uv` you are likely installing a pre-compiled binary that bundles openblas inside of it. When you install numpy through conda-forge, it dynamically links against a dummy blas package that can be substituted for mkl, openblas, accelerate, whatever you prefer on your system. It's a much better solution to be able to rely on a separate package rather than having to bundle every dependency.

Then lets say you install scipy. Scipy also has to bundle openblas in their wheel, and now you have two copies of openblas sitting around. They don't conflict, but this quickly becomes an odd thing to have to do.

While the limit of increasingly concentrated Gaussian's does result in a Dirac delta, but it is not the only way the Dirac delta comes about and is probably not the correct way to think about it in the context of signal processing.

When we are doing signal processing the Dirac delta primarily comes about as the Fourier transform of a constant function, and if you work out the math this is roughly equivalent to a sinc function where the oscillations become infinitely fast. This distinction is important because the concentrated Gaussian limit has the function going to 0 as we move away from the origin, but the sinc function never goes to 0, it just oscillates really fast. This becomes a Dirac delta because any integral of a function multiplied by this sinc function has cancelling components from the fast oscillations.

The poor behavior of this limit (primarily numerically) is the closely related to the reasons why we have things like Gibbs phenomenon.

Observation assimilation is a huge field in and of itself. Observables have biases that have to be included in assimilation, they also have finite resolution and so observation operators need to be taken into account.

TEMPO is one of three similar instruments, GEMS for Asia and Sentinel 4 for Europe.

Similarly I switched to Colemak, and I agree, it's not worth it for most people.

I switched because I never typed with proper technique in QWERTY. I would only use ~2 fingers on my right hand. I tried multiple times to retrain myself but there was just too much muscle memory. The only way for me to switch to proper technique was to switch layouts.

I wasn't worried about safe usage, more that some of the initialization may be moved inside the benchmarking function instead of outside of it like intended. I'm sure you know more about it than me though.

Related on the Eigen benchmarking, I see a lot of use of auto in the benchmarks. Eigen does not recommend using it like this (https://eigen.tuxfamily.org/dox/TopicPitfalls.html) because the template expressions can be quite complicated. I'm not sure if it matters here or not, but it would probably better not to use it in the benchmarks.

These benchmarks look to be ~8 years old, and don't really agree with benchmarks done by other sources (https://romanpoya.medium.com/a-look-at-the-performance-of-ex..., https://eigen.tuxfamily.org/index.php?title=Benchmark)

In general I would be skeptical about any benchmark that claims to beat MKL significantly on standard operations

It seems like every large project these days has coalesced around Eigen, what are some of the advantages that Blaze has over Eigen?

I agree, I think upper bound constraints go against what is commonly accepted and used in the Python ecosystem. What I try to do on my projects now is to always have a nightly CI test step, in theory if an updated package breaks my package it will be caught fairly quickly

There have been lots of posts here about efforts to “modernize” Fortran, which is great! But I’m wondering what the current state of things is. Has anyone recently started a new project using modern Fortran and can comment on their decision?

There’s a lot more to it than just snappiness. But where I think Microsoft is going to have a tough time is ensuring x86 compatibility as well as Rosetta does.

The short answer is to measure methane you rely on methane absorption features. To do that you need to be looking at a source through the methane plume, from a satellite this source is the ground. From a ground instrument you can use the sun as a source, but it limits the times of day/direction/location you can measure from.

From a user point of view Python packaging has probably never been better, but it is still a huge mess from anyone having to maintain these projects which might explain some of the dichotomy in the comments.

In my experience most of these packaging tools work fine for pure Python packages, it is when you try and bundle extensions in a cross-platform way that things get really messy. For better or worse I think third party package managers somewhat outside the Python ecosystem, i.e. conda + conda-forge, are the only tools that get this right.

A lot of package managers that distribute binaries (e.g. conda-forge) rely on CentOS 7 because of the relatively old glibc version available, I wonder what all of these projects are planning on moving on to

Base Fortran has a lot of advantages for scientific programming over other languages, but I think there are two factors that are contributing to it's unpopularity:

1. Models are increasingly becoming much larger projects where flexibility, configuration, setup, are just as important as the actual number crunching that's done. These aren't areas that Fortran is known for.

2. The existence of libraries like Eigen for c++ provide most, if not close to all, of the advantages that Fortran gives for number crunching.

I was starting to get wrist pain in my right hand at the end of the day. I believed it was from never learning to type properly, I only used two fingers on my right hand even though I could type relatively fast.

I tried many times to re-train myself to type properly, but with proper technique I was only typing at half of my normal speed and would give up quickly.

In the end I switched to colemak to force myself to re-learn how to type with proper hand technique. It took a year but now I can type faster than I used to be able to with QWERTY and without any pain. It was definitely worth it for me, but there are enough annoyances with everything being QWERTY by default that I wouldn't recommend anyone make the switch without a reason to do so.

It does seem odd they would want to set up a lab in close proximity to what they wanted to study

I have found that there can be huge quality differences between cheap and more expensive LED bulbs as well. Specifically the ones that use a cheap rectifier. Sometimes I think that I can see them flickering out of the corner of my eye.

It would be interesting to see some example questions and answers. Since the test is multiple choice is it possible that the model has gotten very good at estimating how likely a possible answer is?

Annualized over the last 6 months inflation is now under the 2% target. I would be surprised if we see anything more than a quarter-point at the next meeting.

Sulfur dioxide in the troposphere isn’t very long lived and won’t make it to the stratosphere where it actually has a surface cooling effect. Even small volcanos have very little impact on stratospheric aerosol formation since they do not inject sulfur to high enough altitudes. Only very powerful surface injections have long lasting stratospheric effects.

The vast majority of existing wiring is cat5e which 2.5gb is the max speed

While not a completely open experience, Microsoft does let you do a lot more on the newer consoles, e.g. https://www.howtogeek.com/703443/how-to-put-your-xbox-series...

This should be correct but it probably is less about the "animation being closer to real life" and more about the actual measurement method. A camera measuring at 24 fps is likely going to have exposure times closer to 1/24 and measure an average scene over that time instead of an instantaneous measurement. The oversampling method you suggest would correct for this.

We bundle DLLs in our wheels in such a way that it "just works" for the user but it kind of feels like a hack. First a main DLL library is built completely separately from the wheel. Then a binary wheel is built where the .pyd file basically just directly calls functions from the main DLL. The main DLL is then just manually included in the wheel during the build step. Any dependent DLLs can also be just manually included inside the wheel as well.

If you imagine every molecule in the crystal can be oriented randomly, then there is a very large number of possible global configurations that are equally likely and we say the crystal is "symmetric" with respect to these outcomes. If the orientations become ordered in some fashion as the article is saying we say the symmetry is broken.

Statistics canada provides a service similar to this https://www150.statcan.gc.ca/n1/pub/71-607-x/71-607-x2020015...

In terms of numerical computing I don't think this is going to be a battle of core language speed, Python has already lost here. The question is going to be what are the advantages of a language designed with a focus on number crunching vs a multi-purpose language with some number crunching extensions.

I mostly do scientific computing but I really enjoy the toolchain of an extremely popular multi-purpose programming language (Python) + C extensions where necessary for speed. The reason is that many tasks these days are not just pure number crunching. If I need to start up a quick web server, do some web site scraping, basically anything can be done easily from Python. It's unlikely Julia will ever be able to catch-up in these areas.

I have had this happen a few times too. I have found the best way to minimize this is to install nothing in the base environment except for conda and make sure you use a different environment for everything else.