I think "reflect top to bottom" is intended to mean "swap top and button". A mirror reflects left, right, top and bottom perfectly. It's front and back that it swaps.

Someone saying that a mirror swaps left and right is comparing it to a photograph, and only because we, as bipedal creatures, really prefer to orient images of other humans with heads up.

Someone saying that a mirror is swapped left and right is because they rotated themselves 180 degrees about the vertical axis to face the vertically aligned mirror. If they used a horizontal axis instead, they would have swapped top and bottom. And if the mirror is horizontally mounted on the floor, anything goes. You'd probably say it swaps up and down, which is front and back from the mirror's point of view.

> It's front and back that it swaps.

This sub-thread is becoming unfairly more interesting than the main conversation at this point.

You know, I never thought about that.

This was my small "mind expansion moment" for today. Thanks!

The image you see in the mirror is a reflection of a human. Or, more precisely, a 2-dimensional projection of the frontal outer surface of a human.

One half of one dimension less than a human. But sure looks convincing on the surface.

Ethics is what people agree on. Not doing unnecessary harm is usually easily agreed on. Don't exploit people who know less it's also on the list. Doesn't mean we didn't learn something valuable from KZ camp experiments, we just don't think it outweighed the costs. And we don't like, or want to encourage, people who think it did.

There are very strict rules for scientific experiments _because_ we know that without them, just guided by "common sense" or "be reasonable", someone would get blinded by ambition or "the potential" and go further than the majority want to accept.

Anyone can "experiment" without it being an accepted scientific experiment. But then they're personally responsible for any and all bad outcomes. If you follow the rules and get the experiment pre-approved, you'll likely be covered by your employer's insurance and free from criminal liability . That's a very good incentive.

But people don’t agree on ethics. That’s the whole reason you have ethics boards. Otherwise the scientists wouldn’t need one since they already thought the same.

I agree there ought to be rules, but ethics is just a word to make things sound fair when it’s just an authoritative decision, often taking bad arguments (like religious ones or public misconceptions) unnecessarily into account.

Stressful on the body.

Odd hours, sitting too much, inhaling too many exhaust fumes, having people yell at you if _they're_ late.

Sounds like a fairly hard job.

Yes, taxi driving can be hard.

There are jobs stressful on the mind too - and some of them have very low "life expectancies".

RegExps is the way to tokenize, so it's not surpassing you can look for individual tokens using them.

It's parsing that's hard , for example when it needs to match up braces, or start and end tags, even if either is easily matched by a RegExp.

And you still need to be careful if the source you're looking in has any way to escape text or have different meanings for the same text. In source code, you should recognize comments and strings (and RegExp literals) so you don't match inside those. In HTML, you should recognize CDATA sections, including script elements. If they contain `<div`, it's not a tag.

That's is, your 99.9% is probably too damn high.

Models do not have assumptions. They have probabilities for what the next token should be. With enough context, in the context window and built into the model, that next token isn't completely random, it's correlated with something someone might choose to write.

But people write all kinds of crap manually. So far, the data people have been writing has tended to be denser around what people could agree on (there are many lies, but only one truth), so the model is more likely to go there.

If we start putting AI generated text into the training data, it's not clear what that means for the resulting model. It's already clear that some actors are trying to influence models by putting large amounts of content out there that agree with them.

Figuring out which content is safe to train from is the real problem for future model trainers.

LLMs to inspect:

- Simple robust syntax

> - One obvious way to do things

That always leads to more verbosity. Much syntactic sugar is a more specialized way to do a subset of a more general thing. Why have `a + b` when you could just write `a.add(b)`? Because it's easier to read. The general functionality needs to account for all cases, the specialized one can cut that down just the things that matter to a specific common use case.

- Static type checking

\<meme>Which one?\</meme>

That's a very, very deep can of worms. One could argue that of an LLM is generating the code, then the type system doesn't need to be understandable to humans, so throw in all the features you'd ever want and just have the LLM change the code if it's not valid. Unions of higher order generic functions, sure! Or one could argue that there should be minimal magic, because the LLM understands the language only by its source, so everything should be explicit. If the LLM can prove that something is sounds to the compiler, accept it. Give ways to give extra evidence of soundness, like declaring invariants and contacts.

- Purely functional encouraged, escape hatches for performance

"One obvious way to do things", except when you need two. Purely functional except when it matters.

Why doesn't performance always matter? (And how will an LLM know if it does?)

Being purely functional is nice for data, but not for data structures that are updated in place. If all you do is stream data from one DB query into another, then your mutable state is the database. Otherwise might as well accept that it's a multiparadigmatic language with both imperative, functional and OO features. Just like all the others.

- Inspect-able, testable, and reviewable in small pieces

Good modularity and abstraction. No global scope. Maybe something like dependency injection to decouple from dependencies? (That does not make code readable, though.)

- Something like formal predicates, preconditions, post-conditions, assertions, or effects typing

That! LLMs look at the source. The more explicit the source is, the less it has to infer from context or existing knowledge. If the LLM can create its own predicates, accepted by the static type/analysis system, to prove that it's code is sounds, that allows more flexibility than having to fit into any fixed type system. Do we want or need that flexibility? Maybe. Most LLM-generated code is directly inspired by existing idiomatic code in the same language. Some is translated from other languages, trying to match up idioms. Some is just blindly trying to make unit tests pass. We could end up with generated predicates tailored to specific unit tests, not the actual concept.

So the `+` is not _overloaded_, the `+` syntax is a shorthand for calling a method named `__add__` on the value of the first operand, with the value of the second operand as an argument . That is: `e1 + e2` is syntactic sugar for `e1.__add__(e2)`, no more and no less.

It's not "operator overloading" any more than two _different_ classes having a `length` property is "length overloading".

Using the term "operator overloading" to begin with is the error here.

I think the bigger problem here is that "overloading" is specifically about providing multiple functions with the same name that take different parameters. You cannot truly overload in python, partly because it is weakly typed, and mostly because function names are a key in attribute dictionaries and must be unique.

The article is showing function overriding, not overloading, which is just standard class inheritance stuff.

If + silently gets translated to adding 2 numbers or joining 2 strings that is operator overloading, no matter how it's done under the hood.

If python had you write e1.__add__(e2) Or S1.__join__(s2)

Then you would have 2 distinct operators, therefore no overloading.

Re classes.

Foo.len() and bar.len() are different. You can tell that when you are using them.

It's no different to I_add() and f_add() they are both different functions.

If you automatically called one of those depending on whether the arguments were floats or ints, that would be overloading.

I suppose you could take it further and say that it's overloading if you have different int sizes.

But then we don't really class that as overloading, which I suppose demonstrates that it isn't a very precise term so there isn't much point getting particularly pedantic about it.

Hyperbolic title is, unsurprisingly, misleading. At least the article follows the style consistently.

The "ghost cut" is a two-step text move. A perfectly fine operation to have, _because_ it's not the same as a cut operation followed by a single paste operation.

Cut can be used without paste, and paste can be used more than once. They're combinable primitive operations. Sometimes what you want isn't that combination. Someones it is. But claiming that they're _broken_ ... is not a sign of someone who's able to see past their own needs and preferences.

> paste can be used more than once

Not in Excel after you cut. Because there, cut & paste is seen as an atomic move, akin to what's described in the article.

Probably don't care.

I have no idea what "randoseru" means, or what kind of backpack it is. Looking it up, it seems to be a design that carries special meaning in Japan, and not really anywhere else. While other countries _may_ have similar designs, it's not something special to them.

Even if the emoji looked like a ranoseru backpack, it wouldn't mean anything to most people. If anything, the front pocket is more likely to be associated with a backpack used for school.