Finites at Fredy's

From Esolang
Jump to navigation Jump to search

Finites at Fredy's is a logic based scheduling language based around a simple, but universal, component: the Controlled Security With Animatronic Patrols (CSWAP) office. AKA "Fredy's".

It is intended to help kids learn about Category:Reversible computing concepts (something that will become increasingly relevant as transistor sizes reach their practical minimum) and provide a gentle introduction to the Quantum Circuit model through the familiar and comfortable medium of survival-horror, and (cheap) jump-scare reinforced learning.

Description


(West Hallway)> ╟▆╢ <(East Hallway) 
                 ^ (Control Room)

The Fredy's office consists of a control room flanked by two hallways, one West, and one East. The hallways are connected to the control room by security doors which are OPEN by default, allowing anyone, or anything, to pass through the control room unimpeded unless there is a living controller in the room able to manually close the doors. (No, this does not make any security sense, but is required for the logic to work).

A Finites at Fredy's program consists of a finite list of animatronics in storage locations (numbered 1 to n), and a schedule of patrol triples for a finite number of shifts ("nights").

Animatronics can have arbitrary names, but must be unique. There is one reserved keyword EMPTY to indicate a storage location is empty. The symbols () are used to denote that an animatronic is optional in any multi-shift playthrough. For all animatronics enclosed in (), the user is prompted before the first shift to specify whether that animatronic is present or not (1/0). If not selected, that storage location is to be considered EMPTY for this particular playthrough and that animatronic is removed from the building. A convention to indicate which storage locations represent output at the end of a playthrough is to mark the location content with a ! in the header row.

Each shift consists of one or more triples mapping three storage locations to West Hallway, Control Room, East Hallway. There can be more than one triple per shift, but no storage location can be opened twice in one shift.

Shifts proceed as follows: For each triple, the contents of the storage locations are placed in the three locations: West Hallway, Control Room, East Hallway.

There are two possible outcomes:

  1. If there is an animatronic in the Control Room, the controller is "incapacitated" and cannot close the doors in time. Any animatronics in the Hallways will pass through to the other side.
  2. If the storage location associated with the Control Room is EMPTY, the controller is able to close the doors in time, and any animatronics in either hallway will stay there, until it is time to return to their original storage location.

After each triple, the animatronics are returned back to storage locations. Control room animatronics always return to their original location. Hallway animatronics return to the storage location mapped to that hallway at the start of the triple. If the controller survived, all animatronics will return to their original locations. If the controller did not survive, locations will be swapped for any animatronics in the hallways. Controllers are replaced as needed, there apparently is always someone willing to take the job.

Reversibility

An interesting and important property of this configuration is that animatronics are always conserved. The same cannot be said for controllers, but fortunately for management this does not affect computational ability, and is therefore considered unimportant. The number of animatronics in the building never changes, but their storage locations do. Even though the locations of animatronics can become thoroughly mixed, all management needs to do to return animatronics to the original locations is run the series of shifts in reverse, most likely with a fresh set of controllers.

Examples

Full-adder (1-bit, with carry)

(B), (C), (F), EMPTY!, FF!
5, 1, 4
5, 2, 4
5, 3, 4
5, 4, 3
5, 2, 3 

This 5 night schedule with five storage locations and between one and four roaming animatronics represents a full 1-bit adder (with carry). It adds animatronics in locations 1, 2, 3, and returns the total in binary notation in locations 3, 4 at the end of the 5 night playthrough ({00, 01, 10, 11}).

Hi! output

Illustrating ! to indicate output bits (locations to inspect at the end of the schedule). The schedule is run as many times as there are characters to output using the input locations.

(A), (B), C, D!, EMPTY!, EMPTY!, E!, EMPTY!, EMPTY!, EMPTY!
3, 2, 5
2, 5, 10
4, 1, 5
7, 1, 10

Inputs (A) (B) map to the seven marked output locations for 7bit ASCII values:

  • 00: H
  • 01: i
  • 10: !

Output with input: A=1, B=0

Input Animatronics: ['A', None, 'C', 'D!', None, None, 'E!', None, None, None]

Schedule	Staff On Duty	West Coor.	Control Room	East Coor.	Output (masked)
Night 1:	Employee #1	Loc. 3 (C)	Loc. 2 (None)	Loc. 5 (None)	1001000: int: 72 chr: H
Night 2:	Employee #1	Loc. 2 (None)	Loc. 5 (None)	Loc. 10 (None)	1001000: int: 72 chr: H
Night 3:	Employee #1	Loc. 4 (D!)	Loc. 1 (A)	Loc. 5 (None)	0101000: int: 40 chr: (
Night 4:	Employee #2	Loc. 7 (E!)	Loc. 1 (A)	Loc. 10 (None)	0100001: int: 33 chr: !

     ┌─────────────────┐                           
q_0: ┤ initialize(0,1) ├──────────■──■─────────────
     ├─────────────────┤          │  │             
q_1: ┤ initialize(1,0) ├─■─────X──┼──┼─────────────
     └──────┬───┬──────┘ │     │  │  │             
q_2: ───────┤ X ├────────X─────┼──┼──┼─────────────
            ├───┤        │     │  │  │    ┌─┐      
q_3: ───────┤ X ├────────┼─────┼──X──┼────┤M├──────
            └───┘        │     │  │  │ ┌─┐└╥┘      
q_4: ────────────────────X─────■──X──┼─┤M├─╫───────
                           ┌─┐ │     │ └╥┘ ║       
q_5: ──────────────────────┤M├─┼─────┼──╫──╫───────
            ┌───┐          └╥┘ │     │  ║  ║    ┌─┐
q_6: ───────┤ X ├───────────╫──┼─────X──╫──╫────┤M├
            └───┘       ┌─┐ ║  │     │  ║  ║    └╥┘
q_7: ───────────────────┤M├─╫──┼─────┼──╫──╫─────╫─
             ┌─┐        └╥┘ ║  │     │  ║  ║     ║ 
q_8: ────────┤M├─────────╫──╫──┼─────┼──╫──╫─────╫─
             └╥┘         ║  ║  │     │  ║  ║ ┌─┐ ║ 
q_9: ─────────╫──────────╫──╫──X─────X──╫──╫─┤M├─╫─
              ║          ║  ║           ║  ║ └╥┘ ║ 
c: 7/═════════╩══════════╩══╩═══════════╩══╩══╩══╩═
              1          2  4           5  6  0  3 
RESULTS (result: count): {'0100001': 100}
As int: 33
As chr: !

OpenQASM conversion

Finites at Fredy's code can be easily converted to OpenQASM2.0 for simulation and circuit viewing using the following Python function which takes a multiline string of a Finites at Fredy's schedule as input:

   lambda faf: '\n'.join(['OPENQASM 2.0;\ninclude "qelib1.inc";\nqreg q[{}];'.format(len(faf.split('\n')[0].split(',')))] + ['cswap q[{1}], q[{0}], q[{2}];'.format(*[int(v) - 1 for v in s.split(',')]) for s in faf.split('\n')[1:] if s])

See also

Other esolangs built on universal logic gates (not necessarily reversible):

External resources