jblog
toc

Colorful Time Prompt in zsh

2020-04-18, post № 227

programming, #customization, #prompt, #zsh

I have been using zsh for a while now, and whilst I like its minimalistic approach, I felt that my prompt lacked a certain graphical oomph.
Thus, I built what most graphical environments hide away at the screen’s corner directly into the prompt — a clock. Paired with a time-sensitive rainbow color scheme, I find the result quite visually pleasing.

If you want to try out my prompt, the following installer automatically downloads jprompt.c, compiles it and asks if .zshrc should be set up to load my prompt.
Since jblog has moved, the below script might not work.

% curl --silent https://www.jfrech.com/jblog/post227/install.zsh | zsh

Zpr’(h

2020-03-21, post № 226

programming, Zpr'(h, #esolang

I have designed and implemented a new esoteric programming language called Zpr’(h. It is a language built upon iterated symbolic pattern matching, requiring the user to define their own semantics and interpreting them as computations.
Whilst developing Zpr’(h, I implemented a rudimentary standard library, defining semantics for natural numbers, mappings, lists and logic. Furthermore, I used these semantics to define a lazy computation of all prime numbers — albeit executing at a rather slow pace.
Having finalized the language’s specifications I began investigating its computational bounds. After all, testing primality is a primitive recursive relation. Thus, it a priori is not even clear if Zpr’(h is Turing complete — a useful feature for a programming language to have.

Pondering this question, I thought about how to show that Zpr’(h is indeed Turing complete — driven by hope that I have not created a primitively weak language. I briefly thought about implementing a Turing machine but quickly opted to implement a brainfuck interpreter — equivalent, since both can simulate each other.
After having written said brainfuck interpreter (zprh_brainfuck.zpr), I proceeded to test it only to realize that using byte-based pattern matching to implement a brainfuck interpreter in a functional manner does not lead to the most efficient implementation. Interpreting the brainfuck program ++[->+++<]>. — that is, multiplying two by three — takes a respectable twenty seconds at 𝟦.𝟢𝟢 GHz. Yet more excruciatingly, adhering to commutativity and interpreting +++[->++<]>. yields the same correct numerical result, although at a steep slowdown to over three minutes.
Time constraints are not the only factor — since the current Zpr’(h implementation does not alias any byte sequences if long byte sequences are duplicated, the memory footprint rises to the unmanageable, easily blowing the 𝟣 GiB provided by default. Increasing the available memory most likely not make much of a difference given the aforementioned exponential behavior.
Thus, testing larger brainfuck programs appears not to be feasible due to computational resource limitations. Nevertheless, I am now fairly certain of Zpr’(h being Turing complete, even though my brainfuck implementation may not be correct.
To input brainfuck source code into the above interpreter, I used this translator.

Not being satisfied with a nigh untestable brainfuck implementation, I attempted to fulfil another classical interpretation of computability; recursive functions. As seen above, primitive recursive functions can already be modelled, leaving only the existence of µ-recursion open; a one-liner using the standard library:

(µ .p) |> (head (filter p |N0))

In conclusio, I am convinced that Zpr’(h is Turing complete, if not very efficient — a common fate of esoteric programming languages.

As a side note, implementing the Ackermann-Peter function is fairly intuitive: zprh_ackermann-peter.zpr
I have also golfed in Zpr’(h; it is not the most terse language out there.

Complete Contact Configurations

2020-02-22, post № 225

C, games, programming, #board game, #Contact, #stochastic analysis

Contact is a board game designed by Ken Garland in which players draw square tiles containing colored connections from a pile, attempting to form matches. Whilst the game is enjoyable to play — allowing the odd trading of cards in unfortunate circumstances — it seldom leads to a complete configuration, meaning a valid contacting arrangement using all available cards.

With the power of stochastically driven brute-force, however, finding such complete configurations turns out to be feasible — at least when playing with the 𝟣𝟦𝟢 cards my Contact version contains. Not surprisingly, many solutions are of rather linear nature since the game only contains two branching cards, i. e. cards where three sides boast connections.
Thus, the search is further narrowed in by demanding a maximum dimension, that is the final configuration has to lie in a card rectangle of a given area. From my testing, a maximum dimension of 𝟧𝟢𝟢 is moderately quickly computed (~ 𝟥𝟢 sec @ 4.00 GHz), whilst lower maximum dimensions appear to be less likely.

complete-contact-configurations-00_tdg-500.png
0complete-contact-configurations-00_tdg-500.png225/complete-contact-configurations-00_tdg-500.pngcomplete-contact-configurations-01_tdg-500.png225/complete-contact-configurations-01_tdg-500.pngcomplete-contact-configurations-02_tdg-500.png225/complete-contact-configurations-02_tdg-500.pngcomplete-contact-configurations-03_tdg-500.png225/complete-contact-configurations-03_tdg-500.pngcomplete-contact-configurations-04_tdg-500.png225/complete-contact-configurations-04_tdg-500.pngcomplete-contact-configurations-05_tdg-500.png225/complete-contact-configurations-05_tdg-500.pngcomplete-contact-configurations-06_tdg-500.png225/complete-contact-configurations-06_tdg-500.pngcomplete-contact-configurations-07_tdg-500.png225/complete-contact-configurations-07_tdg-500.pngcomplete-contact-configurations-08_tdg-500.png225/complete-contact-configurations-08_tdg-500.pngcomplete-contact-configurations-09_tdg-500.png225/complete-contact-configurations-09_tdg-500.pngcomplete-contact-configurations-10_tdg-500.png225/complete-contact-configurations-10_tdg-500.pngcomplete-contact-configurations-11_tdg-500.png225/complete-contact-configurations-11_tdg-500.pngcomplete-contact-configurations-12_tdg-500.png225/complete-contact-configurations-12_tdg-500.pngcomplete-contact-configurations-13_tdg-500.png225/complete-contact-configurations-13_tdg-500.pngcomplete-contact-configurations-14_tdg-500.png225/complete-contact-configurations-14_tdg-500.pngcomplete-contact-configurations-15_tdg-500.png225/complete-contact-configurations-15_tdg-500.pngcomplete-contact-configurations-00_tdg-500.png

From an implementation point of view, a generalized Contact card (defined as four sides, each with three nodes being blank or colored one of three colors) snuggly fits into 𝟤𝟦 bits, allowing for card rotation, reflection and match determination bei ng implemented through integer bit fiddling.
The stochastic process is driven by an (ideally assumed) uniformly distributed random number generator, being recursively applied until all cards are consumed. Finally, an image is created as a portable pixmap .ppm and resized to a .png using ImageMagick.

Source code: complete-contact-configurations.c

Jonathan Frech's blog; built 2021/04/16 20:21:20 CEST