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.
790 karma · joined November 7, 2014
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.
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]
[1] https://en.cppreference.com/w/c/numeric/bit_manip.html [2] https://en.cppreference.com/w/cpp/numeric/popcount.html
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.
[1] https://oeis.org/A003417 [2] https://oeis.org/A001203 [3] https://en.wikipedia.org/wiki/Leibniz_formula_for_%CF%80
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...
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"?
FYI, the reason you get these almost integers is related to the `n`s being Heegner numbers, see https://en.wikipedia.org/wiki/Heegner_number.
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`.
In a similar vein, Ramanujan famously proved that e^(sqrt(67) pi) is an integer.
And obviously exp(i pi) is an integer as well, but that's less fun.
(Note: only one of the above claims is correct)
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?
[1] https://en.wikipedia.org/wiki/Intelligence_quotient#Social_c...
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".
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
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.
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.
However, the notation that lets you do this in this specific case is very natural and not specific to Maxwell's equations. Differential forms are very natural objects in differential geometry, mathematicians would have likely introduced them and studied without inspiration from physics. The fact that Maxwell's equations are very simple in this natural geometrical language does say something meaningful about their nature and elegance, I think.
> Rewriting the equations in vector form reduces the number to the modern number.
And if you use the differential form or 4d tensor notation they get reduced to 1 equation. Of course, for a lot of practical problems this is not very useful and it's better to work with the 3d vector form.
> The variant with 4 equations is the simplified variant for vacuum, which is mostly useless, except for the purpose of studying the propagation of electromagnetic radiation in vacuum.
> Instead of learning a large number of simplified variants of the Maxwell equations with limited applicability, it would have been much better if a manual would present since the beginning the only complete variant that is always true, which must be in integral form, as initially published by Maxwell.
Here I have to strongly disagree. The version of Maxwell's equations that is fundamental and exactly correct [1] is the vacuum version. The ones with magnetization and displacement vectors are only approximations where you assume continuous materials that respond to fields in simple way. In truth, materials are made of atoms and are mostly vacuum: there is no actual displacement vector if you look close enough.
Also the vacuum Maxwell equations are useful in many scenarios. For instance, that's how you compute the energy levels of Hydrogen atom or how you derive QED. Also, you have to start from them to derive the macroscopic versions with magnetization and displacement that you seem to like.
[1] Well, up to non-linear quantum mechanic effects.
What? No you can't. The fields are invariant under gauge transformations.
Having a quick look at your code, couple of thoughts:
- You shouldn't bother with parsing and validating UTF-8. Just pretend it's ASCII. Non ASCII characters are only going to show up in the station name anyway, and all you are doing with it is hashing it and copying it.
- You are first chopping the file into line chunks and then parsing the line. You can do it it one go, just look at each character byte by byte until you hit a semicolon, and compute a running hash byte by byte. You can also parse the number into an int (ignoring decimal point) using custom code and be faster than the generic float parser.
- If instead of reading the file using standard library, you mmap it, should also speed things up a bit.You could shrink your input size to 2 bytes but then you can't work on a word at a time, and for a realistic number of relevant states your transition table is still way bigger than you can fit in even L3 cache.
Unless I am missing something very basic, this doesn't seem like a viable approach.
Your state machine would need at least 2*160,000 states (you need an extra bit to flag whether you have reached a newline in the last word and need to increment a counter or not), correct? And you are assuming the input is 4 bytes, so won't your transition table need (2^32)*2*160,000 ~ 10^15 entries (at least 3 bytes each)?
(Here there is a restricted range for the temperature with only 199 possible values (-99.9 to 99.9 with 0.1 increment) so you could do it constant memory, need something like 4*199 bytes per unique place name))
For the sum overflow is not an issue if you use 64-bit integers. Parse everything to integers in tenths of degree and even if all 1 billion rows are 99.9 temperature for same place name (worst possible casE), you are very far from overflowing.
IO will dominate the running time for this, and JSON parsing will be second.