flannelhead's comments

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!

Congratulations Fedora!

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.

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.

[0] https://en.wikipedia.org/wiki/Gravitational_lens#Explanation... [1] http://spiro.fisica.unipd.it/~antonell/schwarzschild/

Thank you!

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.

Thanks for the compliment and suggestion! The redshift would be interesting to do, I'll consider that.

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

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.

[0] http://rantonels.github.io/starless/

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.

Hello HN!

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.

[0] https://github.com/flannelhead/blackstar

[1] https://flannelhead.github.io/posts/2016-03-06-photons-and-b...

Are you using neomake by any chance? I might switch from syntastic as neomake seems to support the linters I need (mainly eslint and hlint).

Done. Thanks for the reminder.

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.

Otherwise the editor seems to work very nicely.

[0] https://en.wikipedia.org/wiki/Fixed_%28typeface%29

There's a variant of lodash with auto-currying and better argument ordering: https://github.com/lodash/lodash-fp

I haven't tried it, but it looks like it could basically replace Ramda (although I feel that Ramda might contain even more FP oriented functions).

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.

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).

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.