greysphere

One oddity of Lorentz invariance is that two non-parallel boosts decompose into a boost and spatial rotation.

I've never quite wrapped my head around this and was hoping to get some insight from this simulation. But afaict, I'm not seeing this effect (press W for a bit, the A for a bit and it's not obvious I'm at a different orientation - if I look down at the ground the gridlines are still axial).

I don't know if I'm misinterpreting the math, or the simulation, or maybe the simulation is doing something to 'correct' for this behavior so things are more natural, or something else. Does anyone have any insight?

It's pretty hard for someone to make something worth a billion dollars then sell it, because someone else could make the same thing and undercut you. We even have a word for the way around this: 'moat.' In the 2000s 'network effects' were the most common moat, and they seemed a little crappy but not outrightly evil. Now the most common scheme seems to be breaking law until your big enough for the rules to not apply. That's why people see it as cheating.

Thanks, yes I think we had some confusion on the foo() vs parse() and I was referring to foo().

But even for the parse() example, the issue is the aliasing rules (and not the alignment - though that could still be an issue depending on input!) Aliasing isn't even mentioned in the article. Instead the example presents this thing 'people do all the time' and identifies it 'UB' without even identifying the actual issue.

On its own I could forgive the former, making a precise example is tricky (particularly with alignment issues). But this is repeated: milliseconds() is characterized 'UB' because it's inputs could be outside the representable range. Again the function is not UB, the inputs can potentially trigger UB.

Then the function pointer example obfuscates the assignment (fine) with the call (ub). Despite the red herring statement 'NULL compares unequal to any object or function' as the example assigns a function _pointer_ which can be NULL. The honest example of the statement is:

    void foo() = NULL;

which won't even compile because it violates the thing that was just said (among other reasons). The UB is the call below and has nothing to do with equality with NULL.

The repeated pattern of say one thing, show an example that's 'reasonable' and implies that it's related to what was just said, and from that invalid relation conclude that everything is UB in C feels dishonest (particularly when it's so easy to talk about UB in C honestly because there is so much to be legitimately concerned about!)

I appreciate your and your advocacy about UB in C, and I think I agree with most of your points about it and they worth discussing. That's why the article itself is frustrating to me, we don't need to be tricksy when talking about UB, it's already tricky enough!

Maybe I'm misunderstanding. Here is what I'm trying to say.

"Accessing an object which is not correctly aligned" - this is UB

"As an example of this, take this code: ..." - this (code) is not UB.

Is this incorrect somehow?

You could interpret the second sentence as 'under the assumption of an unaligned pointer, let's look at what this seemingly innocuous (and correct) code does.'

But that's not what they did. They presented that code as if it's incorrect (following the whole premise of the article 'Everything in c is UB'). That's what the whole article does, they take a topic with real concerns, then present 'normal' code, and then imply the code is the issue (and therefore the language), not the premise.

You know what would be better, show an example that clearly shows the complete path for the premise to the issue. Ie show some code that generates an unaligned pointer and then uses it. Why did the author not do that? Surprise, because it's actually pretty hard to write code that's 'guaranteed' unaligned behavior.

    int foo[10];
    int *bar = (int *)(((int)&foo) + 1);

Is this unaligned access? You don't know because you don't know the size of int. (Not to mention it looks ridiculous. By only showing 'reasonable' code as the example, the article suppresses the common 'uh just don't do that' criticism.)

And in fact the ambiguity of alignments and sizes is the whole point - they are given the privilege/footgun of being undefined in c so that compilers are easier to write. It's very debatable if this was/is a good idea, but that's where the debate should be, not illusorily ascribed to derefing pointers.

If I'm misunderstanding, please let me know. Specifically, if you're claiming (1) either the literal code in the first box of the article is UB, or (2) please write some literal code that is UB in the vein of the first claim of the article. I think that would help me bridge the gap that we seem to be having.

The first example is dereferencing an integer pointer. That is a valid operation. Now if that pointer isn't valid (and being unaligned is one of many reasons it could be invalid) then calling the function with that invalid pointer will be UB.

An honest discussion would be something more like 'dereferencing pointers can lead to UB on invalid pointers. Here are N examples of that. Maybe avoid using pointers. Maybe consider how other languages avoid pointers. Maybe these shouldn't be UB and instead some other class of error.' And then even more honest discussion would present the upsides of having pointers and the upsides of having these errors be UB.

Instead, the article (and your comment) take this valid operation and presents it as invalid. Imagine you're a new programmer, you are just starting to wrap your head around pointers and you stumble across this article. You see the first example and it looks exactly what you would expect a dereference to look like. But the article claims it's wrong, and now you're confused. So you dig into the article more closely and are exposed to all these terms like UB, alignment, type coercion etc and come away more confused and scared and disinclined to understand pointers. This is classic FUD. This is a technique to manipulate, not educate.

Pointers have pros and cons. UB has pros and cons. Let's try to educate people about them.

The examples aren't really undefined behavior. They are examples that could become UB based on input/circumstances. Which if you are going to be that generous, every function call is UB because it could exceed stack space. Which is basically true in any language (up to the equivalent def of UB in that language). I feel like c has enough actual rough edges that deserve attention that sensationalism like this muddies folks attention (particularly novices) and can end up doing more harm than good.

Absolutely. Interestingly, if there's a paper and it's not typeset in LaTeX, I can't help but start predjudiced. "Is this a Word document? These are not serious people."

1) Because the people who contributed to the development of those other processes received fair market value for their work (for the most part). The vast majority of contributors to the process that made this logo have not been compensated for their work. This differential can lead to an ethical judgement about the process, which can transitively be applied to the logo made with the process, and the restaurant as a whole.

2) Some automated processes lower the quality of outcomes. Microwaving food might be a faster/cheaper way to cook, but customers might criticize the results.

3) Some processes can be viewed as having lower value compared to others, independent of result quality. This is particularly common in the art and service industries, for which the logo of a restaurant is very much at the intersection.

With the old way of doing things you could spend energy to reduce errors, and balance that against the entropy of you environment/new features/whatever at a rate appropriate for your problem.

It's not obvious if that's the case with llm based development. Of course you could 'use llms until things get crazy then stop' but that doesn't seem part of the zeitgeist.

Another interesting thing about the steam engine is much of science in the 1800s was dedicated to figuring out how steam engines actually worked to improve their efficiency. That may be similar for AI, or it may not!

We made an AlphaGo like implementation for the card game Dominion. Certainly not the same number of cards but similar complexity. I have high confidence the same techniques would work for mtg. In fact possibly better as mtg doesn't lend to large search depths. Though possibly worse as there is more hidden information (though that depends on if the format has open deck lists and/or how much of the meta is provided to or trained by the nn)

  (1712) Newcomen Engine
  (1776) Watt Engine
  (1807) Atomic theory of Gasses (Dalton)
  (1807) Concept of Energy (Young)
  (1824) Carnot Cycle
  (1834) Ideal Gas Law (Clayperon)
  (1845) Relationship between work and heat (Joule)
  (1840-60s) Laws of Thermodynamics (Carnot, Clausius, Kelvin)

For over a century, there were a group of people working on building, maintaining, repairing, refining and improving engines, called 'engineers', who had a very incomplete picture of the physical laws surrounding them. I would assume there were many explosions and other accidents along the way (as there continue to be).

The investment in the science of thermodynamics and the chemistry of fuels was largely motivated by the value of the steam engine, and the attempts to improve efficiencies allowing miniaturization, enabling locomotives and the railroad boom, and eventually automobiles and powered flight.

I think the era from say 1950..2020 has been a relatively unique period in history where science has been ahead of praxis (though folks in medicine or other fields might not have had that luxury). Recent advancements in AI preceding strong theoretical foundations might be a reversion to the mean.

And in fact, the first engines were developed without a robust understanding of the physics behind them. So, the original version of 'engineering' is more closely to the current practices surrounding AI than the modern reinterpretation the root comment demands.

Seems like it'd be relatively easy to allow one to 'smooth' their income over multiple years. Imagine paying 100 income at 40% tax year 1 and 0 income year 2. A scheme where you could retcon things to be 50, 50, each at say 30% for a 10k refund (or at least credit) seems very doable.

I don't understand how inflation and risk wouldn't/aren't priced in. You have $1000. You can: put it in your mattress, put it in 'safe' treasury bonds at inflation +a few percent, or yolo it in NVIDIA. Yes if bonds are returning less than inflation you don't buy them and that makes financing more expensive but it's not somehow unfair vs the other things you could do with capital.

Seems like return is roughly proportional to risk(1-tax)investment so changing tax should affect everything proportionally (barring cheating/avoiding the system in some way).