Maybe we are just quibbling over semantics but the compiler intrinsic here is '__builtin_popcount'. 'stdc_count_ones' is a standard library element that presumably will be implemented using the intrinsic.
And FWIW all major C/C++ have for a long time have had a an intrinsic for this. In clang it even has the same name, Visual Studio it's something like just '_popcount'. So it has long been easy to roll your own macro that works everywhere.
> An example you'll see in say a modern C compiler is that if you write the obvious loop to calculate how many bits are set in an int, the actual machine code on a brand new CPU should be a single population count instruction, C provides neither intrinsics (like Rust) not a dedicated "popcount" feature, so you can't write that but it's obviously what you want here and yup an optimising C compiler will do that.
C compilers definitely have intrinsics for this, for GCC for instance it is `__builtin_popcount`.
And apparently it has even standard language support for it since C23, it's `stdc_count_ones` [1] and in C++ you have `std::popcount` [2]
> In a different world, we settled on a system of notation based on continued
> fractions rather than decimals for writing non-integers. In this world, nobody
> marvels at the irregularity of pi or e, the fact that they seem to go on for
> ever without a pattern - both numbers have elegant and regular representations > as infinite sums of fractions.
There are some less widely-known topics in math that seem to make some of those that learn them want to "evangelize" about them and wish they had a more starring role. Continued fractions are one.
Now, don't get me wrong. Continued fractions are very cool, some of the associated results are very beautiful. More people should know about them. But they never will be a viable alternative to decimals. Computation is too hard with them for one.
Also, while e has a nice regular continued fraction expansion [1], that is not the case for pi [2]. There is no known formula for the terms, they are as irregular as the decimal digits. There are nice simple formulas for pi as infinite sums of fractions (simplest is probably [3]) but those are not continued fractions.
Well, actually... the "main" function is handled specially in the standard. It is the only one where the return type is not void and you don't need to explicitly return from it - if you do it, it is treated as if you returned 0.
(You will most definitely get a compiler error if you try this with any other function.)
You might say this is very silly, and you'd be right. But as quirks of C++ go it is one of the most benign ones. As usual it is there for backwards compatibility.
And, for what it's worth, the uber-bean counter didn't miss a bean here...
Those points are true of current AI models, but how sure are you they will remain true as technology evolves?
Maybe you believe that they will always stay true, that there's some ineffable human quality that will never be captured by AI and value creation will always be bottle-necked by humans. That would be nice.
But even if you still need humans in the loop, it's not clear how "democratizing" this would be. It might sound great if in a few years you and everyone else can run an AI on their laptop that is as a good as a great technical co-founder that never sleeps. But note that means that someone who owns a data-center can run the equivalent of the current entire technical staff of Google, Meta, and OpenAI combined. Doesn't sound like a very level playing field.
At present, if you have financial capital and need intellectual capital you need to find people willing to work for you and pay them a lot of money. With enough progress in AI you can get the intellectual capital from machines instead, for a lot less. What loses value is human intellectual capital. Financial capital just gained a lot of power, it can now substitute for intellectual capital.
Sure, you could pretend this means you'll be able to launch a startup without any employees, and so will everyone. But why wouldn't Sam Altman or whomever just start AI Ycombinator with hundreds of thousands of AI "founders"? Do you really think it would be more "democratic"?
Actually `e^(sqrt(n) pi)` is very close to being an integer for a couple of different `n`s, including 67 and 163. For 163 it's much closer to an integer, but for 67 you get something you can easily check in double precision floats is close to an integer, so I thought it worked better as a joke answer :)
Charitably it was a joke, as was my quip about `e^(sqrt(67) pi)`. It is a funnier joke without a disclaimer at the end, but unlike GP I couldn't bring myself to leave one out and potentially mislead some people...
What I meant was that I didn't know that `e^pi - pi` is another transcendental expression that is very close an integer. You might think this is just an uninteresting coincidence but there's some interesting mathematics around such "almost integers". Wikipedia has a quick overview [1]. I didn't realize it before, but they have GP's example and also the awesome `e + pi + e pi + e^pi + pi^e ~= 60`.
> Are you just being overawed by IQ tests, which are notorious for measuring only ability to pass IQ tests?
People like to say things like this, but nothing could be further than the truth. There is a vast literature showing that IQ predicts things like job performance, school performance, income and wealth [1]. IQ is highly persistent across time for fixed individuals. Yes, "intelligence" is not a precisely defined concept, but that doesn't mean that it isn't real. A lot of useful concepts have some vagueness about, even "height" to take the example parodied in the OP.
And "super intelligence" is admittedly even vaguer, it just means sufficiently smarter than humans. If you do have a problem with that presentation just think of specific capabilities a "super intelligence" would be expected to have. For instance, the ability to attain super-human performance in a game (e.g., chess or go) that it had never seen before. The ability to produce fully functional highly complex software from a natural language spec in instants. The ability to outperform any human at any white-collar job without being specifically trained for it.
Are you confident that a machine with all those capabilities are impossible?
You make a valid point, but I feel there is something in the direction the article is gesturing at...
The mean of the n-dimensional gaussian is an element of R^n, an unbounded space. There's no uninformed prior over this space, so there is always a choice of origin implicit in some way...
As you say, you can shrink towards any point and you get a valid James-Steiner estimator that is strictly better than the naive estimator. But if you send the point you are shrinking towards to infinity you get the naive estimator again. So it feels like the fact you are implicitly selecting a finite chunk of R^n around an origin plays a role in the paradox...
I think that ship has sailed, but I think it's unfortunate that "ReLU(x)" became a popular notation for "max(0,x)".
And using the name "rectified linear unit" for basically "positive part" seems like a parody, like insisting on calling water "dihydrogen monoxide".
To me it sounded like part of the problem is that people on ECMO cannot leave the ICU because at any moment they might have a complication that requires immediate emergency care.
So it's not enough to make them smaller and cheaper, they also have to be made much less prone to these complications. I am sure that will happen in time, but I am also sure we'll be able to grow people new lungs in time
I think matplotlib's main strength is its breadth and power. It really lets you do exactly what you want if you spend enough time fiddling and digging through the documentation.
All this versatility comes at the expense of ease of use. It could certainly do a better job of making the simple common use cases more straightforward.
gnuplot arguably has similar power and versatility and it does make the simple stuff easier.
One thing that matplotlib is IMO bad at is interactive plots. They are very slow, and the controls are not intuitive. 99% of the time you just want to zoom and pan and those should be default actions.
gnuplotlib looks interesting and I will have a look, but these days most of the plots I do are in jupyter notebooks and I really want inline interactive plots so I don't think I will use it much. FWIW, what I use currently is plotly - the interactivity is very good (way better than matplotlib's) and plotly.express is very easy to use for the simple use cases.
I agree that to fully specify electromagnetism you also need to include how the fields affect charged matter. So EM = Maxwell's equations + Lorentz force equation (not sure why you say there is no consensus about what this is, that is new to me).
This is just a matter of taste, but OTOH I would not include descriptions of how some materials respond to the fields in the continuous limit as part of a definition of EM.
It is true that for most terrestrial applications you do need those to do anything useful with EM. But if you want to study plasmas you need to add Navier-Stokes to EM, doesn't mean hydrodynamics is part of EM. To study charged black holes you need EM + GR, but it still makes sense to treat them as mostly separate theories.
And FWIW all major C/C++ have for a long time have had a an intrinsic for this. In clang it even has the same name, Visual Studio it's something like just '_popcount'. So it has long been easy to roll your own macro that works everywhere.