Part 46: Cybermyth studios

Part 46 - Cybermyth studios

=== Trash World Inbox ===

Quackles has a nice improvement for last week's task.
With such a comprehensive explanation, there's not much I can add. Your file writing code is quite elegant, and because it doesn't use M I wouldn't be surprised if it was faster.


=== Cybermyth studios ===



Time to help out Ghast... Wait, 1992? I was in 1998. Is this supposed to be a flashback or something?

I don't know, so let's just get to the task.


OST: Getting Started

The assignment this time:
- Each host contains two files: a list of accounts and a list of transactions. Although the entries in these files vary, the first value of each entry is a unique identifier that connects an account to one or more transactions.
- Determine the amount of back-pay owed to Ghast and Moss by subtracting the amount that they were paid (file 221) from the amount that they were owed (file 231). Then add their shell company (file 300) to the list of accounts payable (file 220) and issue a single payment to it for the total amount owed (file 221).
- Note that all monetary amounts are represented as two values: dollars, then cents.

That's quite a lot of information. Before I figure that out, let's look in the files. From the dates, it seems I'm definitely in 1992. The files in the RECEIVABLE host list some transactions related to companies. The RECORDS host has no transactions, but the files say that Ghast is on report for absenteeism and I (Moss) am on report for intoxication. Crap.

Something I hadn't noticed yet: my home host is named GHAST. Am I actually playing as Ghast? The same thing was the case for the other postgame tasks so far.

The expected goal shows that I actually have to change two things:
- Add the shell company TRASH WORLD CLEANING to file 220, starting with the first unused ID number.
- Add a transaction to file 221, with the ID of the shell company, a date (I guess today's from the #DATE register), and an amount.
That amount is the amount Ghast and Moss are owed, which I can get by subtracting the total paid amount from the total owed amount.

Looking at the data, the total owed amount is often more than the EXA's max value of 9999. At least in the first few tests, the amount paid is not. So, I should be able to solve this problem by writing the amount paid as a negative, then adding the amount owed to it, so I never cross the 9999 boundary.

For the total amount owed, it looks like the payroll has the same amounts for every week, AND everyone gets paid every week. That means I can just calculate the amount for one week and multiply that by the number of weeks.

Enough with the theory, let's write some actual code.

XB just grabs the information file and sends data over M.
XA goes to the host containing the paid amounts and finds Ghast's and Moss's account ids. This is done through a basic search loop. But I realized that I'll never have enough registers in one EXA to test if a transaction belongs to either Ghast or Moss in one go. So I REPL the EXA containing Ghast's id (it barely fits in the host when the original EXA is holding a file). It grabs the other file, then sends a message over M in local mode. The TEST MRD in the search loop causes the search for Moss to end without a REPL and in MOSSDONE.

That means the original EXA holding the list of accounts now has Moss's id in X, the other one has Ghast's id.



The EXA containing Ghast's id changes to local mode, creates an EXA I called LOCALCTRL and starts sending Ghast's dollar amounts to it. LOCALCTRL adds them up and stops once it gets a zero. Because the M's interacted badly, I removed the MRD check from below the FINDPERSON, and added a check after the REPL, which tests if XB sent a 0. However, this doesn't get triggered because the EXA waits on the REPL command until a space is freed up. Something to think about later. At least now I have Ghast's amount of paid dollars.

I added several steps. First, after the amount of dollars, I add up the amount of cents too. Moss's id is temporarily sent to XB and then retrieved by the EXA that's looking through the transactions. It then sends Moss's dollar and cent amounts. XB finally sends a 0 which causes both the sender and the LOCALCTRL EXA to jump to a final state. At that point LOCALCTRL is holding a file with respectively, an amount in dollars, cents, dollars and cents. It adds these up, making sure to add cent amounts > 100 to the dollar value. It ends with total dollars in X and total cents in T.


Okay, with that done I need to find out how much they are due.

I can do a bit of cleanup first. That original EXA is still sitting at REPL GHASTID. Instead of letting it continue, I can have the other one just do a KILL. That means that I can remove the TEST and HALT after it. There's also a place where I had to do a TEST X = 0 and if that's true it can HALT. It saves some space to just DIVI T X T and use the divide by zero trick.

Dealing with the payroll is a bit tricky, because the accounts there have other IDs. I need to get Ghast's and Moss's name from file 300 once more.
You know what, doing that with M is going to cause timing issues. I'll just have another EXA handle that altogether.


Enter the extended XB. I'll go through it bit by bit.
After grabbing the file, it copies Ghast's and Moss's name to X and T. The 'main' XB still sends these values over global M to XA. XA's FINDPERSON code stores the result in X and sends it to M. The first time round, XB VOIDs the M. The second time round, because XA can never REPL, the id on M is necessary. XB buffers it in X, then forwards it to XA's existing REPL when it is ready to receive. Finally, when XA asks for a 'third name', XB send COPY 0 M. The 0 tells XA to continue with the next part (the calculation).

The MODE change followed by a final M message is for the PAYROLL REPL. Once PAYROLL is done, it'll come back to the home host and wait for this M, which indicates that XA is ready. After that, the original XB can HALT and the PAYROLL can take over. By the way, by reordering the code a bit I can get rid of this HALT by having the EXA fall through into harmless code where it dies.


Now, for the PAYROLL itself. It switches to MODE to LOCAL and will stay there. This way it can never interfere with the XB-XA GLOBAL communication.
Since the IDs in the payroll host differ, XB has a copy of the FINDPERSON code. This time, it just sends the result on local M. It then waits for a message. If this is a 0, it dies. If not, it waits for another message from M into X (Moss's name). We need to listen to M twice because attempting to do arithmetic on a text string crashes the EXA.

The OTHER REPL GRABs the file with the amounts owed. Then it copies the ID found by FINDPERSON to X. It sends 1 to M to tell FINDPERSON to look for Moss, followed by Moss's name which is still sitting in T.

After that it needs to wait a bunch of cycles. That's because before the FIND loop can start looking for Ghast's salary, the CTRL EXA first needs to get Moss's ID. I'll get to that EXA in a second.

The FIND loop itself simply looks for Ghast's ID and then copies both the dollars and cents to M. If it gets Moss's ID (which is a non-zero number) it'll look for his amount too, otherwise this EXA will continue to another part of the code.

Before we go to that next part I'll show the CTRL REPL.

First, it waits for the second ID from FINDPERSON. It sends a 0 to let FINDPERSON know it can stop looking. Then it makes a temporary file, in which it stores Ghast's salary (dollars, then cents). This EXA sends Moss's ID to the FIND EXA and then stores Moss's salary too. It sends a 0 to tell the FIND EXA it's done. It adds the two salaries together, and then does the same trick as XA, with the SWIZ to add any hundreds of cents to the dollar amount.

Finally, the temporary file is WIPEd and a new one is made to store the total salary in. Having a file without intermediate garbage makes things simpler later.

The EXA then parks the temporary file in the gateway host (since the payroll host is full), and goes back to GRAB 230 again. This time, it counts the number of people on the payroll. This is multiplied by 4 (because there are 4 items per person per week in file 231) and sent to M, where the FIND EXA which is still holding 231 can read it. Once that's done, it quickly goes back to grab the temporary file (402) again.

Before we continue, let's look at what the FIND EXA has been up to.

This EXA receives the multiplied value and saves it to X. For example, if there are 5 people on the payroll, it'll save '20' to X. That way, by doing a SEEK X it jumps ahead exactly one week. So, what this does is count how many times everyone (including Ghast and Moss) were supposed to be paid.

Since X holds the value to SEEK and T is used for EOF, the actual counting is done by COPY 1 M in the loop, followed by a COPY 0 M to let the CTRL EXA know when it's done. The HALT here is optional if I structure the code so this EXA dies without further side effects after the COPY 0 M.

This is the final part of the CTRL EXA and XB's code as a whole. This EXA is back in the payroll host. In the MORE loop it keeps track in X of the number of payments, and uses T to check when it's done. Then it LINKs back home, and then waits until the original XB sends that one LOCAL message to say XA is done.

At that point this EXA truly takes control by switching to GLOBAL mode, sending the number of payments, then the total amount of dollars, then the number of payments again and then the amount of cents.

If it's not quite clear what I've just done, here's an example:
- Moss gets paid $1076.92 per week.
- Ghast gets paid $961.53 per week.
- In total, they get paid 1076.92 + 961.53 = $2038.45 per week.
- The payroll says they owe payment for 5 weeks.

In this case, the CTRL EXA sends: 5; 2038; 5; 45. That way, the receiving EXA knows to apply $2038 five times, and the cents amount too. Since 5 * 2038 is greater than 9999, this is the most straightforward way to handle it.

Finally, this EXA GRABs file 300 so it can send the shell company's name before it stops.


To handle all this, I added more code to XA.

If you remember, we left off XA with the dollars-already-paid amount in X, and the cents-already-paid in T. It's also holding a temporary file containing intermediate date, with the file pointer sitting at the end.

At this point, we're certain that the only other EXA in this host is the one stuck trying to REPL. I can safely kill it. Then, we store the negative of the cents amount in F and the negative of the dollars amount in X. The EXA switches to GLOBAL MODE and puts the amount of payments in T and the amount of dollars per week in F.

The AGAIN loop adds the amount owed to the negative of the amount paid repeatedly. For example, if the amount paid is $100 and the amount owed is 5 payments of $60, the calculation is -100 + 60 + 60 ... and so on. The result, which is the actual final amount Ghast and Moss are owed, is stored in F.

Next, we repeat the exact same trick but with the cents. Again, I have to do the SWIZ to handle hundreds of cents.

While testing I found out this bit of code failed in one particular case. Because I'm subtracting the cents separately from the dollars, it's possible to end up with a negative amount of cents. For instance, 56 dollars and -29 cents. That's actually supposed to be $55.81. There might be a way around this by doing something smart with the SWIZ code but I just slapped a workaround after it.

Temporarily store the dollar amount (which was in T) to F, so I can do a test. Then, if the cent amount is negative, add 100 to it, and subtract 1 from the dollar amount. The dollar amount is put back into T.

Now, all that's really left is clean-up and writing the final values to the file.

The EXA now WIPEs its temporary file and GRABs 220 again. First, it finds the highest ID in the file and adds one to it. This value is saved to the end of the file, followed by the shell company's name, which we get on M from XB.

Then, it grabs file 221, and adds a new transaction, starting with the shell company's ID number, and then the DATE which it gets from the DATE REPL. It then copies the dollars amount from T, and it gets the cents amount from DATE as well, since it was overwritten in X by the ID.

The REPL itself doesn't have much code. It goes grab the current date from the hardware register, sends that, and then the cents.

The NOOP here is absolutely necessary. Without it, it would start sending just before the other EXA had the chance to read the shell company's name from M. If I had put the REPL DATE instruction any earlier I would've needed even more waiting cycles here. And I couldn't put it any later, because after that point, X gets overwritten.


That's every single piece of the code explained. While testing, I ran into one more bug. It is possible for the amount of cents in a payment to be 0. And I was already used 0 to let the other EXA know no more payments are coming. I fixed that by sending the amount + 1 and then subtracting 1 once the other EXA receives it. I had to do this for dollars as well because they share the receive code.

The full code is... hard to read because I shuffled blocks of code to remove a bunch of HALT instructions. It's very long, so I added it in an appendix at the bottom.



Oh. It's way too long.

Well, the good news is that even though I don't get a high score, the game still counts this task as completed. I'm glad, because I spent enough time on it that I really don't want to optimize it further.

I can see my score by looking at the detailed test run data. It's 536/246/16.

Outside the level, the histograms show up.


The top percentiles are 215, 92, and 4, but for size there's a tiny little peak in the histogram around 60. I can think of some optimizations but getting it down to 60-ish? I have no idea how. My speed though is close to tenth percentile, and I'm happy with that.



Next time, hydroponix.


=== Appendix ===