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.
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.
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.
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?
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.