toth

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]

[1] https://en.cppreference.com/w/c/numeric/bit_manip.html [2] https://en.cppreference.com/w/cpp/numeric/popcount.html

I think you shared the wrong link. Based on a quick youtube search I think you meant this one

https://youtu.be/EL7Au1tzNxE

For pytorch the analogue is Named Tensors, but it's a provisional feature and not supported everywhere.

https://docs.pytorch.org/docs/stable/named_tensor.html

That seems uncharitable. I for one enjoy the tidbits he posts in is blog.

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.

[1] https://oeis.org/A003417 [2] https://oeis.org/A001203 [3] https://en.wikipedia.org/wiki/Leibniz_formula_for_%CF%80

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.

I can't understand how you reach your conclusion.

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 :)

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.

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

[1] https://en.wikipedia.org/wiki/Almost_integer

Very nice, didn't know about that one!

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)

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?

[1] https://en.wikipedia.org/wiki/Intelligence_quotient#Social_c...

Right, it's a limit at infinity

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

Ditto.

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

Is github copilot using GPT-4 or 3.5? I've tried to find out for sure but I can't seem to find the information anywhere

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.

It's true that you can always define notation to combine all equations you want into one. This means that, by itself, the observation that you can write Maxwell's equations as a single equation doesn't say anything very meaningful.

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.

Sorry, but gauge transformations do not (by construction) affect the physical fields at all. You cannot set E to 0, even at a point, with a gauge transformation.

The originally published equations were "20 or so" because one equation was written for each scalar component.

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.

You can make the electric field disappear by choosing the right gauge. Same goes for the magnetic field (can't make both disappear together though).

What? No you can't. The fields are invariant under gauge transformations.

Interesting, I guess that makes sense.

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.

Hmm, still doesn't seem feasible. Even if you only have 256 "relevant" states (which I think you'll agree is far less than what you need) then given a 32-bit input your state transition table is 2^32*256 = 1 Terabyte.

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.

I deleted two previous comments because I realized I misunderstood your proposal. I understand it better now, but I am still confused about something...

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

In general, median and mode are much harder than min/avg/max. You can't compute the former with constant memory in one pass (you can do approximate median, but not exact median).

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

s/JSON/string/

You don't need the look up table. All you are asked for is min/mean/max which can all be computed in one pass without storing the data. All you need is a hash table with 400 entries and 3 floats (running min, mean and max) and and int (count, for updating running mean). That's just 16 bytes, if you use 16 bytes for name of station you can fit everything under 16K.

IO will dominate the running time for this, and JSON parsing will be second.