Slim's Geek Gazette

[Slim]

But: I'd like to organise the game so that when you enter a quadrant for the first time, it gets created. But then it gets saved, so when you come back, the stars (and Klingons if present) are all in the same place.

So having looked into this, I realised that there's a flaw in this idea. In the existing design, after the Enterprise arrives in a quadrant, the quadrant is populated "around" it. In other words other objects are never placed in the same location.

But if we cache the positions rather than rebuilding them around the Enterprise, the ship could land on top of a star or Klingon.

I still think it's worth doing, but - we'll have to perform a search for the next free position. Very worst case, the next seven positions are occupied and the odds against that are billions to one.

[Slim]

So  I did that, works nicely. Surprisingly complicated to do, but it's a bit like building a working model from parts you've made yourself, really rewarding.

Will try to come up with some more meaningful enhancements, maybe uncloaking Romulans or something.

[Thenop]

I love the amount of geekiness that oozes through this thread.
I myself find it perfectly normal to refer to Romulans, Vulcans or the Glory of the Empire. Fortunately so does my wife, but I do see people making a face when I wandere in less than geek territory every now and then. Not that I care. I am way past that point.

Anyway, sounds like a fun project you are doing.

[Slim]

The actual "language" used by Casio programmables at that time is very basic - it more or less just mirrors the keystrokes that you'd type if you were doing the calculations by hand, with some crude flow control and memory handling thrown in.

Unfortunately I deleted the program from the calculator many years ago. My next project is to reacquaint myself with the language, and code another Gaussian Eliminator.

So I've prototyped a Gaussian Eliminator program in awk, which is a language most oftne used for manipulating text. My first instinct would have been to do this in BASH, for familiarity. But BASH only does integer arithmetic natively. So this is what I came up with, in awk:

Code Select Expand

#!/usr/bin/awk -f

function get(prompt, var) {
    printf "%s ", prompt
    getline var < "-"
    return var
}

BEGIN {

  A = get("X1")
  B = get("Y1")
  C = get("K1")
  D = get("X2")
  E = get("Y2")
  F = get("K2")

  M = A / D
  print "M:"
  printf M
  du=get("")
  E = M * E
  F = M * F
  printf A
  du=get("")
  printf E
  du=get("")
  printf F
  du=get("")

  E = B - E
  F = C - F

  printf E
  du=get("")

  printf F
  du=get("")

  Y = F / E
  printf "Y="
  du=get("")
  printf Y
  du=get("")

  B = B * Y

  printf A
  du=get("")

  printf B
  du=get("")

  printf C
  du=get("")
 
  C = C - B

  printf A
  du=get("")

  printf C 
  du=get("")

  X = C / A

  printf "X="
  du=get("")

  printf X
  du=get("")

}
It's intentionally very minimal and crude, to mirror a calculator program. Those 'du=get("")' lines are just to pause until a key is pressed, like a calculator can be made to do.

For the problem:

2x+y=7
3x−2y=7

.. the transcript looks like this:

Code Select Expand

X1 3
Y1 2
K1 7
X2 2
Y2 1
K2 7
M:
1.5
3
1.5
10.5
0.5
-3.5
Y=
-7
3
-14
7
3
21
X=
7 

I think that's pretty close to what my old Casio program would have done in 1986.

Next - convert to Casio code and key in to my calculator!

[Slim]

So, I did that. The Casio program is:

Code Select Expand

?→A:?→B:?→C:?→D:?→E:?→F:A÷D→M:"M="◢M◢E×M→E:F×M→F:A◢E◢F◢B-E→E:C-F→F:E◢F◢F÷E→Y:"Y="◢Y◢B×Y→B:A◢B◢C◢C-B→C:A◢C◢C÷A→X:"X="◢X◢
And it works! I'm sure it's not exactly the same code I keyed in to the calculator in the summer of 1986, but it does pretty much the same thing.

If you're curious, the ◢ means pause until the user presses a key (allows you to read what it's just written to the single line display) and the : is a delimiter between commands.

[Matt2112]

I'm going to start a thread called "Matt's Greek Gazette" so you techies might get an empathetic idea of how this one appears to me.

[Thenop]

I'm going to start a thread called "Matt's Greek Gazette" so you techies might get an empathetic idea of how this one appears to me.

So that'll be a thread on run down buildings with philosophical tag lines then?

[Matt2112]

I'm seriously considering doing a Greek GCSE so it could be a journal of my progress through that... 

(Sorry to go off-topic).

[Slim]

I decided to rewire my Star Trek program. I just thought of a cleverer way to organise and manipulate the quadrant data. But it was in a complete and working state, so I've kept the existing code as "version 1". My fear of course is that I'll introduce a bug, get bored with it while it's broken, and end up getting an AI to tell me how it works again, years from now. As long as I have a working version, this mission that I embarked on a few weeks ago is complete.

I should admit that the change I'm making makes zero difference to the experience of using the program. But because it's an ancient game from the days when every byte was precious I'm indulging an extreme efficiency philosophy. More in keeping with the spirit of the original idea, back in 1971. It comes partly from learning to code on a ZX-81, a system with roughly seventeen million times less memory than my present Desktop computer has. Without doubt it did make me a very economical programmer.

More than anything, I just find it fascinating to do, like a very complicated puzzle.

[Slim]

So I did that. Changed the way it handles its data. Introduced some clever caching for short range scan displays, and nifty buffering for screen writes. I went to bed last night at about 0130, shortly after I had the idea, with a contented smile on my face as I closed my eyes, thinking "that'll keep me occupied for a few days!"

Nope, all done by about 1500.

I still have a few vague ideas on how to extend it though. Maybe introduce Romulans. I could even have the Romulans and the Klingons attacking each other. Or wormholes.

[Slim]

Spent most of the day setting up my new PC. Using it now, but still a lot to do. But I've hooked the old one up to an old monitor and keyboard so I can do the changeover gradually. Very happy. Big, robust case, the cabling inside is very tidy and it's much quieter than the last one - it's actually a bit eerie here in my mancave with the old one turned off.

For fun I ran some benchmarks to compare performance with my last desktop computer and a micro-pc (minako) which I use as a backup server.

Highslide Image Viewer

The new box (pop-os,named after the Linux version) is quite a bit faster than the last one (glower) and about ten times faster than the micro-pc for a CPU intensive job. The disk write test, involving writing 512MB of junk data to local disk, shows the NVMe storage on the new box to be about twice the speed as the NVMe on the old one, and about five times quicker than the SSD on the micro-pc.

But the graphics card is the most dramatic upgrade. Will try some local AI image generation later.

For perspective, that disk test that took less than half a second on the new PC would have taken about 25 minutes on the workstation I had on my desk in the early '90s, except that it didn't have enough disk space to accommodate 512MB.

[Slim]

I picked up one of my old computer mags, from August 1990. There's an article on voice processing, which of course was in its infancy then. "Algorithms today can capture speech using bit rates from a few hundred bits per second to a few hundreds of thousands of bits per second", it says. Fascinating. A few hundred bits per second would have sounded extremely crude.

It also states that an A4 page of information (in voice format) would take up "500,000 bytes", which would roughly be 32kbps. Then it says "this is clearly too much". And "voice systems tent to sample at a rate of between 6000 and 10000 samples per second".

These days it's trivial to store hours of voice audio at much higher sample / bitrates of course.

[Slim]

Just dug my old netbook out because I wanted to run the same benchmarks from the post before last. These are the actual tests:

jg@aspire:~$  time dd if=/dev/zero of=testfile bs=1M count=512 oflag=direct status=none

real 0m9.435s
user 0m0.009s
sys 0m0.411s
jg@aspire:~$  time head -c 100M </dev/urandom | sha256sum >/dev/null

real 0m3.569s
user 0m1.138s
sys 0m1.202s
jg@aspire:~$ 


My new desktop PC (much higher spec and 10 years younger):

jg@pop-os:~$  time dd if=/dev/zero of=testfile bs=1M count=512 oflag=direct status=none

real 0m0.312s
user 0m0.000s
sys 0m0.067s

jg@pop-os:~$ time head -c 100M </dev/urandom | sha256sum >/dev/null

real 0m0.287s
user 0m0.272s
sys 0m0.224s


Many times faster. The CPU test runs in less than 0.3 secs, compared to 3.6. The disk test: 0.3 secs compared to 9.5.

[Slim]

Still working on my Star Trek implementation which I have named Bash Trek, after the programming language I've used.

The following graphic shows the Enterprise in a quadrant with four stars. At the moment, I place the stars randomly. But there's a problem with this strategy, a potential flaw. It's possible, though improbable, that the Enterprise could arrive in a corner position, in the corner quadrant with three stars in the immediately adjacent positions. A sort of "three star hug". Were this to happen, a sort of stalemate would occur in which no move is possible.

Highslide Image Viewer

The odds of this happening in any given quadrant are 1 in 2480 and it's only a problem if the Enterprise is in the corner. Nonetheless I see that as significant - it's in "it'll happen one day" territory. So I'm going to change the way I place the stars.

At the moment what I do is shuffle the numbers 0-63 and pick the first four (or fewer) for the stars.

So what I'm going to do instead is place each star, check that it isn't adjacent to any previously placed star and if it is, add repeatedly add 3 to its position (the index into the array of positions) until it isn't. Because 3 is coprime with 64, steps of 3 would visit every position eventually. Actually all odd numbers are coprime with 64, because it's a power of 2.

So no two stars will occupy adjacent positions which I think will be nicer aesthetically. And the configuration above in which two stars are next to each other diagonally will not be possible.

The test for non-adjacency is simple: if the absolute value of the difference in the two index values is 1,7,8 or 9 then the two stars may be adjacent. If not, they can't be. This is where the index for the top-left position is 0 and the bottom right is 63.

[Slim]

My Star Trek project is pretty much finished now. Perhaps I'll do it again in a different language one day. So I've been thinking of what to do for my next coding project, and I had the idea of implementing a version of Conway's "Game of Life", again in BASH, and again in a terminal. Again this is something that was common on the microcomputers of the early '80s, and again something I once wrote in BBC BASIC.

Life is a "cellular automaton". It uses a two-dimensional grid of cells. Each cell is alive (or "on") or dead (or "off"). You start with a simple pattern of live cells and watch the pattern grow, as though organically, according to simple rules:

• A live cell with fewer than two live neighbours dies
• A live cell with more than three neighbours dies
• A dead cell with exactly three live neighbours springs to life
• A live cell with two or three live neighbours remains alive

Much more info here.

I thought this would take me a week or two, but I had the whole thing done and dusted in a day yesterday. What I'm particularly pleased about is that I was able to incorporate mouse control - in the phase of the program where you set cells alive for the initial pattern, you click on a square on the grid to toggle on/off.

I may optimise it a bit.

There's a very good online version here: https://playgameoflife.com/

It's quite a fascinating toy. Some patterns repeat, some fizzle out to a completely dead grid, some give out pretty patterns for 30 or 40 generations then get stuck.