Astronomical Calculations for Hard SF in Common Lisp | Hacker News Reader

Astronomical Calculations for Hard SF in Common Lisp

borretti.me

197 pointsvarjag42 comments

I also did some astronomical calculations and display for a hard science fiction book. In my case the book was "Project Hail Mary". I used Python, pandas, numpy, and matplotlib; I also converted all distances to light-years. See: "Project Hail Mary Stellar Map" at: https://dwheeler.com/essays/project-hail-mary-map.html

I also showed where these positions are on the board of the game "StarForce: Alpha Centauri". This game uses a map based on the real world positions of stars. See: "Project Hail Mary and StarForce: Alpha Centauri" https://dwheeler.com/essays/project-hail-mary-starforce.html

Code and data are posted as well.

It's my hope that doing these kinds of this will increase interest in both science and hard science fiction. I think those interests should be in a self-reinforcing loop.

>The simplest way to do this—without writing my own graphics code—is to use a 3D scatter plot. There aren’t any good plotting libraries for Common Lisp, so I used Python’s matplotlib, and used a CSV to transfer the data.

>Plotting is always tedious, but happily I was able to use ChatGPT to write most of the plotting code. I asked it to generate a simple example of a scatterplot with labeled points—that is, stars. Then I modified the presentation a bit, changing colours and font sizes, but the static plots have the problem that the perspective makes it hard to know where places really are.

>So I showed ChatGPT my plotting code, and asked it to rewrite it to create an animation where the entire plot is rotated about the vertical axis. It rewrote the script, preserving bit-for-bit identical output, and added animation support. I got an inscrutable error, showed it to ChatGPT, and it suggested a fix. I’m really happy with this approach.

Forget the turing test, conquering matplotlib is the real feat of machine intelligence.

And I really enjoyed the story, and the other one in the same universe:

https://borretti.me/fiction/maker-of-rivers

>This is the noocene: 10^30 immortal souls scattered over a billion stars, across a disk eight thousand light years in diameter. And a pantheon of some seven hundred gods, who have changed the face of nature. Most leave them a wide berth: the stars around Sadalmelik are not settled.

>And when gods die, grave-robbers flock to them and dig a quarry out of their bodies. This is the crew of the Epiphany: explorers who sift through the middens of collapsed civilizations and rob the graves of the gods, searching for beautiful things. This is the Epiphany: a treasure ship, laden to the gunwales with precious things from every world and every age, and the burial hoards of the gods.

> Forget the turing test, conquering matplotlib is the real feat of machine intelligence.

I truly actually laughed out loud here.

For folks who might be interested in astronomical calculations but who don't want to roll their own library, astropy (https://www.astropy.org/) is widely used by professional astronomers.

Excellent point. The unit conversions in OP are all in astropy, as well as projections into the many possible coordinate systems.

Another resource is the star/exoplanet catalogs at (https://exoplanetarchive.ipac.caltech.edu/docs/MissionStella...), see also (https://exoplanetarchive.ipac.caltech.edu/).

I actually wish the unit system was split off into a separate library. I use it occasionally in my data science work, but it feels kind of silly because I don't use pretty much anything else in the library.

You might find unyt useful: https://unyt.readthedocs.io

Disclaimer: I am the primary unyt maintainer.

Would be useful to add the standard units (SI units) from physics and for all quantities that can possibly be used.

Thanks, I might indeed!

The one thing I really like about the Astropy system is that it's built on PEP-593 annotations and Numpy, The former being effectively free and transparent at runtime, and the latter being a nearly universal standard for numerical and scientific computing.

The docs also reminded me of the existence of Pint, which is yet another standalone unit system that I keep forgetting to try. Do you have some kind of comparison document among Astropy, Pint, and Unyt? It would be helpful to have a sense of how Unyt differs from the others, otherwise my default behavior is to go with whatever is the most popular.

Maybe you'll find the paper I wrote describing unyt (https://joss.theoj.org/papers/10.21105/joss.00809) useful? unyt doesn't have type annotations so if you need that then it's not a good fit.

Python reigns on library support, and it is usually faster than implementing your own procedures, but I found out that when you are trying to solve a complex problem where you are both learning it and solving it simultaneously, having a repl like the one in common lisp really helps you get into the zone and deeply understand your software. Sometimes it makes sense to pays the price to implement a library just for this.

Isn't that what ipython is for ?

If you compare try to understand actually JavaScript has the most accessible (for normal mortal) on the state of the system. IPython you have to type and sort of print. Python on code might help as you can checkpoint and get some state during that checkpoint.

If there is no problem I am not sure lisp give that much (for our mortal).

Obviously when problem occur in unexpected place and suddenly the availability of the stack is great. And that is lisp winning.

Not sure for general understanding as usually you have a case in mind and want to trace the state. In that case still think JavaScript, Python with code, iPython for document still ok.

ipython can handle this situation fine, however, cl repl leaves ipython in the dust for more complex programs

also python is fine when all you are after is the end result. however if you try to understand what is going on at a deeper level in your program you will quickly discover that python is just a front end to some "black box" (how black it is will depend on your understanding of python's ffi, c, c++, fortran)

The reason to roll my own was: what I cannot create, I do not understand.

Love this philosophy

If you can, and also less dependence has less issue of security … but understanding great how about testing especially not use your use cases but others. That is a reason we still have Fortran. And for that matter lisp.

Also understanding for one is great and as a libertarian and conservative, yes. But real life not just individual. If one wor n in a group, understanding in a widely use langauage like Python may be important.

Key is not pure OR but and-and-sometimes-and-not.

well the OP made a blog post detailing his work so everyone else can follow, clearly not about the individual

Just wanted to thank you for the article! I really enjoyed it.

It has a cool backstory: travelling between stars at the speed of light using laers... it shows practical use of CLOS which is something I've always wanted to get into but never found the time... and it shows how ChatGPT can be very helpful to write tedious code (as someone who's written really tedious parsing, bit manipulation code, I will definitely look into using it for those cases).

Really recommended reading the whole thing for anyone just checking comments.

Surely, surely, for pathfinding in deep space, rather than Dijkstra, you should use the A Star algorithm?

Maybe if you're headed for the center of the galaxy...

Lisp-stat was recently rebuilt and has plotting https://lisp-stat.dev/docs/examples/plotting/

its just a wrapper around Vega, which is d3.js. also few things weird about this project, including name of company and license choice

For hard SF, you’ll want to check that your laser hops don’t pass close to the star your laser is orbiting or another star. For example, Gl 563.2A is part of a binary system (or is it? https://celestia.space/forum/viewtopic.php?f=2&t=2324), so service may be temporarily unavailable because Gl 563.2B interferes with transmission, and a different, slightly longer route may take less time.

Also, the hops presumably are between stars because that’s what the lasers take their energy from. If so, star brightness should be taken into account.

The relay's orbital inclination can be changed so the plane of the orbit is perpendicular to the direction of the target star, so there's always line of sight. I think coherent light would be distinguishable from background sunlight.

I vaguely recall some telescopes simply block out sunlight by having a black disk in the center of the aperture, and orienting the telescope so the sun is behind the disk, but I can't find the search term.

That isn’t guaranteed to work if the relay is used as a crossroads on multiple routes.

And I think you mean a coronagraph (https://en.wikipedia.org/wiki/Coronagraph: “a telescopic attachment designed to block out the direct light from a star so that nearby objects – which otherwise would be hidden in the star's bright glare – can be resolved.“).

I’m not sure using these to block out the sun is common with very sensitive instruments. Some parts of Hubble can’t look at the sun as doing so would damage them (https://en.wikipedia.org/wiki/Fine_guidance_sensor#Hubble_Sp...: “Due to the sensitivity of the FGS they can not be used whilst the HST is pointed within 50 degrees of the Sun.”)

Also, of course, blocking out the sun’s light won’t make you see the stars behind the sun.

This was a really interesting read, thanks! Is it correct that this doesn't take into account any relative motion of the stars, and instead assumes they are fixed points? I assume the relative velocities are not significant since they're pretty close together, but I'm curious if you investigated that.

The HYG database has the velocity vectors of the stars. These are calculated from proper motion (i.e. the star's movement across the celestial sphere) and radial velocity (measured spectroscopically, by the Doppler shift of the light).

In short (kiloyear) timescales, relative motion doesn't matter, because the stars move so slowly. For Beta Pictoris the velocity vectors are:

    $ cat hygdata_v3.csv | grep "Bet Pic" | cut -d "," -f21,22,23
    0.00000061,0.00001886,-0.00001106

0.00001886 parsecs/yr is ~20km/s. At this speed, it would take 10,000 years to travel a mere 0.6 light years. A rounding error.

On longer timescales, the velocity vectors are useless, because it's an n-body problem, and the initial conditions (position and velocity vectors) have massive error bars. Calculating accurate stellar positions in the far future is a task for a group of astronomy PhD's and is beyond my limited skills.

The story timeline is never stated, but it doesn't take place far enough into the future for stellar motion to matter---if you follow the clues you can bound it.

For the record, awk provides a more direct way to grab the results from the csv:

    $ awk -F, '/Bet Pic/{print $21","$22","$23}' hygdata_v3.csv
    0.00000061,0.00001886,-0.00001106

I thought lisp was supposed to be Uber functional. This code all looks very OO and imperative to me. It looks very intuitive.

It’s written in a very OCD style of coding, which I love. Definitely one of the most readable pieces of code I’ve seen in a while.

Lisp is composable. Everything is possible. Functional programming is one of many paradigms and many are common in it.

CLOS is an abstraction layer to enable OOP. It has long been a workhorse in industry. If a programmer wants something in lisp, he can make it.

The textbook sicp (not common lisp, but another dialect) involves building different interpreters to enable differing behavior. A lot of these are configurable or availible through libraries in common lisp. You have near infinite power with it! (Making a unique dsl for your specific problem case, e.g. with macros, is common with racket (my favorite lisp dialect.))

In the 80s and 90s when OOP was gestating and emerging, a lot of experiments and projects in thst direction were made in lisp (in production etc.) just as a lot of quantum computing research is done in lisp today. Indeed, in 1994 lisp became the first standardized OOP language. In the 60s, object modeling was first done - with lisp. The 70s already saw significant research in the area, before being used in industry in the 80s.

For functional only, you have to go to haskell.

The Wikipedia entry for this could legit be a book, it’s so detailed. https://en.m.wikipedia.org/wiki/Common_Lisp_Object_System

Lisp is not very functional at all.

This is Common Lisp, which is multi–paradigm on purpose. You can write purely function code if you want, or go completely object oriented, or just write in a very straight forward procedural style. There are benefits to all of them, so the language designers decided not to force people into any one style. Personally I prefer code that is mostly procedural with a fair amount of functional code mixed in.

I didn’t know that. Thank you for clarifying.

You’re welcome.

In Common Lisp you have the option of using CLOS which is a wonderfully flexible and customisable object system:

https://lispcookbook.github.io/cl-cookbook/clos.html

Reply on news.ycombinator.com