752 karma · joined December 22, 2015
Red alert. You basically just wrote “I should quit tomorrow”.
This reminds me of http://penrose.ink/siggraph20.html as well.
I have massive respect for those who bravely tackle the frontiers of Physics; some physics majors have a broader understanding of Math than a mathematician! Though importantly, your average mathematician will have a much deeper understanding of more focused topics.
I don’t mean to suggest that any of Math, Physics, CompSci, etc is fundamentally harder than the others. Each field presents different challenges! But they are also intimately related IMO: the recent MIP*=RE proof has convinced me. In short, we’re all on the same side.
Really eye opening stuff! I am still impressed that prefix sum (generalized over all associative operators, not just +) can be done in O(log n) span. And the algorithm is not too complicated either, I was able to get the gist of it even as an undergrad.
The figures on the slides are really great. Hope this helps:
Fascinating. Is this why you posted this, OP?
Modloaders like Forge are platforms for mod installation because they overwrite the class files, and instead modders would add class files that don’t conflict instead (these days it might patch in code via Reflection, so things might be slightly different, but the fundamental process is the same). Furthermore I believe Mojang has started releasing debug symbols for Minecraft so the decompilation is no longer 100%. community driven as it used to be.
Fundamentally though, Forge is really doing the same thing. My point is that without the ability to easily decompile and patch in code, Minecraft modding would not be nearly as easy to do and platforms like Forge wouldn’t exist
I used to be a MC Modder back in the Beta, and at peak my mod had order 50000+ users, so I have some idea what I’m talking about. Admittedly I didn’t use a Mod loader at this time though.
Here's the first video uploaded by Notch when he first embarked on a new "Cave game": https://www.youtube.com/watch?v=UMpv5kZ9-rE (the original video is blocked in the US for some reason)
An interesting side-effect of this technical decision was that the game was heavily moddable. Java byte code is relatively easy to decompile, and class files easily modularize the various components of the game. So installing a mod amounted to un-zipping the minecraft.jar file and replacing .class files with modded ones. In fact, this is still how modding works in the Java version of the game.
That all being said, I still agree with you. I really don't care how much money Nintendo, Microsoft, or Sony wants to make on decades-old games, at a certain point it becomes a cultural artifact. Snow White and other century-old movie properties should be public domain nowadays as well. At this point we're debating about the core values of trademark law though, and I'm not sure you wanted to do that.
A similar debate revolves around what the law should say about "dead" games. These are games that, for example, rely on a central server that has been shut down. Many of these games were incredibly popular in their day, and some "radicals" (like myself, lol) argue that game companies should be compelled to release the server source code in an effort to preserve the game. Here's a great overview/rant on this topic: https://www.youtube.com/watch?v=tUAX0gnZ3Nw
My father and I both have it, and it felt great when I told him about it. He was as surprised as I was that it didn't happen to everyone! In a weird way I'm grateful for it, as I'm sure the reflex urged me to stay inside and cultivate my love for computing :). It's too bad it made me dislike the beach as a kid though -- these days I make sure to bring sunglasses.
"Moviefone, Worth 1% of Its Former Value, Is Being Run by One Employee After Parent Company’s Bankruptcy "
> In their first paper, the mathematicians focused on what happens during the mixing process to two points of black paint that begin the process right next to each other. They proved that the points follow chaotic paths and go off in their own directions. In other words, the nearby points can’t ever get stuck in a vortex that will keep them close forever.
> “The particles move together initially,” Blumenthal said, “but eventually they split apart and go in completely different directions.”
> In the second and third papers, they took a broader look at the mixing process. They proved that in a chaotic fluid, generally speaking, the black and white paint mixes as quickly as possible. This further established that the turbulent fluid doesn’t form the kinds of local imperfections (vortices) that would prevent the elegant global picture described by Batchelor’s law from being true.
> In these first three papers, the authors did the hard mathematics required to prove that the paint mixes in a thorough, chaotic fashion. In the fourth, they showed that in a fluid with those mixing properties, Batchelor’s law follows as a consequence.
So no, they are not "proving something by not being able to disprove it." A better way of phrasing their strategy is, "proving something by proving that disproving it is impossible."
In Computer Science, there is a similar concept for proving asymptotic bounds of algorithms called an "adversarial proof." The idea is, given some query that your algorithm performs (e.g. in a graph algorithm, a query could be "are two vertices connected") come up with a worst-case adversary that answers queries in the absolute worst way possible, that would necessitate even more queries to complete the problem. In this way, you can prove a universal lower bound for the cost of solving some problem. See [1].
In this case, the adversary is trying to come up with the worst-case initial conditions for this particular brand of turbulence. Basically they are saying, no matter what, you couldn't come up with an initial condition that challenges Batchelor's law more.
[1] https://www.cs.cmu.edu/afs/cs/academic/class/15451-s20/www/l... Section 3.2
> We figured we could tune the garbage collector to happen more often in order to prevent large spikes, so we implemented an endpoint on the service to change the garbage collector GC Percent on the fly. Unfortunately, no matter how we configured the GC percent nothing changed. How could that be? It turns out, it was because we were not allocating memory quickly enough for it to force garbage collection to happen more often.
As someone not too familiar with GC design, this seems like an absurd hack. That this 2-minute hardcoded limitation is not even configurable comes across as amateurish even. I have no experience with Go -- do people simply live with this and not talk about it?
> It is not just members of the community who wishes for “just two more features.” We have a committee with 300+ members. It seems that essentially every member has a feature or two that they’d like to get into the language, and many have several. I have not changed my opinion that adding too many features could “sink C++.” Remember the Vasa! [Vasa]. In fact, I think that the flood of new proposals has increased since I wrote [Vasa]. I think we are trying to do too much too fast. We can do much or do less fast. We cannot do both and maintain quality and coherence. We have to become more restrained and selective.
> Every design has advantages, disadvantages, and limitations. We should never present a design without a serious and honest discussion of possible problems and alternatives. It is part of a proposer’s job to examine problems; “pure sales jobs” are not intellectually honest. The joint “pro- and con-papers” on coroutines written by people from “opposing camps” were immensely useful ([Use][Impact]).
And later:
> Setting goals is usually far harder than the detailed design and implementation of features. We are good technicians and we have theory and existing practice to guide us with the necessary work once goals have been established. Unfortunately, we are not good at agreeing on goals and articulating them. Often, we end up in a mess of requirements. Language design is not product development. We don’t have a high management setting fundamental priorities for us. Few of us have workplace experience for that, if for no other reason that our firms are each in a specific business. I think product-development analogies have been seriously overdone over the last few years
The idea that traditional product design mentalities are insufficient for programming language design is very interesting. Indeed, a programming language’s design must answer to theoretical truths in addition to mere user feedback (this is a point brought up in the paper). It sounds obvious that in many ways C++ is not a “product” as it doesn’t have clients in the traditional sense. Where does the “language as product” analogy break down?