Explained in the very first sentence, "This is the quarterly links ‘n’ updates post, a selection of things I’ve been reading and doing for the past few months."
I missed that sentence too. I guess the large heading starting with "(1)" drew my eyes first and felt like the natural place to start reading, while the short sentence or two above it in smaller text subconsciously felt skippable (and was skipped). Even when I went back to read the first sentence, I had to kind of force myself to read the stuff above the first large heading. How odd!
EDIT: ok this was nagging at me for a while as something being off, I think this is actually wrong (in some way that must cancel out to accidentally get the right answer) because I need to multiply by 2 pi c to consider all rotations of centers around (0,0) at a given radius, but then my integral no longer works. Ah well, that's what I get for trying to method act and solve quickly, I guess the hooligan stabs me. I think at least this approach done properly could save some dimensions out of the Jacobian we need to calculate. Original post below:
Much more elegant: consider every circle that fits inside the unit circle, and we will work backward to find combinations of points. We only need consider centers on the x axis by symmetry, so these are parameterized by circle center at (0,c) and radius r with 0<c<1 and 0<r<1-c. Each circle contributes (2 pi r)^3 volume of triples of points, and this double integral easily works out to 2 pi^3/5 which is the answer (after dividing by the volume of point triples in the unit circle, pi^3)
I think it's fairly straightforward to adapt your method. Given circle center c you just need to multiply by 2 pi c to get all the circles.
int 0..1 2 pi c int 0..(1-c) (2 pi r)^3 dr dc / pi^3
int 0..1 2 pi c int 0..(1-c) (2 r)^3 dr dc
int 0..1 2 pi c 2 (1-c)^4 dc
-4 pi int 0..1 (1-g) g^4 dg
4 pi (1/6 - 1/5)
4 pi / 30
2 pi/ 15
This result is out from the article by a factor of pi/3. This is the multiplicative difference between his inner integral with all the sins 24pi^2 and the GP's observation that 3 points on the chosen circle have density (2 pi r)^3 = 8pi^3 r^3.
(The article had already covered the r^3 in another part of the calculation.)
I'm trying to figure out an intuitive explanation as to why the work with the inner Jacobian is needed or an argument as to why it isn't.
Anyone want to simulate this accurately enough to distinguish between 40% and 41.9% probability? 5000 samples should be more than enough.
Sorry, this was incorrect. In this integral we're just calculating the geometrical question, what is is the 5d volume of the collection of 3 points whose circumcenter is on {(x, 0) : x in [0, 1]}. So the "overall" probability of the problem has nothing to do with it.
One can discuss what “choosing three points independently and uniformly at random from the interior of a unit circle” means, but whatever you pick, I don’t think that method is doing it.
Doesn’t it have half its circle centers have 0 < c < ½, while that covers only a quarter of the area of the unit circle?
The wiki page agrees with parent, "The double-sided, high-density 1.44 MB (actually 1440 KiB = 1.41 MiB or 1.47 MB) disk drive, which would become the most popular, first shipped in 1986"
The license seems perfectly clear in that it's multiply-licensed under AGPL, MIT, and corporate licensing based on different use cases. Maybe this guy has reading comprehension issues, but more likely he's just unhappy with the corporate part and wants to stir drama.
It does create confusion because adding extra clauses onto whether you can use the AGPL kind of defeats the point of the AGPL, and creates a contradiction because the different flavors of the GPL generally all have language that tries explicitly to prevent such a thing, which is a pretty classic piece of confusion (I've had it when negotiating employment contracts and it's shocking how many people seemingly just never read the documents they're offering).
(EDIT: though, having read the whole document, it seems like there is just a trademark carve-out, which is explicitly allowed under the AGPL, so this seems reasonably straightforward, except for the strange 'we promise not to enforce copyleft if you don't modify the code' which seems entirely redundant. Oh, and the 'licensed to use source code to create compiled version' which seems like a very strange phrasing)
You are licensed to use compiled versions of the Mattermost platform produced by Mattermost, Inc. under an MIT LICENSE
- See MIT-COMPILED-LICENSE.md included in compiled versions for details
You may be licensed to use source code to create compiled versions not produced by Mattermost, Inc. in one of two ways:
1. Under the Free Software Foundation’s GNU AGPL v3.0, subject to the exceptions outlined in this policy; or
2. Under a commercial license available from Mattermost, Inc. by contacting commercial@mattermost.com
"Subject to the exceptions" conflicts with the "no exceptions" wording in the GPL licenses, so I don't even see how any of this constitutes a valid license
I read the exceptions as a grant of additional rights to mattermost's copyright (but not to third parties), I don't think that conflicts.
I'm not sure that they actually granted a GPL license at all though. I could see this document being read as an advertisement that one might be for sale instead of a grant...
Licensing should never be left to "reading comprehension". If there is any doubt about the terms, a clarification should be requested. A clarification was requested here. The requested clarification was declined. If this matter was really so simple that simple "reading comprehension" would solve it, the project maintainers could have said so. But they didn't. And that they didn't holds more weightage than what some random stranger has to say about "reading comprehension".
... also some parts are Apache, and the wording around the AGPL bit is very weird:
> ... licensed to use source code to create compiled versions ...
Why's it calling out compiling specifically? Are they trying to imply you can't modify/distribute/etc the source? Presumably that would be a "further restriction" per the AGPL and hence ignorable, but it's sloppy at best and misleading at worse, which isn't great for a license document...
They didn't say you "might" be able to use it under the AGPL, but that you "may" be licensed to use it. Which, as a native speaker of American English, seems to be relatively clear in its meaning along the lines of what the GP poster stated. Of course, the various meanings of "may" in English might be subtle enough that I'd readily believe it's less clear to non-native speakers (or maybe even speakers of a different dialect), and it's unfortunate that Mattermost's lawyers aren't interesting in cleaning up the language.
I'm going to agree with the downvoted people and say that this sort of approach is largely meaningless if you allow arbitrary mappings. IMO the most reasonable mathematical formulation given the structure of the integers (in the sense of e.g. Peano) is that to truly represent an integer you have to represent zero and each other representable number has a representable predecessor, i.e. to say you can represent 5 you need 0,1,2,3,4, and 5 to be representable. By a straightforward counting argument, 2^64-1 is then the largest representable number, in other words the obvious thing is right.
As I've replies several times before, we don't allow arbitrary mappings.
We allow computable mappings but consider only obviously non-cheating languages like Turing machines
or lambda calculus or Linux's bc or any existing programming language, that are not geared toward outputting insanely large numbers.
It's not "the largest representable number" because you're not representing numbers in any rigorous sense. If I give you 64 bits, you can't tell me what number those bits represent (first, because the rules of the game are ambiguous - what if I give you 8 bytes that are a valid program in two different languages; and second, because even if you made the rules precise, you don't know which bitstrings correspond to programs that halt). And if I give you a number, you can't tell me which 64 bits represent that number or even if the number is representable, and that's true even for small numbers and even if I give you unbounded time.
It seems far more natural to say that you're representing programs rather than numbers. And you're asking, what is the largest finite output you can get from a program in today's programming languages that is 8 bytes or less. Which is also fun and interesting!
> If I give you 64 bits, you can't tell me what number those bits represent
You have to tell me the (non-cheating) programming language that the 64 bit program is written in as well.
> And you're asking, what is the largest finite output you can get from a program in today's programming languages that is 8 bytes or less.
That's what the post ends up saying, after first discussing conventional representations, and then explicitly widening the representations to programs in (non-cheating) languages.
I would say that all of those seem both arbitrary and geared toward outputting insanely large numbers (in the sense that the output of any Turing-complete language is). Now if you can make these claims in a mathematical rigorous way (i.e. without relying on a particular mapping like Turing Machines / Lambda Calculus, and without silly "up to a constant factor" cheats) then that would be more interesting.
Turing Machines and Lambda Calculus can only output insanely large numbers by building those numbers from scratch using their Turing completeness. So while lambda calculus can output something exceeding Loader's Number, it needs well over a thousand bits to do so. What I mean by "geared toward outputting insanely large numbers" is saying: I define a language in which the 1-bit program "0" outputs Loader's Number. That is obviously cheating.
There is unfortunately no mathematically rigorous way to define what is cheating, so it seems unreasonable to ask me for that.
In the spirit of floating points, I'd say posits offer an excellent insight into the trade-offs between precision and accuracy, while being meaningfully representative of a number system rather than some arbitrary functions.
reply