dfbrown

One of my big questions since the HuggingFace incident is whether OpenAI would have been so forthcoming (the independent METR report, the Black Hat talk, OpenAI’s own report) if the incident had been discovered internally and not publicly.

Not disclosing this despite apparently knowing for weeks makes me think they would not have, or would have concealed details, or delayed disclosure. Combine that with their technical missteps that led to this (weak sandboxes, very slow to detect the misbehavior) and I now strongly doubt OpenAI is capable of responsibly developing such potentially dangerous AI systems.

There are two separate things here, interpenetration due how contacts/constraints are solved, and whether you do continuous collision sub-stepping or not.

For stability and performance reasons physics engines usually have parameters that soften or add compliance to contacts/constraints. A bit of compliance is almost always better than infinitely stiff collisions/constraints. There are cases where infinitely stiff systems either have no solution, are very expensive to solve, or would produce very extreme impulses (causing things to explode). Including some compliance fixes these issues. It is also often required to produces more realistic looking results since objects in real life aren't infinitely stiff, they either flex or break.

For performance reasons most physics engines also do not completely solve their constraints. They either use a fixed number of iterations (most common, including the demos here) or solve up to some specified error threshold. This tends to add some additional compliance to complex scenes (stacks/piles of objects for example).

With the right parameters a good rigid body physics engine should be able to prevent noticeable interpenetration in most situations, though the performance cost may not be worth it. In these demos if you max out Position iterations, velocity iterations, and frequency you should see significantly less interpenetration.

As for continuous collision detection/sub-stepping, this is a very common feature to prevent fast moving objects from clipping into or tunneling through other objects. However resting/continuous contact cannot be handled by stepping to the next intersection time and so have to be handled differently. Also multiple simultaneous or near simultaneous collisions can grind things to a halt in degenerate cases (such as multiple stacked objects that are almost, but not quite in resting contact). This is why physics engines that support continuous collision usually let you set a maximum number of sub-steps.

All but two state's electoral votes are decided by the result of the popular vote in that state, congressional districts have no effect on that.

Local and proportional representation is the main reason for having the house of representatives, while the reason for Gerrymandering is to disproportionately favor one party or another.

No, ranges in C++ are analogous to the iterator trait in rust

C library public headers are commonly two levels deep to so that projects using them can add the "include" directory to their header search path and in their code have #include "<libname>/header.h". It helps avoid filename clashes.

I would try unrolling 2-4 iterations of the loop. Multiple sequential loads isn't much slower than a single load, so batching your loads and stores together will let you do more arithmetic operations for each time you hit memory.

Depending on the latitude sunset might be when people just start to get off work, or it might be well after dinner. Times have more semantic meaning than just the position of the sun.