a1369209993
Joined 13 years ago
Karma
3,448
Submissions
2,908
Member since
May 22
Recent submissions
Comment · 2 years ago
Comment · 2 years ago
$ units
You have: 25m2 / 2tau(700km)^2
You want: /billion
* 0.0040600751
/ 246.30086Comment · 2 years ago
> such that at least every sentence is on its own line
Yes, with the obvious possible exception of trivial/degenerate cases like "i++; j--;" in C or "This is a cat. That is a dog." in English.
> and every line break represents a semantic clause or sentence gap.
Specifically, it represents a maximally coarse semantic gap, drilling as shallowly down into subclauses as possible/practical.
> wrap/line break [can happen at ...] also a semantically valid intra-word line break.
Preferably only if that word would already be alone on its overly-long line. Eg:
# bad, breaks subordinate clause before superordinate
That sounds supercalifragilistic-
expialidocious.
# semantically valid, but ugly (a pathological case)
That sounds
supercalifragilisticexpialidocious.
# vertically larger, but probably fine
# (unless you're feeling incunabulum-y[0])
That sounds
supercalifragilistic-
expialidocious.
I've yet to see any evidence that really pathological cases exist. (As opposed to "I'm lazy and can't be arsed" cases, which I'm fairly explicitly not disputing.)
Comment · 2 years ago
Yes, exactly. Which means that, while the speed gains are real, they only apply in cases where your libc is dangerously defective.
Comment · 2 years ago
> given not-pathologically-short line length limits like 20 characters
Poor phrasing; 20 characters was meant as a example of a limit that is pathologically short.
Comment · 2 years ago
> Instead, I would prefer a soft semantic wrap
So would I, but...
> if a single semantic unit (be that a word, a clause, or whatever else) extends beyond, say, 80 characters, we keep it on the same line and let the editor/file viewer handle wrapping.
...the editor can't do that because it doesn't understand the semantics.
> that wrapping based on semantics is an orthogonal concept to hard and soft wrapping
Yes, that's why I've been saying "hard and/or soft [but in either case nonsemantic] wrapping".
> > > With semantic wrapping you put each sentence (or similar) on a new line [...] But if that sentence runs over e.g. 80 characters, [then...]
... You don't need to fall back on non-semantic wrapping, you can just just keep breaking it up into smaller and smaller semantically-meaningful pieces.
(You have to do that 'hard'-ly because the editor doesn't understand the semantics, but that's not "decid[ing] whether you're going to hard wrap or soft wrap", it's being forced to hard wrap as a implementation detail because that's what results in correct wrapping.)
It might not be worth the effort to do that, but you're never forced not to (given not-pathologically-short line length limits like 20 characters).
Comment · 2 years ago
> How should it be wrapped semantically?
I have no idea what the semantics of that word are, which is information that is required in order to properly semantically wrap it. (Inherently, since conveying such semantics is one of the major pointer of semantic wrapping.)
However, you included embedded control characters (C2 AD aka 'SOFT HYPHEN'; below replaced with '-') that encode less semantic information than is necessary for proper semantic wrapping, but not none:
Lopado-temacho-selacho-galeo-kranio-leipsano-drim-hypo-trimmato-silphio-karabo-melito-katakechy-meno-kichl-epi-kossypho-phatto-perister-alektryon-opte-kephallio-kigklo-peleio-lagoio-siraio-baphe-tragano-pterygon.
Web browsers use that information to do poor-quality semantic wrapping automatically - actual hard or soft[0] wrapping would produce something like:
Lopadotemachoselachogaleokranioleipsanod-
rimhypotrimmatosilphiokarabomelitokatake-
chymenokichlepikossyphophattoperisterale-
ktryonoptekephalliokigklopeleiolagoiosir-
aiobaphetraganopterygon.
Lopado-temacho-selacho-galeo-kranio-leipsano-d[BREAK]rim-hypo-trimmato-silphio-karabo-melito-katake[BREAK]chy-meno-kichl-epi-kossypho-phatto-perister-ale[BREAK]ktryon-opte-kephallio-kigklo-peleio-lagoio-sir[BREAK]aio-baphe-tragano-pterygon.
The fact that you included soft hyphens rather concedes the point that hard and soft[0] wrapping is incorrect[1].
0: Or rather, non-semantic, which is what we're actually arguing over. Technically, semantic wrapping is a subset of hard wrapping, but it's a specific subset that isn't what is expressed by just saying "hard wrapping". Kind of like how birds aren't what anyone means when they just say "dinosaurs".
1: Granted, to be fair, a lot of the time we just don't care. But (contra your original comment) we never need to resort to non-semantic wrapping; we just sometimes (often) decide to be lazy because it doesn't matter.
Comment · 2 years ago
> But if that sentence runs over e.g. 80 characters,
> you still need to decide
> whether you're going to hard wrap or soft wrap that sentence.
Comment · 2 years ago
> vitalik didn't credit him in his article
You mean this article?
https://vitalik.eth.limo/general/2021/06/18/verkle.html
> Verkle trees are still a new idea; they were first introduced by John Kuszmaul in this paper from 2018[link to [0]],
0: https://math.mit.edu/research/highschool/primes/materials/20...
Comment · 2 years ago
Of course, you also need to use solid gold audio cables, or you're just throwing away the extra precision via poor signal fidelity.
Comment · 2 years ago
Comment · 2 years ago
> There is no antimimetics division V2
"antimemetics".
Antimimetics is also a thing, and might be interesting to read about, but it's not the same thing.
Comment · 2 years ago
I hope to write code that warrants a description at least twice as scathing as this one. But, you know, on purpose; when I'm intentionally fucking with someone. (I don't know of Martin ever trying to claim that Clean Code was actually a parody or practical joke, though I'll admit I can't rule it out.)
Comment · 2 years ago
Evidently I should have been more explicit:
> > A much simpler[-and-more-nitpickable] version
Myhill uses a parlor trick to make his version continuously differentiable. It's a pretty good parlor trick, but it doesn't have much to do with computability.
Comment · 2 years ago
> The key detail here is that the bumps grow exponentially smaller
Pedantically, it's that the bumps grow exponentially narrower.
IIUC, a simpler (but more nitpickable) version would be f'(n+1/y) = [the fraction of n-state Turing machines that halt within y steps] (for positive integers n, and 0 elsewhere); then f is the integral of f'. The value of f(x) can be approximated arbitrarily well by running every floor(x)-state Turing machine for a large finite number of steps[2], but f'(x) is equal to Chaitin's constant[0] for n-state Turing machines over a strictly-positive-length[1] subinterval of [n,n+1).
A much simpler version is f'(x) = {-1 if x<0; +1 if x>0; Chaitin's constant if x=0}. f(x) = abs(x).
Basically, this isn't even a parlor trick. It's a nothing burger, disguised as something by means of a parlor trick.
0: https://en.wikipedia.org/wiki/Chaitin%27s_constant
1: And so strictly-containing-rational-numbers, although predicting which rational numbers is nontrivial.
2: The rounding error from assuming all machines that halt after y steps actually run forever scales as O(1/y) in the worst case.
Yes you can - that's just a existential type. I'm not sure what the syntax would be, but it could be somthing like:
(In practice (ie if your language doesn't support existential types) you might need to jump through hoops like: or whatever the language-appropriate equivalent is, but in that case your list will have been created with the same hoops, so it's a minor annoyance rather than a serious problem.)