superbatfish

This is accurate and the parent commenter here seems to be echoing a common misconception. Either they are confused or they need to elaborate more to demonstrate that they have a valid complaint.

For instance, this would have been a valid complaint:

"Users who don't need free threading will now suffer a performance penalty for their single-threaded code."

That is true. But if you are currently using multiple threads, code that was correct before will still be correct in the free threaded build, and code that was incorrect before will still be incorrect.

When I read an article about Python optimizations, I typically expect to have significant objections. But this one was great, actually.

Implementing `pipe` would be fun, but I'll leave it as an exercise for the reader.

I like exercise:

https://gist.github.com/stuarteberg/6bcbe3feb7fba4dc2574a989...

On the other hand, the authors make plenty of other great points -- about the fact that LLMs can produce bullshit, can be inaccurate, can be used for deception and other harms, are now a huge challenge for education.

The fact that they make many good points makes it all the more disappointing that they would taint their credibility with sloppy assertions!

The author makes this assertion about LLMs rather casually:

They don’t engage in logical reasoning.

This is still a hotly debated question, but at this point the burden of proof is on the detractors. (To put it mildly, the famous "stochastic parrot" paper has not aged well.)

The claim above is certainly not something that should be stated as fact to a naive audience (i.e. the authors' intended audience in this case). Simply asserting it as they have done -- without acknowledging that many experts disagree -- undermines the authors' credibility to those who are less naive.

Honestly, this might be an unpopular opinion, but I'll just say it: Brainfuck is not a great programming language for production use-cases.

Gotta love the word “just” in that first paragraph.

The majority of the research money behind most (if not all) drugs, is spent well after academia’s contribution. Clinical trials are very costly, they usually fail, and yet they’re quite important!

Personally, I think I would, at least at first.

If someone without the necessary expertise chimes in with an unhelpful answer within minutes of a question being asked, then everyone who comes after must check their answer before deciding if the user still needs help.

But even worse, I think potential responders on StackOverflow may not read the question at all because it will be listed as already having an answer. It won’t be an accepted answer, sure. But it still disincentivizes attention to the question. (I know it certainly disincentivizes me when I go looking for SO questions to answer.)

If a question has gone unanswered for hours or days, then sure — offer whatever advice you’ve got. But before then, you’re just adding noise, and actually reducing the chances that the OP will get what they were looking for.

It think the parent's point here could be rephrased like this:

Copyright law treats "involved a human" vs. "involved a machine" as fundamentally different just because humans are special-cased, not due to any deeper reason. Just by fiat.

The law gives special consideration to humans "just because". Therefore, if one situation involves a human in a particular role and another situation involves a machine, then there is no useful analogy to be drawn -- as far as the law is concerned. Even if the analogy makes perfect sense to you and me, the law treats humans and machines as fundamentally different, so all bets are off.

There are at least two potential issues pertaining to copyright law here, and it's not clear which one you're asking about. That's why the responses you're getting here seem to be answering different questions.

1. Are the AI systems violating the copyright protections of the images they were trained on? If so, are users of such AI systems also in violation of those copyrights when they create works derived from those training images?

Answer: That's not yet settled.

2. If you make an image with an AI system, is your new image eligible for copyright protection, or is it ineligible due to the "human authorship requirement"?

Answer: The US Copyright Office recently wrote[1] that your work is eligible for copyright if you altered it afterwards in a meaningful way. Here's a quote:

When an AI technology determines the expressive elements of its output, the generated material is not the product of human authorship. As a result, that material is not protected by copyright and must be disclaimed in a registration application.

In other cases, however, a work containing AI-generated material will also contain sufficient human authorship to support a copyright claim. For example, a human may select or arrange AI-generated material in a sufficiently creative way that “the resulting work as a whole constitutes an original work of authorship.” Or an artist may modify material originally generated by AI technology to such a degree that the modifications meet the standard for copyright protection.

[1] https://www.federalregister.gov/documents/2023/03/16/2023-05...

You might already be advanced beyond high-level introductory material, but this short book chapter by Chris Lattner himself was a good read for me (a casual reader, not a compiler expert).

http://aosabook.org/en/llvm.html

The answer is that once you’re able to definitively recognize it in at least one form, you’ll start to recognize similar, not quite identical forms.

The sapling form is not quite the same as the vine form, which is not quite the same as the very thick hairy vine that it eventually transforms into. But once you know one, you can start to recognize the others due to at least some parts of the plant matching what you already know. And then the other parts of the plant, which you hadn’t previously recognized as being how poison ivy can look, are added to your personal visual memory, too.

I don’t know, it’s hard to explain. It’s like if you saw a chihuahua and a Great Dane, you might not recognize them as being the same species. But if you see enough dogs in between, eventually you’ll see that they have something in common.

I'm afraid you have it exactly backwards. The problem isn't that it doesn't work -- the problem is that it does work. And to the extent that it isn't perfect, well, it's still improving all the time. You cited a 3-year-old article reporting on data from up to eleven(!) years ago -- an eternity in this field. Not even worth reading at this point.

The racial bias issue is still important for now, but it's fast becoming irrelevant. We should be asking ourselves where our priorities lie even if bias weren't a concern.

The Systems 1 & 2 analogy has also been made by Emad Mostaque, (CEO of Stability AI). He probably wasn’t the first, I bet.

The Koyaanisqatsi cinematographer went on to become a director himself, and made the movie “Baraka” in the same style. IMHO, it’s even better.

Some people like granular comments, and some people only want high-level comments. I’ve long suspected that both camps are correct, because they’re using different languages.

A single line of Python data analysis code is often worth 20 lines of C++. If you would be willing to add one comment per 20 lines in C++, then nearly every line of your pandas gobbledygook is worth commenting.

Terse code is good, but that doesn’t necessarily mean the comments should be terse (or absent).

According to Dmitry Kobak, some details in these figures are merely convergence artifacts, and no longer produced when using more recent versions of UMAP.

https://twitter.com/hippopedoid/status/1318917878364672001?l...

He explicitly mentioned that path…

Matt Yglesias’s new podcast “Bad Takes” did an episode about this, covering some of the meta-issues (as you might imagine).

https://www.grid.news/story/podcasts/2022/09/30/bad-takes-ep...

This question wording is very unfortunate:

“Do you mind if your comment is made public?”

Many people will respond with the opposite answer they intend to convey. This is especially likely for non-native Engish speakers, but will also affect native speakers.

If you are willing to accept the various caveats that come with -ffast-math for your own library, then it looks like it's okay to use -ffast-math during compilation, but not during linking (because it links in crtfastmath.so, as the author points out).

Your own compiled library functions will use the optimizations, but won't force the weird FPU register modes on the rest of the process.

I'm a big fan of the logging module, but it can't solve the problem of silencing or redirecting noisy C extensions. For extensions which you control, maybe the ideal option would be to offer logging configuration, or callbacks, or even integration with Python's logging module. But for externally written extensions, your only option is lower-level manipulation of the relevant file handles. Python's sys.stdout and logging module are powerless in that scenario.

The redirect() method shown in this post only works for output that is written via the Python sys.stdout handle.

If your code links against C/C++ extensions that have internal printf calls, then you need something lower-level, which can intercept the data at the file handle.

There's a great solution for that on StackOverflow: https://stackoverflow.com/a/22434262/162094

As a variant of option 2, could one create a new tag at the pre-merge commit?

I don’t think knowing the “internals” is really necessary. I like git and use rebase frequently. But I know almost nothing about the internals.

To me, it’s just a convenient way to keep track of big stacks of patches. That’s enough to understand rebase and most other commands.

I agree: Many people have half-baked commit messages. And many erroneously assume that a PR is always a single atomic code change, rather than a sequence of pseudo-atomic changes.

As an industry, we should be nudging people away from those bad habits. Instead, the "squash merge" feature nudges them in the opposite direction. It disincentivizes careful commit commit messages and encourages general disregard for the commit log.

Collaboration requires good communication. For programmers, that means:

- writing clear code

- commenting your code

- documenting your code

- writing a clear summary in the PR description

- organizing your changes into cohesive, (mostly) self-contained, reviewable units -- expressed as independent commits in the version history

On that last point: The commit log is something worth curating, tending to it with the same care you would use for the other points.

Yes, PRs are often small and self-contained enough that it shouldn't be subdivided into multiple commits. But just as often, it's clearer to use multiple commits which can be reviewed in sequence, rather than in one big chunk.

In the latter case, it's incumbent on the PR author to present a logical, clean commit history. If you wrote four commits but two of them are inseparable, then squash those two before you submit the PR. Commit messages like "fix typo from last change" are completely unacceptable in a PR. That sort of thing is fine in your own repos, outside of any review process. But when sharing code with others? No way -- that's inconsiderate with others' time, and pollutes a valuable data stream (the commit log).

But hey, if there's a good chance that all your commits will be squashed anyway, then why bother curating your commit log at all?

Instead of letting bad commit messages slide and simply squashing them, we should gently insist that PR authors fix their commits on their end. Their next PR will be better for it.

In the past, I've been occasionally annoyed when my carefully crafted commit log was simply squashed by a PR. I had intended the commits to be reviewed one-by-one. And if a bug is discovered in one commit later on, it would be clear which lines ought to be reverted, and which should stay unchanged. All of that care gets thrown out by a squash. Grr...

From the headline, I thought this would be about github’s squash merges, which represent an extreme anti-pattern to any sane developer.

Yes, it’s I’ll-advised to keep one’s savings in cash, but a shockingly large number of people do it.[1]

It’s not surprising that some people would also choose to keep the money “safe” by keeping it with them when they travel.

The fact that it’s irrational is irrelevant. It’s quite common, and therefore this is a great example of abusive civil forfeiture. Corrupt cops have surely become aware that such behavior is commonplace. They’ve learned how to sniff out such victims and prey upon them.

I can’t think of a better example than this case.

[1] https://slate.com/business/2015/02/keeping-cash-at-home-way-...

If-statements are for the weak :-)

This uses numpy, but it's the shortest answer presented thus far.

    In [1]: from itertools import chain, zip_longest
       ...: import numpy as np
       ...:
       ...: def f(l):
       ...:     a = np.array([-np.inf, *l])
       ...:     up = a[:-1] <= a[1:]
       ...:
       ...:     pos = (up[1:] != up[:-1]).nonzero()[0]
       ...:     pos = [0, *(1+pos), len(l)]
       ...:
       ...:     up_runs = (l[x:y] for x,y in zip(pos[0::2], pos[1::2]))
       ...:     down_runs = (l[y-1:x-1:-1] for x,y in zip(pos[1::2], pos[2::2]))
       ...:
       ...:     pairs = zip_longest(up_runs, down_runs)
       ...:     return [*filter(None, chain(*pairs))]
       ...:
       ...: f([1, 2, 3, 2, 1, 4, 5, 6, 7])
    Out[1]: [[1, 2, 3], [1, 2], [4, 5, 6, 7]]

I agree with you in spirit. Having separate names is preferable to context-specific semantics for the []. In pandas, using [] alone is discouraged, in favor of using .loc or .iloc. But admittedly, that only partially improves the situation. Both accept multiple types (int vs int-list vs bool-list).

Last year, I had an in-person discussion with a numpy core developer in which I proposed adding pandas-like syntax to numpy, e.g. allowing the author to use:

a.boolmask[b == c]

(but maybe not so verbose).

A problem immediately arises: An array can have multiple axes, and each could be indexed with a different type within the same slicing call.

One idea might be to allow the author to explicitly wrap the arguments with some dummy class to make clear what types they’re using:

a[np.boolmask(b == c), d, np.intlist(e)]

(Again, perhaps choosing shorter names in practice.)

The idea would be that the wrapper merely “looks like” the thing it wraps, but contains an assertion to verify the type of the argument.

Anyway, I agree that notebooks (or REPLs in general) are great for verifying your assumptions about how little snippets will behave. But I think they would be useful even in a fully statically-typed compiled language, too.