MauranKilom

That completely ignores the second half of the article. I agree that it's confusing why the article goes into so much depth on "companies are now liable, similar to how everyone expects" in the first half when the main talking point is/should be "open source devs are now liable if consumers use their software directly" (as discussed in the second half).

Just dropping this here, because there is more to this issue in real-world scenarios:

https://loopit.dk/banding_in_games.pdf

(Not my talk, but I found it enlightening.)

A list comprehension: E.g. [x for y in z]

...it is also the plot device of the latest bond movie...

Not necessarily contradicting this, but even overcast days still have a high amount of sunlight outside. We don't really notice the difference to room lighting because our eyes have a very high dynamic range, but during the day (unless you live in the polar circle), the intensity of sunlight outside (and also the broadness of its spectrum) are much higher than any common indoor lighting.

From the twitter description it wasn't clear whether this was just a display bug or the device actually failing to record the user input.

I naively assumed it was just failing to display the decimal point. But no, going by the manufacturer statement, the actual value entered and used will ignore the decimal point. You still have to confirm the (correctly-displayed-incorrectly-received-value). If you don't pay attention (because the last 10 times it worked) you might just die... That's unbelievable.

Aside: This is reminding me of the relatively-orthogonal-but-still-awful-imo-UX where entering numbers into payment fields (e.g. card reader or PayPal app) just floods in the numbers from the right, with every digit passing through the decimal places as you type. I don't know why it irks me so much more than "normal" number entering, but it just feels so wrong. I'm entering a quantity in (e.g.) dollars, but I have to type it as a number of pennies. Normally, entering the decimal point would disambiguate my intent clearly even if I type too few or too many decimal zeros...

And, without looking that up, "halation" presumably comes from this being an artifact of the chemical process in early photography involving silver halides!

> he says there isn't persistent cheating

...in titled Tuesday, i.e. when there is a real-life name and chess career on the line.

This is a very terse note. Is there simply not more information available than "some price went negative on the market because someone made a mistake", or am I missing something that's implied here?

I don't use git at work, but in my private hobby projects my friends usually get mad when they watch me juggle changes and branch pointers with git reset --hard and git stash...

How do you undo a merge that you didn't mean to do/did wrongly?

    git reset --hard <last commit before merge>

Have some cosmetic fixups on your local branch that really should go into main (or a separate branch) first before merging a bigger feature?

    git stash
    git checkout main
    git stash apply

By thinking about branches as pointers, the commit graph existing independently, and stashes just being temporary commits, I feel I'm working much more directly with the underlying abstraction. Yes, git has commands for specific combinations of actions, but for an occasional user it's harder to remember every such command and which arguments and flags to pass in which order. It's either "look through documentation until you find graph diagrams illustrating what will happen for this order of arguments and flags" or "use the primitives 'move branch pointer', 'commit to branch', 'hold these changes for a second' for obtaining the commit tree you actually want. Knowing that the reflog exists also makes this insane-sounding working mode pretty non-scary. And yes, some operations (e.g. cherry-pick) you just need to do the "real" way.

(My git stash obsession is most likely just damage from years of using Perforce, which doesn't have a modified/staged distinction. The only way to commit only part of a changed file is via the equivalent of stash -> [restore half the file] -> commit -> stash pop.)

Prepares to be crucified...

I mean, without overthinking it: If your company focuses on making money, you are likely to keep your job/salary. Ideally there are also other concerns affecting this choice (like not creating something that may or may not destroy humanity), but that is less tangible.

Some basics (from someone who played the game a bunch a decade ago): There are two resources, metal and energy, neither can "mine out". To build something, you need equal amounts of both, and the thing building can only spend them at a certain rate ("buildpower"). Notably, metal income is effectively proportional to the amount of territory you control, whereas energy generation can be built anywhere. Buildpower is local to factories and builder units. Neither resource needs to be "moved around", it can be spent by builders anywhere.

One important economy management aspect is matching your metal income with at least as much energy income and buildpower so you can actually spend it (excess energy is turned into a bit of extra metal). And then yes, you should spend it, but the factories support queues (including automatic re-queueing), and you can of course shift-queue buildings.

Another important aspect is that dead units leave behind metal scraps. This can boost your metal income substantially (e.g. if a failed enemy attack leads to a bunch of dead units near your base).

In short, balancing metal income (/territory expansion) with energy income and buildpower is the core economy management loop. But because units have pretty capable AI (e.g. auto-kite when applicable), you can devote a lot more of your attention to this aspect, as well as higher-level decision making.

The point being made is that he could've just crashed his next own flight.

Engine fires.

Not exactly the same topic, but I feel like this is a good context to bring up https://extremelearning.com.au/unreasonable-effectiveness-of....

It provides (in some sense) maximally un-aliased parameter choices when trying to cover a (continuous) parameter space. It generalizes to arbitrary dimensions, doesn't require you to choose the number of samples/experiments beforehand, and actually expands trivially to parameters representing classes (including possibly weighting the classes).

I think it would be interesting to see how using this sequence fares in such a fractional factorial analysis, i.e. how close to optimal the (e.g. binarized) pseudorandom parameter choices are for different numbers of experiments!

Sorry, can you elaborate what or who you are replying to?

Be aware that there is no notification functionality. Most people you reply to will not see the replies, unless they frequently check their own comment history (where replies are shown in context) _and_ commented very little in the last two weeks (so that the comments you are replying to are still visible in the list).

So can you implement soft floating point math in soft integer math in floating point math?

Not completely objecting to this idea, but even in ideal scenarios with high-tech hardware and specialized setup, getting useful US image quality can be non-trivial and requires training and expertise. I can conceivably see that these are to some extent technical limitations that can be overcome for some level of mass-adoption. However, I don't see what use cases you have in mind that don't require a doctor for interpretation anyway (in which case having a professional device and the required expertise present in the facility is much simpler and cheaper than putting it in the hands of every patient).

But also, particularly for pets I believe anything with a non-negligible amount of fur or similar (i.e. anything that is not just bare skin) will be fundamentally impossible to achieve good enough acoustic coupling for. Unless you also sell shaving equipment with it. Anything with bone in the way (e.g. a ribcage with gaps smaller than a human one) is also more or less out.

For inanimate objects I really wonder what use cases you have in mind. Acoustic properties (and coupling) are even more of a variable there...

As a bystander this seems accurate, but at the end of the article Nate himself states that he has little hope that it will convince people on Twitter/X. It's more about credibility to his own readership, I suppose.

I actually initially also wrote "std::get and std::tuple_size", until I double-checked. :D

Is there a reason not to just handle/accept everything that has a valid `std::tuple_size` specialization?

Didn't check whether it hardcodes support for std::pair and std::tuple, but the "correct" way to do this is to rely on `std::tuple_size` and `std::tuple_element` for all tuple-like types. User types may well have these customizations defined already for e.g. structured binding support.

It's not that you couldn't do that, it's that polymorphism (in the interface/virtual functions sense) is only one of several paradigms for abstraction/code reuse in C++. And it is on the higher side of runtime cost among them.

Also, the type system in C++, despite all the template stuff, is not actually very good for serious functional programming. For example, when taking a function, there is no generic way to specify its signature in your own signature (and no, taking a std::function is not generic). `require` goes a long way though nowadays.

Assuming there is no material misrepresentation of how this system operates, I would find it hard to argue that it is disproportionate to keep record of an IP address that somehow makes publicly available a file with copyrighted contents.

I too would, from a pure self-interest perspective, like to share e.g. media with impunity, but for the sake of evaluating this opinion it's not reasonable to assume a position where copyright doesn't exist.

I'd be interested in arguments against this opinion.

Maybe I'm the only one, but... why?

What about by-hand-inlining `std::find` makes the code better?

> making the language "assigned at birth" inaccurate from a scientific standpoint

That's a strawman argument about semantics ("assign" in English does not always mean "soviet-style"), which I'm not going to bother engaging with.

> Scientific writing should not be a product of it's date and political climate.

By virtue of using language, it virtually always is. For example, the common/acceptable way of referring to ethnicities changed over time. It's virtually impossible in anything involving humans to have language (and therefore scientific language) not evolve over time.

> From a scientific standpoint, Female and Male are clearly defined.

And how do you distinguish the "scientific" female and male from the "colloquial" female and male, without leaving it ambiguous according to the "political background" of the reader? Or rather, what if, in a purely hypothetical future English, "female" and "male" refer unambiguously to the gender people identify as? It seems like you would like scientific writing to conform specifically (and only) to what you consider acceptable language _right now_, and are not actually particularly interested in accessibility to future readers.

> In scientific writing, such as studies like this - just the facts please.

But those are just very precise facts? Clarifying that they refer to "female sex assigned at birth" is strictly less ambiguous than "female".

Without trying to dismiss your opinion: Was the internet before Google/ad-tech not "open, free (as in beer)"?

Because it's most likely using a conditional move.

Given everything you said is true, under those assumptions 3% of those asteroids that we identify as being in said 2km box will hit earth, unless the forward simulation is wrong (implausible) or the measurement error distribution is substantially wrong (also seems unlikely).

What your analysis is not touching on is the prior probability that an asteroid will hit earth (you collapse this to "any asteroid will either hit or not", but that is not helpful for "model calibration" or whatever you want to call this) - or, equivalently, the prior probability of making (a series of) observations with a certain uncertainty/error distribution. If that prior were actually as uniform as each measurement error suggests, I don't see any Bayesian wiggle room left for why we don't have those 3% of impact actually happen.

(I'm no expert, but presumably you need multiple measurements to predict a trajectory, and while their measurement error distributions may be independent, it seems plausible to me that the prior probability of making two specific noise-affected observations, i.e. of the asteroid being on a certain trajectory, is most likely not so uniform. That's the part that I'd like to learn more about though.)