Jul 14, 2021
I was just reminded after years of the "weird number" in 2's complement arithmetic:

https://en.wikipedia.org/wiki/Two%27s_complement#Most_negative_number

The reason it came up: it's the result of trying to convert a floating-point Infinity or NaN to an integer.

https://c9x.me/x86/html/file_module_x86_id_61.html


Color dithering on the Mu computer.

Here is a before/after pair of images. Before has 256x256x256 colors. After has 256 colors.

Before:

Screenshot of original .ppm file (since Mastodon doesn't render the original directly)

After:

Same image after running through Mu's dithering.

Notice all the yellow pixels in the first image that turn into alternating greens and oranges in the second. Also, the stem looks very different. But overall, it looks gratifyingly similar to the original. My eyes took a while before they started to notice differences.

Main project page

permalink

* *
Jul 12, 2021
Generalizing dithering to color (assuming a fixed palette) turns out to be surprisingly complex. The r/g/b channels are mostly independent copies each analogous to the greyscale dither, but there's tangling in one place in the center that complicates everything.

A chart showing how the r/g/b channels are dithered.

permalink

* *
Jul 11, 2021
Dithering 256 levels of greyscale using 16 levels of greyscale.

Before:

256 levels of greyscale

After:

16 levels of greyscale

permalink

* *
Jul 10, 2021
Starting to render images on the Mu computer

This screenshot shows a greyscale image dithered using just black and white pixels.

Before:

a greyscale version of the standard Barbara image using 256 levels of grey.

https://dsp.stackexchange.com/questions/18631/who-is-barbara-test-image

After:

a screenshot showing a Qemu window containing a dithered version using just black and white pixels.

I rather suspect this isn't quite right. There are some suspicious streaks in various places. Rounding error, maybe.

Credit: https://tannerhelland.com/2012/12/28/dithering-eleven-algorithms-source-code.html. I'm using standard Floyd-Steinberg.

Main project page: https://github.com/akkartik/mu

permalink

* *
Jun 23, 2021
Syntax sugar in the Mu shell

I like Lisp. But I also strongly believe anyone should be able to boot into a computer and immediately type in '1+1'. Get started using the computer as just a calculator. It's surprising how few computers satisfy that property. Now the Mu computer does.

https://archive.org/details/akkartik-mu-2021-06-23 (video; 8 minutes)

Main project page: https://github.com/akkartik/mu

A screenshot implementation of Bresenham's circle-drawing algorithm in a Lisp dialect with some syntax sugar.

permalink

* *
Jun 15, 2021
Collaborating on a problem from Advent of Code in Mu

If anybody is into long and rambling 100-minute videos that taper off without a certain conclusion:

https://archive.org/details/2021-06-02-akkartik-sumeet

Mostly by Sumeet Agarwal

Here's the working solution if anyone wants to try it out it: http://akkartik.github.io/mu/html/linux/advent2017/1a.mu.html

Main project page: https://github.com/akkartik/mu

permalink

* *
Jun 13, 2021
One idea that got dropped on the editing floor for this post: the long shadows cast over our lives by the very first systems we program on.

I started programming (in undergrad) on an IBM PC descendant running DOS. I moved on to more sophisticated systems, but over a period of decades keep returning to seemingly little things about that first system that I could never replicate. Little things I turn out to be willing to give up big things for.

For others, it was some game console. NES, GBA, etc. I wonder how common it is to actually escape the gravitational pull of our first systems, how much of the differences between our projects stems from having our brains colonized by different first systems.

permalink

* *
Jun 9, 2021
Some live-coding in my programming environment, running on my computing stack built up from scratch.

https://archive.org/details/akkartik-mu-2021-06-09 (video; 6 minutes)

Snapshot of a session within the Mu computer's prototyping environment running on Qemu. There's a REPL sandbox on the right, a few function definitions on the left, a list of available primitives for reference on the bottom left, and a list of available keyboard shortcuts along the bottom.

Main project page: https://github.com/akkartik/mu

permalink

* *
May 31, 2021
Managing side-effects on the Mu computer

https://archive.org/details/akkartik-mu-2021-05-31 (video; 2 minutes)

Screenshot of the Mu prototyping environment running in a Qemu window. There's a code editor on the left and a REPL on the right. The REPL can show prints to a picture-in-picture fake screen. It also permits drilling down into the execution of a run to understand or debug what the computer did.

The Mu computer's prototyping environment uses traces to explain and debug programs. But traces are expensive to compute and made the environment slow and laggy.

I fixed things by collecting only a shallow trace at first, and iteratively deepening on demand by rerunning programs. This only works because it's safe to rerun functions. There are no side-effects in Mu.

Main project page: https://github.com/akkartik/mu

permalink

* *
May 20, 2021
The Mu shell's error handling is now much improved. Errors in programs you typed in were already showing up consistently in a trace without crashing the computer. However, _writes to the trace_ could cause it to crash in cryptic ways. No more.

Now I'm back to my long-term plan: a prototyping environment that nudges people to write tests, so that it's easier to throw away the prototype and rewrite it from scratch. Making codebases rewrite-friendly.

Main project page: https://github.com/akkartik/mu

permalink

* *
archive
projects
writings
videos
subscribe
Mastodon
RSS (?)
twtxt (?)
Station (?)