It sounds like you're looking for problems in probability theory (rather than statistics). I don't have anything specific for you but you might have better luck searching for problems, puzzles, and examples in probability. For instance:
It has nothing to do with being easier to work with (at least, not in this day and age). The biggest reason is that minimizing sum of squares of residuals gives the maximum likelihood estimator if you assume that the error is iid normal.
If your model is different (y = Ax + b + e where the error e is not normal) then it could be that a different penalty function is more appropriate. In the real world, this is actually very often the case, because the error can be long-tailed. The power of 1 is sometimes used. Also common is the Huber loss function, which coincides with e^2 (residual squared) for small values of e but is linear for larger values. This has the effect of putting less weight on outliers: it is "robust".
In principle, if you knew the distribution of the noise/error, you could calculate the correct penalty function to give the maximum likelihood estimate. More on this (with explicit formulas) in Boyd and Vandenberghe's "Convex Optimization" (freely available on their website), pp. 352-353.
Edit: I remembered another reason. Least squares fits are also popular because they are what is required for ANOVA, a very old and still-popular methodology for breaking down variance into components (this is what people refer to when they say things like "75% of the variance is due to <predictor>"). ANOVA is fundamentally based on the pythagorean theorem, which lives in Euclidean geometry and requires squares. So as I understand it ANOVA demands that you do a least-squares fit, even if it's not really appropriate for the situation.
We have no evidence that the lead in solder makes its way into the body of the person doing the soldering (and we've been at this for quite some time!). The concerns about lead in solder are due to the environmental hazards of electronics waste, and the hazards associated with mining and smelting lead.
As everyone in this thread is sharing links, I'm gonna pitch in, too.
This lecture by Dennis Freeman from MIT 6.003 "Signals and Systems" gives an intuitive explanation of the connections between the four popular Fourier transforms (the Fourier transform, the discrete Fourier transform, the Fourier series, and the discrete-time Fourier transform):
The use-case is slightly different. Wavelets are suited for non-stationary signals, while Fourier Transform has no time localization so it's more for stationary signals. Although short-time Fourier transform exists, which can handle non-stationary signals under the assumption of local stationarity.
Also, a property of wavelets is they're non-parametric, which limits their utility in knowledge discovery applications.
For ML applications, my opinions is that they're somewhat superseded by deep learning methods that apply less restrictive inductive bias. As data grows, the restrictive prior assumptions of wavelets will hurt, sort of like how CNN is being abandoned for ViT, even though CNN can outperform in situations where data is scarce.
So overall, they have a pretty small set of usecases where they're more suited than other alternative tools.
How do you compute the fractional FT? My guess is by interpolating the DFT matrix (via matrix logarithm & exponential) -- is that right, or do you use some other method?
Yes the simplest way to think of it is to exponentiate the dft matrix to an exponent between 0 and 1 (1 being the classic dft).
But then the runtime complexity is O(n^2) (vector multiplied with precomputed matrix) or O(n^3) opposed to the O(n log n) of fast fourier transform.
There are tricks to do a fast fractional fourier transform by multiplying and convolving with a chirp signal. My implementation is in rust [1] compiled to web assembly, but it is based on the matlab of [2] who gladly answered all my mails asking many questions despite already being retired.
That's pretty neat. I wonder how it works. It's not obvious to me at all how to build something like this, as the program doesn't know the sequence in which the player will reveal the tiles.
I also once made my own variant of this (just like
gregfjohnson's idea): A "lucky minesweeper" where luck can be toggled on/off at any point during the game: https://github.com/yshklarov/minesweeper
For those who don't recognize the name: Linus Åkesson (lft) is the one who made "Nine", that C64 demo with the wizard and nine sprites that was popular a few months ago (https://news.ycombinator.com/item?id=42940553).
Apparently, this is a game that two can play. Niklaus Wirth, the creator of Pascal, had this to say in turn:
"From the point of view of software engineering, the rapid spread of C represented a great leap backward. It revealed that the community at large had hardly grasped the true meaning of the term “high-level language” which became an ill-understood buzzword."
Here is C.A.R Hoare's on his "The 1980 ACM Turing Award Lecture", guess to what programming language he is indirectly making a point of, regarding 1980 language designers and users have not learned this lesson.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
This is by no means unique to programming. Many areas of knowledge are less accessible to those who don't speak English, and much more so to those who don't speak any of the dozen major languages. Because of this, many people will simply learn (enough) English. It's not such a big deal.
In my view, having a single lingua franca is nice. It better facilitates knowledge transfer. I wouldn't want to see a fracturing where each area of knowledge (or, say, every specialization/application programming) is best treated in a distinct linguistic community. That would be bad for everyone.
I see your point - having a global language certainly helps with knowledge transfer, and English has become that standard for programming. But is learning English really 'not a big deal' for everyone? For someone with limited access to quality English education, it could take years before they’re comfortable enough to learn programming effectively. Meanwhile, a fluent English speaker can start coding right away.
Rather than fragmenting knowledge, what if we had a system that let people write and learn code in their native script, while still maintaining full compatibility with the existing programming ecosystem? Similar to how Unicode enables multiple languages on the web without breaking global communication. Do you think that could work?
Algol 68 offered that, for keywords at least. Variables, procedure names, and the contents of strings can't be localized quite the same way (though localization for content is easier now than it used to be if you don't embed the string text directly in the source).
If we switched from a text file based representation of code to a different structure, localization could be performed more easily for source code even down to comments and variables. However, this would help you to work on a project I started, taken too far it would not help us work together (we'd refer to the same variables and procedures with different names). We'd still need to select a common language when collaborating.
Other languages, today, at least work well with unicode source but they retain English-based keywords (Go, Rust, probably others but they like to tout it specifically).
Localizing everything could make collaboration harder if different people refer to the same function by different names.
But what if we had a system where people wrote code in their native script, and it automatically translated into a universal format when shared? Would that help keep things accessible while maintaining collaboration?
That's what I suggested, but it means our person-to-person collaboration becomes more challenging, though if we work at arms length with each other it might be more feasible. You always work in your translated code, I always work in mine. But direct communication about code breaks down because we need to have a translator and decide on the common terms.
We could probably collaborate at a higher level (system architecture and design). I'm building a compiler, I can share the architecture with you and have you implement a particular optimization pass. But if I want to read your optimization pass code and discuss it with you then one of us has to learn the same code twice: once in our native language and once in whatever is decided to be the shared language.
Store the code in a database (or something akin to one) and use a structured editor and this mode is technically feasible. It would open up work for people who are not native in the original language, but you also need to ensure that code has a translation. So you're still going to need someone (or something) to do the localization as well.
OSS projects can't afford this, but commercial efforts might be able to. On the other hand, commercial projects can afford to be the $2/hour extra (companies are cheap bastards) to hire those English speakers in your country and ignore the non-English speakers.
To nitpick with the grammar in the quote: It's capable of measuring to the accuracy of 120 μm at 1000 km. So it cannot accurately measure the diameter of a human hair (which ranges from around 20 to 200 μm) at that distance, but only to the accuracy of a human hair.
You're right: this precision is hundreds of times below the diffraction limit of even the James Webb telescope. It can't possibly measure the width of an object that finely; rather, only the relative displacement of its centroid position between two points in time. (And it's a seriously confusing physics miracle that that much is possible).
For point source astrometry, there are a few ways to beat the diffraction limit. For instance, some observers will purposely defocus their optics to spread the target photons over a larger number of pixels, which with sufficient SNR lets you gain a better lower bound (from a Cramer Rao perspective) on precision. I think Gaia actually does something similar to this but “blurs” through time, rather than across space, by purposely not perfectly tracking stars so that they drift at sub-pixel rates across the FPA.
https://math.stackexchange.com/questions/2140493/counterintu...