greysphere
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?
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!
"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.
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.
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.
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.
(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.
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).
Your statements seem to extend that further: If you rent an apartment, you the property is owned by an landlord (lord is literally in the title!) and passed down by their wishes. Similarly if you work for Walmart for life, the company is owned and passed down by the Waltons. In these cases the property rights extend beyond life and are transferred via circumstances of birth, while the rights of labor end.
Interesting that IP rights are ended by death (or death+n years) as well. This line of reasoning suggests maybe that should apply to all property.
The argument really isn't based on rights, it's based on the rules of the game have been that people that make things get to decide what folks get to do with those things via licensing agreements, except for a very small set of carve outs that everyone knew about when they made the thing. The argument is consent. The counter argument is one/all of ai training falls under one of those carve outs, and/or it's undefined so it should default to whatever anyone wants, and/or we should pass laws that change the rules. Most of these are just as logical as if someone invented resurrection tomorrow, then murder would no longer be a crime.
5. Fixing a bug means you have to go through a re review of your marketing assets that haven't changed in 3+ years and there's a non zero chance each time your review could result in _your app being removed from the storefront_ and losing _days_ of revenue after you appease whatever whimsical issue wasn't an issue the hundreds of times you've submitted previously and wait for the next review slot.
Looking further a redefinition E is necessary when including the \beta factor [2]. So that was a mistake on my part - relativity does change the rhs of Coulomb's law.
Admittedly the problem as stated (two particles falling towards each other) constrains things in such a way that there is no off-axis contribution. Or to put it another way, 1d electromagnetism doesn't have magnetism.
[1] https://physics.stackexchange.com/questions/142159/deriving-...
[2] https://en.wikipedia.org/wiki/Coulomb%27s_law#In_relativity
Sorry if this is a bit pedantic, but as someone trying to study this at the moment, I don't see this the same way and I'd like to validate my interpretation: You can just plug numbers into Coulomb's law, that part is correct. But then the problem of infinite velocities comes from interpreting the 'F' side of the equation, assuming Newton's law (F=ma), rather than using its relativistic counterpart.
Coulomb's law: F = qq'/r^2
Lorentz force law: F = q(E + mu x B)
For the 2 particle case, both of these say the same thing (substitute into the Lorentz eq E = q'/r^2, B = 0 and you get the same thing).
The promotion from non-relativistic to relativistic mechanics is a change of what 'F' means.
nonrelativistically: F = p' = m v' = m x'' = m a
relativistically: F = p' = \gamma m v' = \gamma m x'' = \gamma m a
where \gamma is the Lorentz factor.
Interpreted this way, infinite velocities are avoided.
But, as r->0 we still have an infinity problem - namely infinite energy! This necessitates a quantum mechanical correction to both the Coloumb and Lorentz laws.
TLDR: relativity is necessary when things start to move 'very fast', qm is necessary when things are 'very small'
I think it very much depends on your situation. I personally look to her as a role model who's demonstrated the value of strikes and collective action in influencing climate legislation.
Others might take inspiration in her criticisms of air transportation (something that seems to be growing in popularity these days) but I'm not able to give up seeing my aging parents across the country a few more times so that point hasn't reached me quite yet.
Her wikipedia page is worth 5 minutes if you can spare them and maybe go from there.
Frankly a question to ask is why you feel a person like her isn't encouraged to speak out on these issues, and isn't worth listening to? Is she saying things that aren't true? If so it seems like the thing to do would be to speak to those misstatements.
Much more likely though, systemic sexism and ageism make it difficult for folks to accept young women in leadership roles, particularly when their message asks for change from the status quo.
So the reasons you should care about what this person is saying are 1) she is speaking truths about climate change 2) the truths are about existential threats to humanity and she is able to communicate the seriousness of those threats 3) she is able to rally groups of like minded people with a common vision of those threats and their seriousness 4) paying attention to her and uplifting her leadership role helps erode systemic sexism and ageism.
I worked on the game, happy to answer any questions!
But even if you had a system, there's still the resource cost to run the algorithm (needs to be bounded or else you've just made a finite jump) and the gains you make need to not decay (or again you've just made a finite jump).
And all this needs to be compared against investing in humans - which seem pretty clearly to have AGI properties (but with some really bad constant factors. 20 year training time - ridiculous!)
To me it seems things are a long way off and least a couple of major innovations away. But at least there's some ideas of the problems to tackle, which is a big step up!
This characteristic is observable for metals as well. Steel becomes less flexible as it's worked because it's grains become smaller and more chaotic - A microscopic property with a macroscopic effect.
It's also often the correct choice for something like a collision partition for a physics sim where elements are most likely in the same sort position each frame.