Pyramid #3/37: Tech and Toys II

[Flyndaran]

If the Antikythera counts an analytical machine, then does that make a slide rule one too?

[seasong]

Technically, he said computational device, which is a broader term than analytical (it includes things like counting on your fingers), but still . . . Obviously, there are different cut-offs you could make for an analytical device.

A slide rule is a mechanical, analog computation device. It has a storage of a few bits (context-sensitive bits, unfortunately). And it can make certain dedicated calculations . . . although it has no conditional branching or algorithmic processing. The user has to provide that out of his or her own brain.

An abacus is similar, but has slightly more storage.

The antikythera mechanism appears to have similar storage to the abacus, and manages a quite complicated, dedicated algorithm. It still has no conditional branching.

None of the above items are programmable in the usual sense (technically, the antikythera was programmed when it was built - firmware rather than software).

A Jaquard loom is programmable, is capable of quite sophisticated algorithms . . . and has IF..THEN branching, although it lacks any equivalent to GOTO. So it almost qualifies as Turing complete.

Pretty much anything above the level of the Jacquard loom is Turing complete. As soon as you add GOTO functionality, the computer can do anything a modern computer can do, given sufficient time and a correctly written program.

[vicky_molokh]

Originally Posted by seasong

A Jaquard loom is programmable, is capable of quite sophisticated algorithms . . . and has IF..THEN branching, although it lacks any equivalent to GOTO. So it almost qualifies as Turing complete.

Pretty much anything above the level of the Jacquard loom is Turing complete. As soon as you add GOTO functionality, the computer can do anything a modern computer can do, given sufficient time and a correctly written program.

This is really ironic, considering that there seems to be a trend towards removing GOTO from many implementations, and not telling newcomers that there is such a thing as GOTO.

[seasong]

Originally Posted by vicky_molokh

This is really ironic, considering that there seems to be a trend towards removing GOTO from many implementations, and not telling newcomers that there is such a thing as GOTO.

Most newcomers are completely unaware of Assembler programming in general :-). I can't help but think that's a good thing, though.

At the level of high-level languages, GOTO gets a lot of syntactic sugar: loops, subroutines, abstract data types, and so on are all GOTOs with a layer of abstraction to make specific uses of GOTO easier to think about and program in.

[vicky_molokh]

Originally Posted by seasong

Most newcomers are completely unaware of Assembler programming in general :-). I can't help but think that's a good thing, though.

Wouldn't it be more properly called JMP in that case?

Originally Posted by seasong

At the level of high-level languages, GOTO gets a lot of syntactic sugar: loops, subroutines, abstract data types, and so on are all GOTOs with a layer of abstraction to make specific uses of GOTO easier to think about and program in.

Oh, there are, and those sugars are extremely sweet. I remember being shown how something as simple as
if(a==b)
where a and b are strings, actually requires looping and other mildly tangled stuff; it was enlightening*, and seriously boosted my respect towards char arrays (among other things).

But sometimes a simple goto is all that is needed.

* == I'm saying this as someone who can get by with only slightly above-default level of Computer Programming, at least so far; of course, I'm gradually trying to improve it.

[seasong]

Originally Posted by vicky_molokh

Wouldn't it be more properly called JMP in that case?

In the x86 architecture, it is JMP, MOV, or POP (all types of GOTO). Or Jxx, where xx is replaced with a conditional sub-code. In the Motorola 68000 architecture, it's BRA (or Bxx, with xx being the same as for Jxx). Other architectures use other opcodes.

Most of my reading in that area has implied that GOTO is the general term.

Please note, however, that I don't program in Assembler. What little I know comes from a vague interest in the under-hood mechanics. There may be a term other than GOTO that is more generic, more correct, or more understandable, that I'm simply not aware of.

[Huyderman]

Originally Posted by seasong

Most newcomers are completely unaware of Assembler programming in general :-). I can't help but think that's a good thing, though.

At the level of high-level languages, GOTO gets a lot of syntactic sugar: loops, subroutines, abstract data types, and so on are all GOTOs with a layer of abstraction to make specific uses of GOTO easier to think about and program in.

You really start to appreciate things like 'if ... then ...' and 'for' when you can't use it... It also makes you appreciate exactly why modern programming paradigms encourage against goto's, when you loose all sense of scopes. ;) But I digress...

[vicky_molokh]

Originally Posted by Huyderman

You really start to appreciate things like 'if ... then ...' and 'for' when you can't use it... It also makes you appreciate exactly why modern programming paradigms encourage against goto's, when you loose all sense of scopes. ;) But I digress...

Speaking of then, I think THEN went the way of the dodo lately too. But that's not a big issue. The big issue is the difference between the assumption that WHILE is followed by DO (or vice versa), and the assumption that WHILE and DO are standalone keywords.

[seasong]

Five Year Thread Necro!

When I wrote the Thinking Machines article, I left out software for a few reasons, of which space constraints were a big one. But I keep coming back to it, because I am a masochist.

Below is a very rough guide to converting HT and UT programs into Thinking Machines programs. This does not result in realistic programs, anymore than HT and UT produce realistic programs -- this is a pure, direct conversion of the results, after combing through both books and extracting general use rules.

Most TL9+ Software

Complexity 5 or less, subtract -1 (4 is 3, 5 is 4).

Complexity 6-7 becomes 5.

Complexity 8-10 becomes 6.

Complexity 11-13 becomes 7.

Complexity 14-16 becomes 8.

...and so on, except for the special cases noted below.

TL6-8 Software

Use Complexity as listed, except for special cases noted below.

Software Tools

Complexity 2 for IQ-based TL skills of any difficulty, and modify by +1 or +2 Complexity for good or fine normally. This lines up the requirements by type of machine reasonably close.

From about TL9+, the Complexity rapidly becomes unimportant, and by TL10, it simply doesn't matter: owning a computer is probably sufficient.

Note that rules-as-written mean that an espionage agent in a 1963 spy thriller requires a one-ton mainframe to stay on top of popular culture, put on a disguise (or cosmetics!), or render first aid.

Artificial Intelligences

Assign two costs: one to develop the underlying software, and one (called pseudo-Complexity) to program the expertise. The underlying software determines what hardware is required. The pseudo-Complexity is only used to determine the additional development cost.

For the underlying software, a late TL7 Dedicated AI is Complexity 4, and requires Computer Operations to use. A late TL8 Dedicated AI is Complexity 5, and can respond to voice. The expertise has a pseudo-Complexity of (skill/2)+1, which does not impact performance -- this is purely a measure of the effort to program it.

A Non-Volitional AI is Complexity 6. The pseudo-Complexity of building real intelligence into it is equal to (IQ/2)+2.

A Volitional AI is Complexity 7, 8, or 9, depending on how hard a problem you think it should be. Pseudo-Complexity is (IQ/2)+3.

Encryption

Encryption is very, very difficult to abstract in a gameable and realistic fashion. Use the default software Complexity conversions above for "gameable."

Realistically, how encryption works, the Complexity required, the gains possible, and the time and difficulty... all changed in sizable ways every decade from the 1930s to the 1970s, and some of those changes were not technological but political. I.e., if you want realistic encryption for a particular era, do some research ;-).

For a vaguely more realistic approach that can be applied in a general way, use the Invention rules to find a way to crack a specific type of encryption (Simple at TL6-7, Average at TL8, and Complex for TL9+), and to patch the exploit once it is discovered. Once an exploit is acquired, actually decrypting arbitrary communications is trivial.

Cracking passwords is a bit easier, and depends on how good the password is and how well-protected it is. If the password is well chosen and well protected, it is effectively impossible to crack -- use the Invention rules, as above, instead.

Protection consists of two basic elements: can you acquire the stored string, and how well encrypted is the stored string once you find it.

Acquiring the stored string is usually a matter of hacking a system to get the list of stored passwords... which can be a website, a server, or an open database API. Use your preferred hacking rules normally.

Once acquired, there are three basic possibilities:

1. Well-encrypted. A terrible password (about 25% of users) can be cracked in 1d¥10 minutes on a laptop, no matter how well encrypted it is. A good password is effectively impossible.

2. Poorly encrypted. You can use a pre-generated rainbow table! A terrible password in 1d seconds, a good password in 1d¥10 minutes. Generating a rainbow table for current encryption methods takes years, but a poorly implemented encryption standard may only take months, or weeks, or days.

3. Plain text. You're done, and somewhere a cute puppy cries out and is suddenly silenced.

[Flyndaran]

Sweeeeeeet! That was one of my favorite articles of all time. But it missed that piece about programs making it harder to wedge into R.A.W.
Thanks.