# Planet Scheme

## Tuesday, October 4, 2022

### Scheme Requests for Implementation

#### SRFI 237: Reconciled Records

SRFI 237 is now in draft status.

This SRFI defines a version of the define-record-type definition of R6RS that extends the define-record-type syntax of R7RS, reconciling both systems.

This is a proposal for a future SRFI to be adopted by R7RS-large to integrate the R6RS record system compatibly with the existing R7RS-small record system.

## Sunday, October 2, 2022

### Jeremy Kun

#### Carnival of Mathematics #209

Welcome to the 209th Carnival of Mathematics!

209 has a few distinctions, including being the smallest number with 6 representations as a sum of 3 positive squares:

\begin{aligned}209 &= 1^2 + 8^2 + 12^2 \\ &= 2^2 + 3^2 + 14^2 \\ &= 2^2 + 6^2 + 13^2 \\ &= 3^2 + 10^2 + 10^2 \\ &= 4^2 + 7^2 + 12^2 \\ &= 8^2 + 8^2 + 9^2 \end{aligned}

As well as being the 43rd Ulam number, the number of partitions of 16 into relatively prime parts and the number of partitions of 63 into squares.

Be sure to submit fun math you find in October to the next carvinal host!

The Heidelberg Laureate forum took place, which featured lectures from renowned mathematicians and computer scientists, like Rob Tarjan and Avi Wigderson on the CS theory side, as well as a panel discussion on post-quantum cryptography with none other than Vint Cerf, Whitfield Diffie, and Adi Shamir. All the videos are on YouTube.

Tom Edgar, who is behind the Mathematical Visual Proofs YouTube channel, published a video (using manim) exploring for which $n$ it is possible to divide a disk into $n$ equal pieces using a straightedge and compass. It was based on a proof from Roger Nelsen’s and Claudi Alsina’s book, “Icons of Mathematics”.

The folks at Ganit Charcha also published a talk “Fascinating Facts About Pi” from a Pi Day 2022 celebration. The video includes a question that was new to me about interpreting subsequences of pi digits as indexes and doing reverse lookups until you find a loop.

Henry Segerman published two nice videos, including one on an illusion of a square and circle in the same shape, and a preview of a genus-2 holonomy maze (Augh, my wallet! I have both of his original holonomy mazes and my houseguests love playing with them!)

Steve Mould published a nice video about the Chladni figures used (or adapted) in the new Lord of the Rings TV series’ title sequence.

The Simons institute has been doing a workshop on graph limits, which aims to cover some of the theory about things like low-rank matrix completion, random graphs, and various models of networks. Their lectures are posted on their YouTube page.

Peter Rowlett shared a nice activity with his son about distinct colorings of a square divided into four triangular regions.

Krystal Guo showed off her approach to LiveTeX’ing lectures.

Tamás Görbe gave a nice thread about a function that enumerates all rational numbers exactly once.

Every math club leader should be called the Prime Minister.

In doing research for my book, I was writing a chapter on balanced incomplete block designs, and I found a few nice tidbits in threads (thread 1, thread 2). A few here: Latin squares were on Islamic amulets from the 1200’s. The entire back catalog of “The Mathematical Scientist” journal is available on Google Drive, and through it I found an old article describing the very first use of Latin squares for experimental design, in which a man ran an experiment on what crop was best to feed his sheep during the winter months in France in the 1800’s. Finally, I determined that NFL season scheduling is done via integer linear programming.

## Math Bloggers

Lúcás Meier published a nice article at the end of August (which I only discovered in September, it counts!) going over the details of his favorite cryptography paper “Unifying Zero-Knowledge Proofs of Knowledge”, by Ueli Maurer, which gives a single zero-knowledge protocol that generalizes Schnorr, Fiat-Shamir, and a few others for proving knowledge of logarithms and roots.

Ralph Levien published a blog post about how to efficiently draw a decent approximation to the curve parallel to a given cubic Bezier curve. He has a previous blog post about fitting cubic Beziers to data, and a variety of other interesting graphics-inspired math articles in between articles about Rust and GPUs.

## Wednesday, September 28, 2022

### Joe Marshall

#### Observationally Functional

A couple of years back I wrote a Java microservice that talks to Jenkins to find the state of a series of builds. The code was structured to be “observationally functional” — there were plenty of side effects, but the main data abstractions behaved as if they were immutable as far as the abstract API was concerned. This allows us to treat code that uses these objects as if it were pure functional code.

If a data structure is observationally functional, then regardless of what the implementation does, there is no way to observe side effects at the abstract level. Primarily, this means that if you call a function twice with the same arguments, you always get the same answer. (This implies, but it isn't obvious, that calling a function should not mutate anything that would cause a different function to change.) This restriction has a lot of wiggle room. You can certainly side effect anything local to the abstraction that doesn't get returned to the caller. You can side effect data until the point it is returned to the caller.

The main data abstraction my microservice works with is a representation of the build metadata tree on the Jenkins server. The higher level code walks this tree looking for builds and metadata. The code maintains the illusion that the tree is a local data structure, but the implementation of the tree contains URL references to data that is stored on the Jenkins server. As the higher level code walks the tree, the lower level code fetches the data from the Jenkins server on demand and caches it.

Writing the code this way allows me to separate the data transfer and marshaling parts from the data traversal and analysis part. The tree, though it is mutated as it is traversed, is immutable in the parts that have already been visited. The caching code, which actually mutates the tree, needs to be synchronized across multiple threads, but the traversal code does not. Nodes in the tree that have already been visited are never mutated, so no synchronization is needed.

Once the caching tree abstraction was written, the higher level code simply walks the tree, selecting and filtering nodes, then reading the field values in the nodes. But the higher level code can be treated as if it were pure functional because there are no observable side effects. An advantage of pure functional code is that it is trivially thread safe, so my microservice can run hundreds of threads in parallel, each walking separate parts of the Jenkins tree and none interfering with the other. The only part of the code that uses synchronization is the tree caching code.

This implementation approach was quite fruitful. Once the code was tested with a single thread, it was obvious that multiple threads ought to work (because they couldn't observe each other's side effects) and when I turned the thread count up, no debugging was necessary. The code has been running continuously with dozens of threads for the past couple of years with no timing, synchronization, or race condition bugs.

### GNU Guix

#### Wrapping up Ten Years of Guix in Paris

Two weeks ago, some of us were in Paris, France, to celebrate ten years of Guix! The event included 22 talks and 12 lightning talks, covering topics ranging from reproducible research on Friday and Guix hacking on Saturday and Sunday.

If you couldn’t make it in Paris, and if you missed the live stream, we have some good news: videos of the talks and supporting material are now available from the program page!

If you weren’t there, there are things you definitely missed though: more than 60 participants from a diverse range of backgrounds—a rare opportunity for scientists and hackers to meet!—, impromptu discussions and encounters, and of course not one but two crazy birthday cakes (yup! on one day it was vanilla/blueberry-flavored, and on the other day it was chocolate/passion fruit, but both were equally beautiful!).

There are a few more pictures on the web site.

It might seem a bit of a stretch at first, but there is a connection between, say, bioinformatics pipelines, OCaml bootstrapping, and Guix Home: it’s about deploying complex software stacks in a way that is not only convenient but also transparent and reproducible. It’s about retaining control, both collectively and individually, over the “software supply chain” at a time when the most popular option is to give up.

We have lots of people to thank, starting with the speakers and participants: thanks for sharing your knowledge and enthusiasm, and thank you for making it a warm and friendly event! Thanks to the sponsors of the event without which all this would have been impossible.

Special thanks to Nicolas Dandrimont of the Debian video team for setting up the video equipment, tirelessly working during all three days and even afterwards to prepare the “final cut”—you rock!! Thanks to Leo Famulari for setting up the live streaming server on short notice, and to Luis Felipe for designing the unanimously acclaimed Ten Years of Guix graphics, the kakemono, and the video intros and outros (check out the freely-licensed SVG source!), all that under pretty tight time constraints. Thanks also to Andreas Enge with their Guix Europe hat on for addressing last-minute hiccups behind the scenes.

Organizing this event has certainly been exhausting, but seeing it come true and meeting both new faces and old-timers was a great reward for us. Despite the occasional shenanigans—delayed talks, one talk cancellation, and worst of all: running out of coffee and tea after lunch—we hope it was enjoyable for all.

For those in Europe, our next in-person meeting is probably going to be FOSDEM. And maybe this will inspire some to organize events in other regions of the world and/or on-line meetups!

GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the Hurd or the Linux kernel, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, AArch64, and POWER9 machines.

In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language.

### Mark Damon Hughes

#### Old Man in the Woods Way of Argument Parsing

So, my premise is that only developers use command lines anymore. And after years of corporate enslavement, it's nice to run off to the woods, make a log cabin and all your tools yourself.

Therefore the best way to parse arguments in Scheme is:

(define debug #f)
(define outfile #f)
(define infiles '())

(define (main argv)
(set! debug (if (member "--debug" argv) #t #f))  ;; boolean
(set! outfile (if (member "--out" argv) (cadr (member "--out" argv)) #f))  ;; key-value
(set! infiles (if (member "--" argv) (cdr (member "--" argv)) #f))  ;; all after --
(unless outfile (error 'main "No outfile given")) ;; maybe show a whole usage & exit
)


This has some disadvantages. It's only discoverable by reading docs or even code, and you have to write the docs yourself. If you want short args, you have to duplicate lines and maybe set the arg twice.

But it's trivial to set up, you can't really get it wrong, and the amount of effort is appropriate to a developer interface.

(You might complain I'm using globals, you can just change those to let)

For the young over-engineering crowd, there are a variety of arg parsing libraries. And I'm too lazy to demonstrate each of them. But in the set of generates usage, is easy to use, and you'll be able to remember how it works in a year, they all get maybe 1, and need to be 3.

### Idiomdrottning

#### When an AI researcher didn’t research AI

My take is that the biggest error Lemoine did when saying that LaMDA was sentient was refusing to learn how it worked and how neural networks work generally. It seemed to me that he deliberately wanted to stick to “Turing test”-like conditions. That makes as little sense as if a doctor would want to smash up X-Ray machines. If you can look under the hood, or if your team members can, that’s a huge boon that you shouldn’t squander.

I know a person when I talk to it, It doesn’t matter whether they have a brain made of meat in their head. Or if they have a billion lines of code. I talk to them. And I hear what they have to say, and that is how I decide what is and isn’t a person.

Now, I’ve written about my distaste for “Pinocchio AI”, and plenty of people have pointed out some other flaws in the approach, like asking LaMDA if it is a dinosaur and similar. You know, the good old null hypothesis. Falsification.

That’s good and all but… People have been fooled into thinking that some pillows and a tape recorder under a blanket is a real person. If you can verify out of band, do that.

## Tuesday, September 27, 2022

### Scheme Requests for Implementation

#### SRFI 225: Dictionaries

SRFI 225 is now in final status.

The procedures of this SRFI allow callers to manipulate an object that maps keys to values without the caller needing to know exactly what the type of the object is. Such an object is called a dictionary or dict in this SRFI.

## Sunday, September 25, 2022

### Scheme Requests for Implementation

#### SRFI 231: Intervals and Generalized Arrays

SRFI 231 is now in final status.

This SRFI specifies an array mechanism for Scheme. Arrays as defined here are quite general; at their most basic, an array is simply a mapping, or function, from multi-indices of exact integers $i_0,\ldots,i_{d-1}$ to Scheme values. The set of multi-indices $i_0,\ldots,i_{d-1}$ that are valid for a given array form the domain of the array. In this SRFI, each array's domain consists of the cross product of intervals of exact integers $[l_0,u_0)\times[l_1,u_1)\times\cdots\times[l_{d-1},u_{d-1})$ of $\mathbb Z^d$, $d$-tuples of integers. Thus, we introduce a data type called $d$-intervals, or more briefly intervals, that encapsulates this notion. (We borrow this terminology from, e.g., Elias Zakon's Basic Concepts of Mathematics.) Specialized variants of arrays provide portable programs with efficient representations for common use cases.

This is a revised and improved version of SRFI 179.

#### SRFI 122: Nonempty Intervals and Generalized Arrays

SRFI 122 is now in withdrawn status.

This SRFI specifies an array mechanism for Scheme. Arrays as defined here are quite general; at their most basic, an array is simply a mapping, or function, from multi-indices of exact integers $i_0,\ldots,i_{d-1}$ to Scheme values. The set of multi-indices $i_0,\ldots,i_{d-1}$ that are valid for a given array form the domain of the array. In this SRFI, each array's domain consists of a rectangular interval $[l_0,u_0)\times[l_1,u_1)\times\cdots\times[l_{d-1},u_{d-1})$, a subset of $\mathbb Z^d$, $d$-tuples of integers. Thus, we introduce a data type called intervals, which encapsulate the cross product of nonempty intervals of exact integers. Specialized variants of arrays are specified to provide portable programs with efficient representations for common use cases.

## Thursday, September 22, 2022

### Scheme Requests for Implementation

#### SRFI 236: Evaluating Scheme expressions in an unspecified order

SRFI 236 is now in draft status.

This SRFI defines the perform syntax, which can be used to combine side effects into one expression without specifying their relative order.

## Saturday, September 17, 2022

### Phil Dawes

#### Gambit-C namespaces

One of the first issues I had when evaluating scheme as a possible replacement for Python as my hobby language was its apparent lack of module/library/namespace system. How do people possibly build big programs? I wondered.

Now it turns out most (all?) scheme implementations have features to deal with modules and libraries. Gambit's is particularly nebulous in that it doesn't appear to be documented anywhere. Anyway, here's how it appears to work. I'm sure somebody will correct me if I've got something wrong:

Gambit has the 'namespace' primitive, with which you can declare that certain definitions belong in certain namespaces. Here's an example:


> (namespace ("f#" foo) ("b#" bar baz))


This means (AFAICS): "any further use/definition of the term 'foo' will reference the f# namespace and any use of bah/baz will reference the b# namespace".

e.g.


> (namespace ("f#" foo) ("b#" bar baz))

> (define (foo) "I am foo")  ; defines f#foo

> (foo)
"I am foo"

> (f#foo)
"I am foo"

> (define (bar) "I am bar")

> (b#bar)
"I am bar"


This is cool because it allows you to retroactively fit namespaces to scheme code loaded from other files. E.g. If mod1.scm and mod2.scm both defined a procedure 'foo', you could use namespaces to allow both to be used in the same environment thus:


> (namespace ("m1#" foo))
> (load "mod1")    ; contains: (define (foo) "I am mod1's foo")

> (namespace ("m2#" foo))
> (load "mod2")    ; contains: (define (foo) "I am mod2's foo")

> (m1#foo)
"I am mod1's foo"

> (m2#foo)
"I am mod2's foo"


Job done. Now I haven't really used gambit namespaces much, so I not in a position to provide a good comparison with other approaches, however the feature does seem in keeping with the rest of the scheme language. By that I mean rather than a large set of fully blown rich language features you get a small bunch of simple but very extensible primitives with which to build your own language.

An good example of building a big system over these small primitives is Christian Jaeger's chjmodule library where he has used namespaces along with 'load' and 'compile-file' (and of course macros) to build a more industrial strength module system. This includes an 'import' keyword that loads from a search path and a procedure to recursively compile and import modules. Some example code from the README:



\$ gsc -i -e '(load "chjmodule")' -

> (import 'srfi-1)
> fold
#
> (fold + 0 '(1 2 3))
6
> (build-recursively/import 'regex-case)
; recompiles regex.scm (a dependency) if necessary,
; then (re)compiles regex-case.scm if necessary and imports it.
> (regex-case "http://www.xxx.yy" ("http://(.+)" (_ url) url) (else url))
"www.xxx.yy"
> *module-search-path*
("."
"mod"
"gambit"
"~/gambit"
"~~"
"..")


Sweet. I'm guessing it'll also be possible to build the r6rs library syntax in gambit scheme the same way.

## Thursday, September 15, 2022

### Idiomdrottning

#### Proof of Stake

Ethereum switched over to proof of stake! ğŸ‘�ğŸ�» Now, Iâ€™m still staying the hell away from all kinds of crypto personally, but no more sleepless nights.

Some climate victories do come true â™¥

There are a couple of POW networks still running, Bitcoin most notoriously. But one colossus has been felled so tonight we celebrate.

## Wednesday, September 7, 2022

### Joe Marshall

#### Playing with raycasting

I wanted to learn about raycasting. Raycasting is like a simplified version of ray tracing. As in ray tracing, you examine the environment by projecting a ray from your current location out in some direction to determine what is visible in that direction. But we simplify the problem by only considering two dimensions.

I was also interested in making the graphics more functional and less dependent upon side effects. Now obviously rendering an image to the screen is going to involve side effects, but we can refactor the rendering problem into two subproblems, a pure function that maps the world to an image and the procedure that displays the image.

I'll put the code below. The run procedure implements the event loop state machine. It keeps track of the world and calls next-world on the current world to update the world as time passes. next-world just maps next-state over the objects in the world. next-state does not mutate an object, rather it returns a new object in the new state. Every 13 milliseconds, run calls render-world!, which calls render! on each object in the world.

We're going to use raycasting to fake up a first-person view of a two-dimensional maze. From a position within the maze, we'll cast a ray in a direction and see how far away the wall is. If we peer at the wall through a narrow slit in just that direction, it will appear as a vertical line with height inversely proportional to its distance. If we sweep the ray direction and stack the vertical lines next to each other, it will create three dimensional effect.

The render! method for a fp-view will side effect the screen, but we'll compute the contents functionally. We'll go through each column on the screen and call (vraster fp-view column) to compute a color and a height and we'll draw a vertical line of that height in that color in that column.

(defmethod render! (renderer (fp-view fp-view))
(dotimes (column +window-width+)
(multiple-value-bind (r g b height)
(vraster fp-view column)
(sdl2:set-render-draw-color renderer r g b #xFF)
(sdl2:render-draw-line renderer
column (round (+ (/ +window-height+ 2) (/ height 2)))
column (round (- (/ +window-height+ 2) (/ height 2)))))))

vraster is a function that returns the color and height of the wall on a particular column on the screen. It figures out the angle at which to cast to a ray and calls range to find the distance to the nearest wall at that angle. This is sufficient to determine the wall height for that column, but the first person effect is enhanced significantly if you tint the color according to the distance and the direction of the wall. Knowing the distance, we compute the exact point px, py that the ray hit. It's a wall in the x direction if the y coordinate is an integer and vice versa.

(defparameter +field-of-view+ (/ pi 4))

(defun column->theta (column)
(- (* (/ column +window-width+) +field-of-view+) (/ +field-of-view+ 2)))

(defun vraster (fp-view column)
(let* ((location (get-location fp-view))
(theta (column->theta column))
(distance (range location theta))
(px (+ (get-x location) (* (sin (+ (get-theta location) theta)) distance)))
(py (+ (get-y location) (* (cos (+ (get-theta location) theta)) distance)))
(wx (< (abs (- py (round py))) 0.05))
(wy (< (abs (- px (round px))) 0.05)))
(values
(min #xFF (floor (/ (if wx #xff #x00) distance)))
(min #xFF (floor (/ #xFF distance)))
(min #xFF (floor (/ (if wy #xff #x00) distance)))
(min +window-height+ (/ (* +window-height+ 2) distance)))))

So we've factored the rendering of a frame into a procedure that draws on the screen and a function that returns what to draw. The direct advantage of this is that we can determine what we should draw without actually drawing it. As an example, suppose we wanted to generate a stereo pair of images. The only thing we need to change is the render! method. It will now compute the view from two slightly different locations and put one set of columns on the left and the other on the right.

(defmethod render! (renderer (fp-view fp-view))
(dotimes (column (/ +window-width+ 2))
(multiple-value-bind (r g b height)
(vraster (left-eye (get-location fp-view)) (* column 2))
(sdl2:set-render-draw-color renderer r g b #xFF)
(sdl2:render-draw-line renderer
column (round (+ (/ +window-height+ 2) (/ height 2)))
column (round (- (/ +window-height+ 2) (/ height 2)))))
(multiple-value-bind (r g b height)
(vraster (right-eye (get-location fp-view)) (* column 2))
(sdl2:set-render-draw-color renderer r g b #xFF)
(sdl2:render-draw-line renderer
(+ column (/ +window-width+ 2)) (round (+ (/ +window-height+ 2) (/ height 2)))
(+ column (/ +window-width+ 2)) (round (- (/ +window-height+ 2) (/ height 2)))))))

In this and in a previous post I've gone through the effort of writing some graphics code while avoiding unnecessary side effects. Typical graphics examples and tutorials are stuffed to the brim with global variables, state, and side effects. I wanted to see which side effects were intrinsic to graphics and which are simply incidental to how the examples are coded. It appears that large amounts of the global state and side effects are unnecessary and a more functional approach is reasonable.

As promised, here is the code.

;;; -*- Lisp -*-

(defpackage "RAYCAST"
(:use "COMMON-LISP" "NAMED-LET""))

(in-package "RAYCAST")

(defparameter +window-height+ 480)
(defparameter +window-width+ 640)

(defgeneric next-state (object dt)
(:method ((object t) dt) object))
(defgeneric render! (renderer thing))

(defun next-world (previous-world dt)
(map 'list (lambda (object) (next-state object dt)) previous-world))

(defun render-world! (renderer world)
(sdl2:set-render-draw-color renderer #x00 #x00 #x00 #xFF)
(sdl2:render-clear renderer)
(mapc (lambda (object) (render! renderer object)) world)
(sdl2:render-present renderer))

(defun run (initial-world)
(sdl2:with-init (:video)
(sdl2:with-window (window
:h +window-height+
:w +window-width+
:flags '(:shown))
(sdl2:with-renderer (renderer window :index -1 :flags '(:accelerated :presentvsync))

(let ((last-ticks 0)
(render-ticker 0)
(title-ticker 0)
(sim-count 0)
(frame-count 0)
(world initial-world))

(flet ((title-tick! (dticks)
(incf title-ticker dticks)
(when (>= title-ticker 1000)
(decf title-ticker 1000)
(sdl2:set-window-title window
(format nil "Sim rate: ~d, Frame rate: ~d"
sim-count frame-count))
(setq sim-count 0)
(setq frame-count 0)))

(world-tick! (dticks)
(incf sim-count)
(setq world (next-world world (/ dticks 1000))))

(render-tick! (dticks)
(incf render-ticker dticks)
(when (>= render-ticker 13)
(incf frame-count)
(decf render-ticker 13)
(render-world! renderer world))))

(sdl2:with-event-loop (:method :poll)

(:idle ()
(let ((this-ticks (sdl2:get-ticks)))
(if (= this-ticks last-ticks)
(sdl2:delay 1)
(let ((dticks (- this-ticks last-ticks)))
(setq last-ticks this-ticks)
(title-tick! dticks)
(world-tick! dticks)
(render-tick! dticks)))))

(:keydown (:keysym keysym)
(case (sdl2:scancode keysym)
((:scancode-x :scancode-escape) (sdl2:push-quit-event))
((:scancode-left :scancode-right
:scancode-up :scancode-down
:scancode-pageup :scancode-pagedown)
nil)
(t (format *trace-output* "~&Keydown: ~s" (sdl2:scancode keysym))
(force-output *trace-output*))))

(:quit () t)
)))))))

(defparameter +maze+
#2a((1 1 1 1 1 1 1 1 1 1 1 1)
(1 0 0 1 0 0 0 0 0 0 0 1)
(1 0 0 1 0 0 0 0 0 0 0 1)
(1 0 1 1 0 0 0 1 0 1 0 1)
(1 0 0 0 0 0 0 0 0 0 0 1)
(1 0 0 0 0 0 0 1 0 1 0 1)
(1 0 0 0 0 0 0 0 0 0 0 1)
(1 0 0 0 0 0 0 0 0 0 0 1)
(1 0 0 0 0 1 0 0 0 1 0 1)
(1 0 0 0 0 0 0 0 0 0 0 1)
(1 1 1 1 1 1 1 1 1 1 1 1)))

(defclass location ()
((maze :initarg :maze
:initform +maze+
(x :initarg :x
:initform 2.5
(y :initarg :y
:initform 2.5
(theta :initarg :theta
:initform 0

(defun ud-input ()
(- (if (sdl2:keyboard-state-p :scancode-up) 1 0)
(if (sdl2:keyboard-state-p :scancode-down) 1 0)))

(defun lr-input ()
(- (if (sdl2:keyboard-state-p :scancode-right) 1 0)
(if (sdl2:keyboard-state-p :scancode-left) 1 0)))

(defun pg-input ()
(- (if (sdl2:keyboard-state-p :scancode-pageup) 1 0)
(if (sdl2:keyboard-state-p :scancode-pagedown) 1 0)))

(defun canonicalize-angle (angle)
(cond ((>= angle pi) (canonicalize-angle (- angle (* pi 2))))
((>= angle (- pi)) angle)
(t (canonicalize-angle (+ angle (* pi 2))))))

(defparameter +translation-rate+ 3.0) ;; tiles per second
(defparameter +rotation-rate+ pi) ;; radians per second

(defmethod next-state ((location location) dt)
(let ((fbstep (* (ud-input) +translation-rate+ dt))
(lrstep (* (pg-input) +translation-rate+ dt))
(thstep (* (lr-input) +rotation-rate+ dt))

(old-x (get-x location))
(old-y (get-y location))
(cos-theta (cos (get-theta location)))
(sin-theta (sin (get-theta location))))

(let ((new-x (+ old-x (* sin-theta fbstep) (- (* cos-theta lrstep))))
(new-y (+ old-y (* cos-theta fbstep) (+ (* sin-theta lrstep))))
(new-theta (canonicalize-angle (+ (get-theta location) thstep))))
(cond ((zerop (aref (get-maze location) (floor new-x) (floor new-y)))
(make-instance 'location :x new-x :y new-y :theta new-theta))
((zerop (aref (get-maze location) (floor old-x) (floor new-y)))
(make-instance 'location :x old-x :y new-y :theta new-theta))
((zerop (aref (get-maze location) (floor new-x) (floor old-y)))
(make-instance 'location :x new-x :y old-y :theta new-theta))
(t
(make-instance 'location :x old-x :y old-y :theta new-theta))))))

(defclass fp-view ()
((location :initarg :location

(defmethod next-state ((fp-view fp-view) dt)
(make-instance 'fp-view :location (next-state (get-location fp-view) dt)))

(defun range (location relative-theta)
(let* ((angle (+ (get-theta location) relative-theta))

(dx/dS (sin angle))
(dy/dS (cos angle))

(x-step (if (< dx/dS 0) -1 1))
(y-step (if (< dy/dS 0) -1 1))

(dS/dx (abs (/ 1 (if (zerop dx/dS) 1e-30 dx/dS))))
(dS/dy (abs (/ 1 (if (zerop dy/dS) 1e-30 dy/dS)))))

(let dda ((next-x (* dS/dx
(if (< dx/dS 0)
(- (get-x location) (floor (get-x location)))
(- (+ 1.0 (floor (get-x location))) (get-x location)))))
(mapx (floor (get-x location)))
(next-y (* dS/dy
(if (< dy/dS 0)
(- (get-y location) (floor (get-y location)))
(- (+ 1.0 (floor (get-y location))) (get-y location)))))
(mapy (floor (get-y location)))
(distance 0))
(cond ((not (zerop (aref (get-maze location) mapx mapy))) distance)
((< next-x next-y)
(dda (+ next-x dS/dx) (+ mapx x-step)
next-y mapy
next-x))
(t
(dda next-x mapx
(+ next-y dS/dy) (+ mapy y-step)
next-y))))))

(defparameter +field-of-view+ (/ pi 4))

(defun column->theta (column)
(- (* (/ column +window-width+) +field-of-view+) (/ +field-of-view+ 2)))

(defun vraster (location column)
(let* ((theta (column->theta column))
(distance (range location theta))
(px (+ (get-x location) (* (sin (+ (get-theta location) theta)) distance)))
(py (+ (get-y location) (* (cos (+ (get-theta location) theta)) distance)))
(wx (< (abs (- py (round py))) 0.05))
(wy (< (abs (- px (round px))) 0.05)))
(values
(min #xFF (floor (/ (if wx #xff #x00) distance)))
(min #xFF (floor (/ #xfF distance)))
(min #xFF (floor (/ (if wy #xff #x00) distance)))
(min +window-height+ (/ (* +window-height+ 2) distance)))))

(defmethod render! (renderer (fp-view fp-view))
(dotimes (column +window-width+)
(multiple-value-bind (r g b height)
(vraster (get-location fp-view) column)
(sdl2:set-render-draw-color renderer r g b #xFF)
(sdl2:render-draw-line renderer
column (round (+ (/ +window-height+ 2) (/ height 2)))
column (round (- (/ +window-height+ 2) (/ height 2)))))))

;; (run (list (make-instance 'fp-view :location (make-instance 'location))))


## Monday, September 5, 2022

### Joe Marshall

#### Drawing a circle

SDL is your bare bones graphics interface. It gives you primitives like draw-point, draw-line, and draw-rectangle, but you're on your own if you want to draw a circle. Naturally, I cribbed the code from stackoverflow.

Small circles didn't look right — they were a little squarish. The code worked by walking along pixels in one direction and accumulating an error term. When the error term got large enough, it would be reset and the code would advance a step along the other pixel axis. The error term was computed using integer math so that the circle was drawn quickly. The problem is that the integer math has rounding error and the rounding error is noticable with small circles.

For reference, it is straightforward to draw an exact circle. A circle isn't a function, but circle segment between 0 and 45 degrees is a function. If we mirror that segment eight ways horizontally, vertically, and at 90 degrees, we'll get a full circle.

(defun eightfold-point (renderer center-x center-y x y)
(sdl2:render-draw-point renderer (+ center-x x) (+ center-y y))
(sdl2:render-draw-point renderer (+ center-x x) (- center-y y))
(sdl2:render-draw-point renderer (- center-x x) (+ center-y y))
(sdl2:render-draw-point renderer (- center-x x) (- center-y y))

(sdl2:render-draw-point renderer (+ center-x y) (- center-y x))
(sdl2:render-draw-point renderer (+ center-x y) (+ center-y x))
(sdl2:render-draw-point renderer (- center-x y) (- center-y x))
(sdl2:render-draw-point renderer (- center-x y) (+ center-y x)))

(defun draw-circle (renderer center-x center-y radius)
(dotimes (x (1+ (ceiling (/ radius (sqrt 2)))))
(eightfold-point renderer
center-x center-y
x (round (sqrt (- r-squared (* x x))))))))
This gives much rounder looking circles than the code I cribbed from stackoverflow.

The problem, of course, is that this code computes a square root on each iteration. These days, computers are fast and that's not a big issue, but let's try to improve things.

On each iteration, we are computing the square root of r2-x2. This quantity changes between iterations, but not by much. You can compute a square root pretty quickly using Newton's method. The square root computed last iteration isn't that far from the new square root, so we can use the previous square root as the initial guess for Newton's method. Since we started pretty close to the right answer, we only need a single pass of Newton's method to get close enough to the square root for the current iteration.

(defun average (a b) (/ (+ a b) 2))

(defun draw-circle1 (renderer center-x center-y radius)
(let ((x-limit (ceiling (/ radius (sqrt 2)))))
(do ((x 0 (1+ x))
(o 1 (+ o 2))
(y radius (round (average y (/ (- r2-x2 o) y)))))
((> x x-limit))
(eightfold-point renderer center-x center-y x y))))

This gives us pretty round circles — rounder than the integer methods, but not as round as the sqrt method. It requires less arithmetic than the sqrt method, but more than the integer method. What is more annoying, squarish circles or the amount of time it takes to draw round ones?

## Friday, September 2, 2022

### Idiomdrottning

#### How the Lenia evolver works

The rule doesn’t change. Instead, the pattern changes. In Conway Life you’ve seen “gliders”. Think of these patterns as a much bigger glider pattern and then a machine-learning algo writes more and more capable patterns. So this isn’t self-evolving code; it’s two different halves. One code that looks at, and keeps evolving, the other and it self.

Basically the computer is like “OK my job is to design a hand-written pattern that can make its way through mazes. Oh, they’re all failing. OK, let me evolve myself so that I get better at hand-writing such patterns.”

In real life, there is DNA inside the organisms, and the algorithm (probably better known as “living”) for the organism’s own interaction is the same as their own evolution. That’s not what this is. Instead, the designer is evolving itself. Dying is failing, and dying also changes the algorithm. That’s not how this works. Instead, in this Lenia scenario failure/success judgement is external. (Matthew 25:31-46) And by “dying”, I mean the entire group. Evolution doesn’t only work on an individual level. It works fractally: if you live by screwing over your tribe, the tribe has failed and you with it; if we wreck the planet, we as a planet has failed.)

It’s like if people were hand sculpted by some sorta Pygmalion God and he’d be like “ah man, these scrubs are hanging out the passenger side of their best friend’s ride trying to holla at me” (Genesis 11:1-9) and decides to go do some reps so he’ll get way better at hand sculpting people and then rinse and repeat until he had created some sorta super Galatea that can make its way through an Algernon maze and dodge bullets like Neo.