Skeime

Yes, and this is also a mistake, hence the <button> element.

Trying to shoehorn this onto the existing headings was a mistake. They should have introduced a new <h> or maybe <ha> (heading-automatic) element for this. Plus, support in the form of a CSS pseudoclass like :heading(n), which matches <hn> headings and <h> elements nested in n articles/sections/..., would have been great.

Essentially, it was hopeless to expect that designers would adapt their stylesheets to style headings based on the number of sections surrounding them. And if the visual styles don't adapt, nobody will use the outline algorithm to choose their headings.

(Which is sad, because the algorithm makes content nicely nestable. With the algorithm, I can take an article that was independent and use it as a section in a larger work, and the headings will automatically adapt. Though, as a pet-peeve of mine, nested IDs would also be somewhat necessary for this, so that it's fine to have two embedded articles which both have a section with an ID #introduction.)

I will also try to give some explanation:

The specification says that the syntax of expressions in this thing is `E ::= t | E E`. This is a bit confusing, because it might lead you to believe that all expressions just look like `t t t t t t t`. In reality, you are supposed to keep the implied bracketing, so expressions really look like `(t t) (t ((t t) (t t)))` (note that at the top level and in each parenthesis, there always exactly two subexpressions). Essentially, the space character becomes a binary operator (similar to how we often write multiplication with no symbol).

The expressions are a bit heavy on parentheses, so we say that this binary operator is left associative. This means that an expression `a b c` should be interpreted as `(a b) c`, an expression `a b c d` should be interpreted as `((a b) c) d`, and so on. If you think about it, this means that you can always get rid of an opening parenthesis at the left edge of an expression, i.e. we can assume that an expression always start without one.

With this out of the way, we can now understand where the trees come from: As there is only one terminal symbol, `t`, after removing unnecessary parentheses, every expression will always start with `t`, which is followed by a number of other expressions. To draw this as a tree, draw a node representing the initial `t`, and a sub-tree for each of the follow-up expressions (by applying the same procedure to them).

In this view, the semantic rules at the top of the specification page now tell you how to "simplify" a tree whenever there is a node with three or more sub-trees, or alternatively, how to reduce an expression that is a `t` followed by three or more sub-expressions. (In the syntax view, you replace the `t` and the first three expressions following it by whats on the right of the arrow. In the tree view, you replace the node and its first three children by some other sub-tree, then you attach the remaining children to the root of the new sub-tree.)

You always want to grab the Law.

I know that there used to be some oversights where things where missing from the Law (like how to distinguish immediate effects from permanent effects on cards based on whether the box is paper or stone) but all of them have been resolved by now.

You might want to look into wheels (https://en.wikipedia.org/wiki/Wheel_theory).

In analysis, you also use 0**0 = 1 all the time. It's the only sensible convention for power series.

It's really just a bit unfortunate that (x, y) -> x**y is not continuous at (0, 0).

I think they mean memorize. Most students simply lack the mathematical experience to internalize a definition correctly without simply memorizing it. They will forget an "only if", or accidentally swap two quantifiers around, or conflate two variables that need to be kept separate, etc.

This is okay! They're students on the way to gain that experience. At some point you can and will go over to internalizing, instead. But as advice to students just starting out, memorizing is the way to go.

For today's lucky 10,000: Ten Thousand (https://xkcd.com/1053/)

Yeah, it’s the same in Germany. (And to add insult to injury, people in places with renewable generation often pay higher grid fees due to the investments necessary to connect all the new plants.)

I have not once seen a formulae-as-images solution that I would consider acceptable, aesthetically. Common problems are:

- It almost impossible to align the baseline of the formula to the baseline of the surrounding text.

- Often, images are only used for "complex" formulae, while simple ones are implemented using normal typesetting. This resolves the baseline issue for simple formulae, but now the fonts between simple and complex formulae don't match. (This requires extra concentration for the reader, as in other contexts, different font styles are frequently used meaningfully.)

- The images often have sub-par resolution.

But the question here is not looking for a generator, because it would be okay if some group elements are only reached during the application of the sequence. (For the sequence to be a generator, all group elements need to be reached at the end of some full application of the sequence.)

The Hamiltonian cycle sequence from the original post is not a generator, but it visits every state. The question is: Is there a significantly shorter sequence that (when repeated) does the same?

Yes, but I definitely also see the opposite quite a bit: Somebody several layers down thought that something was an edge case, resolved it in a strange way, and now you have a chain of stuff above it dealing with the edge case because the bottom layer took a wrong turn.

The most common examples are empty collections: either disallowing them even though it would be possible to handle them, or making a strange choice like using vacuous falsity, i.e.

  all [] == False

(Just for illustration what I mean by "vacuous falsity", Python's all correctly returns True).

Now, every layer above has to special-case these as well, even if they would be a completely normal case otherwise.

The evaluation criteria don't need to be the same for your entire life. So if someone is taking an exam to decide whether they're fit to become a bridge engineer, ability should be the criterion. Little Johnny in school can still be evaluated based on effort. (In essence, over the course of the educational part of people's lives, slowly shift the criteria, and help them choose paths that will lead them to success.)

I believe that to learn well, you need to be challenged, but not too much. Ability-based evaluation only does that for students whose abilities happen to line up with the expected standard. It is bad both for gifted students and for struggling students.

You're right, I shouldn't have used cloning for the work part, though I rather meant closely replicating an artists style through the use of AI.

I think there is a significant difference between an AI "cloning" you versus an AI cloning your work. (I'm not saying that the latter is not a problem in need of regulation, just that it is different enough to warrant separate legislation -- which I expect to arrive soon-ish.)

The way I would do it: Get a board with a grid of 5x5 insets (like a Big Boggle board), a screen to hide it, 25 colored marbles (9 blue, 8 red, 1 black, 7 white), and a bag. Shake the marbles in the bag and empty it onto the board, shuffling it around until each marble is in a hole.

(Add another red marble if you want to alternate the starting team without switching their color and remove a red or blue marble each time.)

While I do agree that extensibility is vital for a general tool like this (and Markdown isn't), I also think that it is necessary to make certain concessions to standard elements (like paragraphs) in a text. I think TeX and Typst get this right, for example, and writing text is the default, with light-weight markup for paragraphs. Both of them then have ways to still switch into "structured" markup where desired.

Also, just offering the ability to introduce structure does not mean that it is done. For example, I could still write

    (p [I write this comment on August 1, 2024.])

So there is the question whether using something like Skribilo would really save us from having to heuristically extract dates from e-mail bodies in practice.

It is inconceivable to me that in a competently-run real election, you would not transfer actual vote tallies at any point in the (internal) process. This is true for intermediate results just like it is true for final results. If percentages are calculated at all, it is to gain insight into your local results.

(I volunteer at a polling station. We count the votes, and submit the raw counts to the next level. Then, we might do a quick calculation of the percentages, just to see how our voting district did. I can also go to my municipality's website and see the results of my polling station, and for the entire municipality. There are absolute numbers, which are reported to the next level, and the website also shows percentages, again, to gain insight into the municipality's results. Even if partial results are reported to the next level, this absolutely happens in the form of "these districts with this number of eligible voters have been counted; these are the absolute numbers".)

Everybody in the chain of responsibility should understand that the absolute numbers are what counts. And even if some people don't, the system must be set up in a way where you cannot transfer anything else. If there is even a serious possibility that someone might re-create voter counts from percentages, your system is a failure, and here it seems to have happened at the highest level.

And it is such a fantastic resource to learn! You want to get into puzzles like they do on the channel? Just open a video, pause it, and click the link in the description. Stare at the puzzle, trying to figure it out. The first time you do this, you probably won't. Once you lose patience (but give yourself some time!), watch the video until Simon or Mark get to the first deduction and explain it. Pause the video again, and try to continue using your new knowledge. When you get stuck again, what (or skim) through the video until they do enter a deduction that you have not found. Rinse and repeat.

Do this a couple of times with different videos, and you will start to build a repertoire of techniques yourself. At some point, you will be capable of solving puzzles on your own. (And if you get stuck, the video is there to help you.)

I think a tax or levy is somewhat reasonable, but then should go towards paying for sugar-induced costs (mostly healthcare, I'd assume).

No, not a typo. If you translated the two diagrams into classical notation, you’d get the two terms at the top of that page. They’re equal by naturality of alpha, but you need to concentrate on the formula a bit to see it. The great thing about string diagrams is that some of the inconsequential differences “vanish” into topologically identical diagrams.

That’s what I wanted to say as well. This might look and even be serious, but it’s still someone’s hobby project as well. They can do whatever they want.

"Serious" and "hobbyist" are not antonyms.

In Python, everything is a reference, so you don't need special syntax to mark them.

There just happen to be some types where you cannot change the referenced value in any way. These behave like value types in other languages.

(If you believe that they should be marked explicitly, do you also believe the same thing about Rust? I.e. should the Rust compiler throw an error if you never actually change a reference type, as you "should" be using a value type in that case?)

The distinction is needed, I think, unless you want to go the purely-functional route. I love that route, but just as many people will complain about purely functional languages being unintuitive.

If you want mutable values in your language, you need to expect values to mutate. So what should list multiplication do?

- There is the current implementation, where a change to the first entry of [f(x)] * 4 will be reflected in all entries of the list (because they're all references to the same value). - It could only work on list literals. So [f(x)] * 4 would call f four times and collect the values in a list. Then, a = [f(x)]; a * 4 would not work, which would be surprising. - It could work differently on list literals and lists. So [f(x)] * 4 would call f four times collecting the results, but a = [f(x)]; a * 4 would just return a list of four references to the one result of f(x). - It could copy the value in the list. How would you do that if the list contained values like file handlers or network connections that can't be copied?

Within the context of Python (an imperative language with mutable values), the current implementation is the most sensible one. If you work in such a language, you must always exercise some care when working with mutable values. Learn your tool!

Python could have been designed with different decisions. But who knows if we would even be talking about it today in that case?

Oh, that's a somewhat reasonable one. (Though I would expect that you actually want −(2 hours and 24 minutes) in many cases instead, thus needing to handle the negative case separately anyway.)

Sure, but the inexactness of this modulus operation would not be any more unpredictable than all other kinds of float inexactness. Unless you're talking about the case where you don't know whether your operands are ints or floats. But in that case, there are tons of other unpredictabilities. For example, a + b will round when adding (sufficiently large) integers-represented-as-floats while it will never round for integers. So if you take floating-point math seriously, knowing that you're actually dealing with floats is the first step.

This does something different. a // b tries to "fit" b into a as many times as possible. For example, 1.0 // 0.4 == 2.0 because 0.4 fits twice into 1.0 (with a remainder of 0.2). Though as the result should always be an integer, I'd argue that the result should actually be 2, not 2.0. But alas, it's not.

With your change, you calculate 1 // 0 instead, which crashes.

That said, I think checking isinstance(x, float) was always possible. (And nowadays, you can put a type annotation.)

There is math.floor for rounding towards negative infinity, which has the advantage of being crystal clear.

I mean "inexact results" is essentially float's life motto.

That said, I don't really see why you would necessarily want float and integer division to behave the same. They're completely different types used for completely different things. Pick the one that is appropriate for your use case.

(It seems like abs(a % b) <= abs(b / 2) might be the right choice for floats which is pretty clearly not what you want for integers. I also just learned that integer division // can be applied to floats in Python, but the result is not an integer, for some reason?)