Week 4: A Fork In The Road?

Welcome back to my senior project blog! Last week I described more in detail how the process of converting from Piet to BrainF works, and this week I’ve continued to convert some sample programs into BrainF. I finished up converting all 15 Piet instructions into equivalent BrainF strings, which I expected would take a decent chunk of time.  

A subset of all the commands included 

But I’ve been running into other issues that I didn’t expect. The website that specifies the Piet standard, and hosts many of these Piet samples also recommends a specific interpreter written in C called npiet. I assumed that because of this endorsement, npiet would be able to run nearly all the samples without issue, but upon testing some, I realized that npiet gives me incorrect results in more than a few cases. Some samples were explicitly marked on the website as not functioning with npiet, but others that weren’t marked this way still did not work with the interpreter. Npiet could get easily stuck in an infinite loop searching for the next pixel cluster to move to. And in some cases it couldn’t recognize the color palette of some invalidly-formatted Piet programs. 

I also feel I may have to shift what I expect to be doing in this project. I still plan to test out AI in converting BrainF to Piet, but as I’ve been working on the project I’ve realized that the generated BrainF doesn’t feel reflective of BrainF programs in general. There are many redundant actions that are introduced to ensure the conversion works smoothly. Every operation in Piet needs to be mapped over to BrainF. To do this I assume that at the start of each BrainF “operation” (the collection of many smaller operations needed to reproduce a singular Piet operation) the pointer is at a well known home position pointing at a cell directly to the right of the stack, so at the end of each “operation” I move the pointer to this home position. But each “operation” usually needs to start at a different position than the home position. This results in additional “operations” on the pointer; for example, moving 3 to the right (>>>), and then immediately after moving 2 to the left (<<). In a manually written BrainF program, it would make far more sense simply to move 1 to the right (>) since that is equivalent to the other instruction set (>>><<). I could fix this problem individually, but this same issue would persist in more ways that would be hard to counter. And if I were to put the majority of effort into this model I would want it to convert BrainF to Piet in general, not just my specific class of generated BrainF programs into Piet. 

Another part of the AI option would be deciding between a text-to-text translation approach, or a text-to-image approach. Originally I envisioned directly translating BrainF text to Piet images. This would be difficult for the AI, as there is a lot involved with interpreting the image format, and understanding what grouping of pixels is associated with an operation of Piet. But this image data fully encapsulates what a Piet program is. The other option would be text-to-text, which I am now considering moreso than text-to-image after conversations with my counsellors. Using a text-to-text model would make it easier to achieve interesting results using AI, but at the cost of only representing the logic behind a Piet image, and not the full image. The below image represents the BrainF operations and the corresponding Piet-text format produced from the npiet interpreter. This would most likely be what the AI is translating between if I were to use a modified text-to-text model.  

Because the AI option will most likely not work as well as I originally expected, I may also focus my effort on another aspect of code translation. While talking to my advisors over the past few weeks I had a shift in thought about what the project was focused on. I always thought the final AI product would be the more interesting translation, and the rest of the project would be building up to that. But recently I’ve realized that the rule-based translation of Piet to BrainF I’ve been working on also is interesting to analyze. Both AI and rule-based translations have their own limitations and strengths, and fall into their own different pitfalls. So it may also be interesting to attempt to create a program which “manually” translates BrainF to Piet, through pre-defined rules, like with my current Piet to BrainF program. My intuition about this is that it would take me significantly less time than putting together the Piet to BrainF rule-based translation. Where Piet has more complex operations that need to be expressed in long BrainF strings, BrainF has very few operations, and each is extremely basic. 

No matter what specific aspects I focus on throughout the rest of the project, I still hope to explore these concepts in interesting ways!