> A human cannot describe said element, by definition.
That example doesn't work. Some numbers are describable but not computable, Chaitin's constant being the famous example: https://en.wikipedia.org/wiki/Chaitin%27s_constant
853 karma · joined June 8, 2011
That example doesn't work. Some numbers are describable but not computable, Chaitin's constant being the famous example: https://en.wikipedia.org/wiki/Chaitin%27s_constant
In other words, they want everyone to be forced to follow the same rules they were forced to follow 20 years ago.
I think the real issue this highlights -- which is something everyone knows and still everyone does -- is that people love to spread and discuss sensational stories, and no one likes to hear naysayers ruining the fun.
Look the discussion of the original story here in HN[1]. There's a comment by A_D_E_P_T way down in the discussion explaining why the paper is nonsense and pointing to one of the replies objecting to it mentioned in the article from this post. That comment was downvoted by HN readers. I know because it was greyed out when I upvoted it days ago.
So there's no knowledge silo -- us simple folk just want to discuss the newest breakthrough without looking too hard, because that spoils the fun.
Blue + red is magenta. Yellow would be red + green.
None of these results make much sense to me.
You might think this code would be fine if address 0 were mapped to RAM, but both gcc and clang know it's undefined behavior to use the null pointer like that, so they add "random code" that forces a processor exception.
To clarify, the undefined behavior here is that the sanitizer sees `free` trying to access memory outside the bounds of what was returned by `malloc`.
It's perfectly valid to compute the address of a struct just before memory pointed to by a pointer you have, as long as the result points to valid memory:
void not_free(void *p) {
struct header *h = (struct header *) (((char *)p) - sizeof(struct header));
// ...
}
That would make sense for someone with all the relevant context about this story. While I agree with you that "most other information [I] want to know could be researched online", that would take a lot of time (I can't read German) and energy which would be best spent learning about way more important stuff happening in the world right now.
I've often seen people criticize scientists for not engaging with crackpots, with the argument if what they're saying is really dumb it should be easy to show that. I see that as naive -- there's only so much time in the day, you can't disprove every crackpot, so pick your battles.
This case feels like the same thing -- it started with someone claiming that a journalist was jailed for sharing a meme, then I learned this is a complete distortion. So I assume I'm dealing with a crackpot (not you, but the person who made the original claim), and so I refuse to spend more energy on this.
And if I'm being honest, I'm only writing this reply because it doesn't feel good to read "assuming you can be intellectually honest" while engaging in what I assumed was a cordial exchange, so I can't help but defend myself -- which I think I'll stop now and just let go.
I can't help to notice how with just a little bit of context we've come from reacting to "A journalist in Germany was just sentenced to seven months for posting a meme" to deciding if a fine was disproportionate.
With all that, the only sensible answer I can give is that I don't know. It's useless to be outraged by something that might be a non-story.
It is, but see what the article has to say about that (translated with google translate):
> Among other things, they complain about the inappropriate severity of the justice system against an allegedly satirical statement. What is left unmentioned, however, is that the trial only took place because Bendels previously refused to pay a fine of 210 daily rates imposed by the same district court in November.
I know nothing about this person or this case, but it sounds like he has done this before and refused to pay a fine, so the court said "enough is enough" and sent him to prison.
> [...]
> What is left unmentioned, however, is that the trial only took place because Bendels previously refused to pay a fine of 210 daily rates imposed by the same district court in November.
So I don't see "sentenced to seven months for posting a meme of a politician where she holds up a sign saying 'I hate free speech'".
What I see is "mislead people into thinking the politician said something she did not, and then refused to pay the fine imposed by the court".
That's not true; PIX requires your bank to provide a way (called "MED"[1]) for you to request a reversal up to 80 (!) days after a transaction. It can only be used in case of fraud, and it may take up to 7 days for the bank to analyze the situation and deny/allow your request. If it's allowed, you'll get the money back in up to 4 days.
If the bank denies the request (i.e., if they conclude there was no fraud) you can always sue the transaction recipient; you'll have access to all necessary information since they must be registered with some financial institution to be able to receive a PIX transaction.
So it's not as easy as a credit card, but I think it's fair for a free payment service.
[1] in Portuguese: https://www.bcb.gov.br/meubc/faqs/p/o-que-e-e-como-funciona-...
I remember there was a lot of confusion when llvm started removing stores to read-only memory[1], some people got angry because it broke some kernel code (that only worked because being in a kernel the memory page wasn't actually marked as read-only) and thought it would break any code that cast away a `const`, which is very common and valid as long as it was gratuitously `const`, as you say.
[1] https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html#notew...
If you change `writable()` to receive a `const char *` (and then cast it to `char *` to write), then clang will be forced to compile it with a store (even though it sees you storing to a `const char *`) because it doesn't know if the function will be called with a pointer to actual read-only data or just a pointer to writable data that was gratuitously converted to `const`.
For example, clang started simply omitting writes to data it knows to be read-only (which is allowed because these writes are undefined behavior, so anything goes). See this example[1]: `writable()` will return "*ello", but `readonly()` will just return "hello" and not crash (note its assembly doesn't include a write).
The prefix of "diatonic" is "dia" ("through"), not "di" ("two"), but nobody really knows what exactly its origin (διάτονος, "diátonos") was supposed to mean[1]: it's probably either something like "through the tones" or "stretched out tones".
The second meaning is closer to the modern definition we have for diatonic: the 7 (out of 12) notes are selected to be as stretched out as possible in the octave, that is, each adjacent note is either 1 or 2 semitones apart, and the two 1-semitone-apart pairs are as far as possible from each other (note that the second requirement excludes e.g. the ascending melodic minor[2] from being considered diatonic, even though it has 7 notes).
What I mean to say is that the "problem" of undefined behavior does seem to be intentionally introduced by the authors of the standard, not an oversight.
For example, I just checked C99[1]: it says in many places "If <X>, the behavior is undefined". It also says in even more places "<X> is implementation-defined" (although from my cursory inspection, most -- but not all -- of these seem to be about the behavior of library functions, not the compiler per se).
So it seems to me that the standards writers were actually very particular about the difference between implementation-defined behavior and undefined behavior.
I don't know what else to say, other than to show again this full quote: "These editors aren't working on Macs, per se. They're working around them". The point is not that they're not using Macs, he knows they are.
What you're doing is like seeing the scene[1] from the Watchmen movie where a character in prison says "I'm not locked in here with you. You're locked in here with me", and then thinking "Wow, that character was totally wrong! Of course he was locked in there with them, he was in a prison!".
[1] warning: graphic violence: https://www.youtube.com/watch?v=d0-EuoBjkKI
I was simply clarifying "what's the point of the article". Your quote fragment ("These editors aren't working on Macs") makes it look like the article is saying something it's obviously not (as it's clear from the very next sentence).
Put another way, if Stiller's team was building this for Amazon or Netflix, would that be a Mac Mini on Richman’s desk, or an HP or Lenovo box? Why even use a Mac in this editing process at all, when other companies offer access to better GPUs anyway?
[...]
Sure, there's an Apple logo in the top-left corner (two, actually), but it feels superfluous, knowing that the software isn’t directly on the machine and it [could] just as easily be running on a Windows or Linux box a thousand miles away. There are way more efficient ways to do this, and Apple doesn't offer them. Instead it relies on cloud providers like MacStadium, or localized IT teams, to work around their convoluted rules around VMs.
The point of the article, and the full quote, is "These editors aren't working on Macs, per se. They're working around them".
A small suggestion for improvement: the labels of the black keys currently don't match their function according to the key signature. For example, in F major the black key between A and B should be called Bb, not A#.
My point (more generally) is that even though it looks reasonable to make indices start from 1 and offsets from 0, in practice these things can get mixed together. It's not reasonable to get people to use two different numbers for what they see as the same thing (because their use got mixed).
For example, in music we use numbers for the notes of a scale (G is the 5th of C, because in the C major scale: C=1, D=2, E=3, F=4, G=5, A=6, B=7). The numbers are clearly indices for the notes of the scale.
But we often think of stuff like: what's the 3rd of the 5th -- that is, get the note at the 5th position (G in our example) and then get the 3rd of that note (the 3rd of G is B). But note that B is the 7th of C major, not the 8th you'd get from adding 5 and 3.
The problem, of course, is that we ended up using the numbers as offsets, even though they started as indices.