Works really well even on my old-ish smartphone (2014). WebGL is really interesting, too bad I still have yet to find the time to get a grasp of it. But blog posts like this are very inspiring!
Everyone is praising the GNOME (default) edition. Does anyone use the KDE spin? Also, how are Fedora version upgrades nowadays? I'm trying to decide between KDE neon and Fedora.
I would stick with KDE neon unless there is something that you cant live without in Fedora. The KDE developers and enthusiasts seem to be rallying around KDE neon so it's only going to get better and it has a hybrid rolling release model which is nice.
I upgraded from Fedora 25 to 26 alpha a few months ago and even then the process was smooth and the resulting system stable.
Haven't tried the KDE spin but I did try KDE neon briefly earlier this year. Quite slick but I quickly ran into broken package dependencies when trying to install some random stuff I needed (QGIS and sqlitebrowser IIRC); apparently it's been an open bug since September last year [0]. Didn't leave me with a good first impression but I'm rooting for the project - KDE is fantastic these days.
KDE Neon is wonderful IMO.[0] I like the Ubuntu base but I never liked Kubuntu and I really didn't like Unity so I never used it much after they left Gnome 2.
[0]: but then again I always liked KDE except the 4.x series which was too experimental IMO.
That statement is indeed a bit vague. Let me elaborate:
In the process of deriving the said equations, an equation for the radial coordinate of the photon was achieved. This was identified with a classical, Newtonian system of one particle with unity mass. As the real, massless photon lives in four-dimensional spacetime and the said massive "test particle" lives in three-dimensional space, these systems just can't be dynamically the same (in spacetime, the massive particle would take a timelike curve).
To reword the statement, the derived "equation of motion" will yield the same trajectory in the spacelike components (x, y, z), but possibly with a different parametrization - in the classical system, we're integrating the equations of motion with respect to the time. However, this has nothing to do with the "coordinate time" of the four-vectors nor the proper time of the particle (for the photon, proper time doesn't even make sense).
Hope this helps! You could also see [0] for an alternative take on this derivation. I will try and clarify my article a bit as well.
Maybe in the future, and in small resolution. Right now the renderer doesn't have any animation functionality, but this is definitely something I've been considering.
I thought I would share this little writeup on a project I'm quite proud of. The code can be found on GitHub [0]. This article is mostly about the implementation of the simulation in Haskell. I've also written another article [1] on the physics of the simulation. It should be approachable even for those without any general relativity background.
One idea that you might think about adding is redshifting the light that comes off the accretion disk. If the light is monochromatic coming off the disk, then the areas of the disk closer to the horizon should look more red to a distant observer.
What's the physics behind the accretion disk and its look? I would have expected black holes to look more like the last few images where it's just a black hole distorting light around it. Is it just pure eye candy, or do black holes actually output a significant amount of light outside their event horizons?
My take on the accretion disk isn't very physically-based. It's really mostly meant as eye candy. However, the distortion (the form it takes) is physical and due to the Schwarzschild geometry.
The physical explanation of an accretion disk would be some matter that is orbiting the black hole and emitting radiation, so it makes some sense at least. https://en.wikipedia.org/wiki/Accretion_disk
Nice work! Did you consider using an RK method with fewer stages but "better" properties? I'm thinking in particular of symplectic methods like velocity Verlet. Depending on the details, it could give you both speedup and improved accuracy.
A comparison between different integrators is in the plans. It would be certainly interesting to try e.g. velocity Verlet and some other symplectic integrators.
Any suggestions to fake the appearance? Think of distorting background images, for 2d video game purposes. And it doesn't have to be very accurate, just a general resemblance.
At least there's a simple equation [0] for the deflection of light rays caused by a black hole. If your background is a UV map (for example), then it should be easy to compute the distortion effect. rantonels (whose raytracer was the source of inspiration for mine) has done a realtime version [1] -- I believe this should be close to what you're talking about.
Funny how the X11 "Fixed" bitmap font [0] is chosen as the default font on my system. This appears to be caused by 'fixed' being set as a fallback font instead of 'monospace', which, on most systems, is an alias for the default monospace font which is usually an antialiased one.
After a little bit of use, I feel like lodash-fp is limited by being a simple adaptation of lodash. Lodash's API is designed around variadic functions, which doesn't really work with autocurrying, so a bunch of important options and functionality is lost. On the other hand, working with Ramda makes me miss some of the flexibility of lodash - e.g., not having to use a different map() for arrays and objects.
The optimal functional utility library would be designed with autocurrying in mind from the start, but not shy away from flexibility where it makes sense.
prelude-ls really shines when combined with LiveScript - syntactic support for partial application, currying, function composition, "pipelining" (|>), implicit arguments and so much more really make a difference.
That being said, I'm very interested in mori, immutable-js or lz.js. prelude-ls is nice, but is designed to work with native JS types and provides no extended semantics that I'd find useful. It's still my go-to library when working on the frontend and it probably will remain one, but I'm thinking about contributing some support for other advanced collection types to it.
I'm a physics sophomore, and I would be very glad to see more programming, especially FP, integrated to physics courses. During my studies, I've programmed some simulations related to the physics courses I've taken. My main purpose has been to gain a deeper, more practical insight on the subject which would've otherwise remained quite theoretical and distant.
For example, I made a little rollercoaster simulation to demonstrate the power of Lagrangian mechanics and generalized coordinates to myself. On the electrodynamics course I programmed a solver for Poisson's equation using the finite difference method to see a little more than the few simple geometries we calculated by hand. That kind of voluntary activities have greatly motivated me and helped me to understand various concepts.
On some courses we already have some simulation work and numerics in homework problems. Maybe deeper integration of programming into teaching requires time and, more importantly, a driving force and resources behind it. Then, of course, not everyone would be happy to see that kind of integration – I'm sure some would feel like they're forced to learn to program. And, as it has been seen on our entry level numerical physics course, learning programming, numerics and physics the same time is really quite hard.
Given those shortcomings, I still feel this is the way to go for future physics education. A gentle introduction and slowly teaching programming alongside physics would be the key, I think.
Have a look at the Matter & Interactions textbook by Chabay and Sherwood. It's a really cool concept for a first-year physics course, and it incorporates a lot of programming (and even just programming-inspired perspectives). (The authors use the "VPython" programming package for easy creation of 3D simulations.)
Your activities sound useful and worthwhile. A comment on this:
And, as it has been seen on our entry level numerical physics course, learning programming, numerics and physics the same time is really quite hard.
Yeah. My feeling is that the numerical side of things is a lock to get short shrift in this type of course. In my own education, there were certainly lots of nods at numerical work, but they really undersold the subtle difficulties of doing numerics well.
Very nice simulation you've got there! I also did a triple pendulum in JS a while ago. Quite a lot more than 100 lines of code, though. The equations of motion alone take up lots and again lots of space. (Imagine typing them in! I don't even dare to think about adding a fourth degree of freedom) http://users.jyu.fi/~samakapa/triplependulum/
My dynamics course teacher actually showed that the double pendulum can be linearized by some approximations (throwing out some negligible terms, small angle approximations etc.), and that way two modes of oscillation could be found: antisymmetric and symmetric oscillation. Just try with small initial angles with OP's script and you'll see.
First mass counting from which end? The masses are accelerated by each other as there are rigid rods between them.
The lack of friction and the perfectly rigid coupling between the joints might be what makes it seem lacking reality. If we'd extend the chain with more links, the motion of the outermost mass would become more and more unpredictable due to extreme acceleration.
Of course I might have made a mistake somewhere, but I checked that energy is conserved between the frames of the animation (excluding minor energy drift due to the numerical integration).
