StuChat #38
(Please note that this is a personal page and does not necessarily reflect Lightsoft views nor policy)
MOD
Players
Fantasm - History
& Future
And talking of the
future...
ArcTan (Part III)
Late Night Conversations
- A.I. Revisited.
So, another year ends and a new millennium begins. I thought it best to get a StuChat out before the end of 1999 and I'm pretty sure Rob will get a Random Rob together as well. Because it's been a while since I last did a StuChat this is a bit of a "Bumper" issue. I started this one a while back; it's now Boxing Day 1999. I'm sat here in my fave comfy chair in the living room banging this into Word with Fish's "A Kettle Of Fish" on the CD. Cath is watching the telly and Jess is playing with her new 'bike' she received from Father Christmas.
Most of this one is personal and lacks any major coding type stuff; more a little reminiscence seeing as we are coming up to the end of the century, nay, millennium. In this edition I thought you might like to read a little of the history of Fantasm, where it's come from and where it may be going to. Actually, whether you want to read about it or not that's what you'll get :)
In addition I'll cover the history of Lightsoft; where it came from and again what will likely happen in the near future. We'll also revisit the ArcTan discussion, this time touching on speed versus accuracy first discussed in StuChat36 by Ranko Bojanic and followed up in StuChat 37. Contributors this time are Ranko and Rupert Kapp-Rawnsley; my thanks to both.
Finally (and by far the largest section of this StuChat) I have some general discussion this time from a conversation Rob and I had the other evening regarding, amongst other things, the nature of invention leading onto the nature of intelligence.
On a practical point of order, this one was produced over a few days. I really tried to do it all on a PC just to see if it was possible. Unfortunately during a conversion to HTML earlier today, Word 97 completely buggered up the whole lot. And HTML layout editors on the PC are quite frankly pathetic, so here I am on my old faithful G3 and Clarisworks/Pagemill doing the final layout and undoing Word's disaster - not fun on >6000 lines.
Thanks Bill.
MOD players
BUT FIRST.... Mod players. You know those hard to write little players we all love - they play MODs, S3M, XM etc - no battery required for a CD drive and absolutely billions of gigabytes of content to download off t'Net. Yes, it's been a while since I've even remotely touched the area of MODule music on the Mac but anyway, here's the story.... But even before that, grab a nice cup of your fave beverage, get comfy in your seat and read on.
I've recently had reason to work on a PC (hiss!) laptop and of course almost the first thing one has to do after the IT department has finished making sure it's just about serviceable enough for one to actually work on (email is still not working) is get a MOD player. (I'm not sure if it was luck I got a laptop or by design. Either way, even if it is a PC box, they'd get it back over my dead body :)
Now I knew nothing of PC mod players having lived with AnvMOD for the last three years and that's based on the PlayerPro library so I know little of its inner workings. But anyway, the fact is that these guys on the PC are really whooping our collective arse when it comes to sound quality out of a MOD player. Seriously. I'm using XMPlay 1.6 and the sound quality is fantastic compared to anything we have. I'm hearing things I've never heard before in MOD's I've been playing for years on various Macs.
So, my question is, "why?" Why do they have better MOD players than us? It's not fair. Is it because they "know" how to do it and we don't? Is it because nobody in Macdom can be bothered? Either way it's a pretty sad state of affairs. Somebody do something!
And in a similar vein, we all know how important music is whilst programming. Recently I've been looking at these small MP3 players you can get. They cost from about 120 UKP and up. Unfortunately what you get isn't really sufficient as yet. For example even an expensive one with 64 Megs of memory is barely large enough to hold an hours worth of music and that'll set you back close to 180 UKP.
No, what I want is something
similar to:
| Runs Linux or OS X, has a >4 gig hard drive, >64 Meg of RAM, a decent 16 bit DAC to the headphone socket, is the size of a wallet and speaks both USB and Firewire. Even better why not incorporate my mobile phone and whilst we're there do my email as well! |
Fantasm - History & Future
Now then Fantasm. Where did it come from, why, and what will happen to it in the future. First the history.
It all started way back in the mists of time. I was in the R.A.F. working on simulators and had plenty of spare time; professionally I was programming in CCC assembly language, Coral and ForTran. I was posted to a pretty quite place with little in the way of actual work so I was getting lots of spare time to do my own thing. At the time I had an Atari ST which I pretty much knew inside out. I'm also pretty handy with a soldering iron and wanted to explore outside of my little sleepy hollow. I read a lot of electronics mags and had designed various comms type things before, being a keen SWL (short wave listener). Anyway, I knew I wanted to build a modem having designed and built many receivers. I went through three discrete versions before finally getting one that actually worked reliably at 300 baud (this was with the ST providing lots of the capability such as actually dialling by toggling the line in pulse mode). Anyway after searching around for a few days I found a bulletin board called the Bullring which was located (strangely) in the Bullring, Birmingham (about 150 miles away from where I was stationed). There were lots of good people on there and I was just so relieved to find out there was actually real people who knew as much about the ST, if not even more than I did! It was a dream come true.
I must admit those bulletin boards were really community areas not readily apparent any more these days. The web is great (isn't it?) but it just doesn't seem to build the same feeling of community found when nearly everybody had real slow/crap/home made modems. Anyway, one of the people on there was Rob and we were getting on OK as I remember, but it wasn't "famously" because I didn't know what he had been doing and vice versa. At about the same time I had emailed ST Format(which was a magazine for the Atari ST) a small program I had written to display the amount of free memory on the desktop. ST Format put my program on the cover disk and everybody in the whole world knew about it. Except me of course.
I think at that point Rob must've realised where I was coming from and possibly wasn't just "full of it" as many people were at that time. I was also working on a text based adventure system (which had been ongoing for a few years, first in Z80 (Einstein) and then 6809 (Dragon 32) and finally 68K on the ST). It turns out that Rob also had some long term projects "on the go", it also turns out that both Rob and myself "cracked" Jet Set Willy (on the Spectrum - see Random Rob for details) at almost exactly the same time. So we had a bit in common.
We then started swapping code. Rob had been doing some graphics stuff and I parsing and some 3d stuff (because I wanted to write a "space game" Hey! Who doesn't?). After a period of time we finally decided to write something together. Thus was born Fantasy (according to my recollection, I'm sure Rob will correct me if I've got it wrong.)
Fantasy was (is) an adventure game with real time 3d graphics and a traditional text based engine as well. Of course we only wanted to simulate the whole bloody world (being rather naïve when it came to project management) and so spent about two years coding every spare second. It was going OK too. We had weather, terrain, flocks of birds, seasons, a real world system which did actually allow us to model absolutely huge amounts of area (based on blocks and mini blocks so we never had more than what was the really necessary geometry data to handle) etc. The only problem; the environment we were using (DevPac) was getting really slow even if it was a brilliant environment.
So one day I decided enough was enough and plumped down almost a grand for an 030 based Mac. It was great, the only problem was I could not find a cheap enough environment that was easy to use. I tried all sorts - there was a couple of versions of Forth, Harvest C (remember that? Do a Sherlock search), a variety of Basics but no cheap assemblers. Grrr.
So we decided that because I had a Mac and Rob still had an ST I'd have to write a 68K assembler. Oh boy! I spent about 3 months making sure I got all the groupings right (I finally got it down to about 13 major groups of instructions that could share code to get assembled). Previously I had written a Z80 assembler and simulator so I had a rough idea about how to write one and about 6 months later we finally had an assembler that could assemble itself. It was written on the ST in DevPac and then moved to the Mac on a floppy for testing. When it finally could assemble itself development moved to the Mac full time. Indeed to get it moved as quickly as possible I wrote more than a few lines of hand coded machine code using the dc.w directives (indeed that was the first directive to go in :)I'm probably the worlds laziest programmer, so I had to spend a great deal of time getting the assembler smart enough to cope with my relatively bad syntax. I don't want to remember where I should use adda instead of just plain add so I got Fantasm to do it for me; again the same with basic 68K optimisations such as moveq. This is extended even further in the PPC assembler of later versions - I really don't want to manage the TOC by hand.
At this time Fantasm had zero interface, no build manager, linker or virtually anything else. It just assembled a file to an executable. Anyway, it was usable and I posted it onto the MacLincs BB with a note saying that anybody who found it useful could send me ten pounds if they wanted. As it turns out lots of people did and somehow it made its way onto the Internet (as it was five years ago) and I started getting mail from all over the world which was great.
Anyway we carried on with Fantasy on the Mac. We still have it and it does actually run albeit rather clumsily. More people were actually paying for Fantasm which is the greatest feeling; to actually have people pay you for software. I found it quite remarkable and indeed a life changing event.
So we got hold of more Inside Macs and found out about the 32K text editor and hence was born version 2. This version actually had some useful menu commands and a very simple build manager which would take a text file of commands and run through them. I'm also pretty sure Link68K might have made an appearance in version 2, so multi file building was a possibility.
This was all pretty useful but a 32K text editor is nothing to shout about. But the one thing it did get was my basic philosophy that one shouldn't lose a file because ones Mac crashes (yet again) as it does when developing, especially in ASM. It wouldn't even look at running the program without saving all files (if allowed from its prefs.)
So then came the worst version, or more correctly more bug fixes than you can shake a stick at; version 3 with Eddie. We had two separate programmes. The first being Fantasm, the second was Eddie the editor. I'll let you into a secret here; I spent ages trying to get these two programs talk to each other. Apple Events was a non starter as being far too slow (it was dog slow in those days) so I dug deeper and found the PPC toolbox. This was faster but still too slow. I finally figured out a Heath Robinson method of getting Eddie to search Fantasm's heap for a specific sequence of bytes and then claim that as the comms buffer (Eeek!). Anyway it worked and was extremely fast; a kind of shared memory mechanism whereby a protocol would keep everything synchronised. I think we went through about 18 versions of 3.xx; bug fixes were almost weekly, but it was a step in the right direction. Eddie had syntax colouring and was IMHO pretty much the fastest (if buggiest) editor around. Anyway, the best thing to come out of version 3 was the comms syntax between Eddie and Fantasm. You can read all about this in some of the older StuChats.
After version 3 I was able to leave the RAF and work on it full time.
About this time we got some PowerMacs and thus was born version 4. Again 4 had its fair share of bugs, but the later versions (4.18 onwards) were pretty stable. Version 4's main claim to fame was its PPC assembler, which took about 3 months to write (compared to over 7 months for the basic 68K one). Version 4 provided for more powerful macro handling, such as looping constructs. The PPC linker was a different story as docs were simply not available on the XCOFF or PEF formats. The PPC linker is probably some of the hardest code we've ever had to write. Version 4 had a long life BUT the big mistake we made was doing two versions; one 68K only and one for both 68K and PPC. It created a lot of work; not from a development point of view but admin was horrible. By 4.18 it was all done; stable fast and had most features people wanted. What to do now? Well we really wanted to get away from Eddie and Fantasm, all in one was what I wanted, so we spent a great deal of time designing an interface that would allow first modularity and secondly robustness.
There was about a year and half of sheer design; the outcome of which was Fantasm 5. This did away with the text based build file and provided automatic dependency checking and maintenance. I also went to town on the macro facilities in 5 providing useful string facilities and user variables. We wanted version 5 to be a fat binary, but we had a problem in that it was all written in 68K assm! So I simultaneously designed a low level portable language based on 68K assm and provided Fantasm with the facilities to deal with it; thus was born LXT, Anvil and Fantasm 5 all at the same time. Of course Anvil was written from scratch in LXT but Fantasm had to be converted. This really wasn't a big deal as LXT will take pretty much raw 68K source and convert it to PPC. It ran but was too slow, so I added a bunch of extensions using the "q" form; qmove for example is the same as a 68K move instruction but sets no flags. Version 5 was OK in my opinion, it wasn't great but it did what it was designed to do, and as it was the first implementation of Anvil it was an engineering success (again IMO).
Anvil 2 came out in Fantasm 5.2 (if I remember correctly) but I can't remember what specific changes there were over Anvil 1.
As soon as Fantasm 5.2 was out I started on Fantasm 6. This again was a major design effort. Anvil 3 whilst sharing the same name as its predecessors is completely rewritten. I can't tell you what its main claim to fame is; I don't know. It has many changes over Anvil 2; it talks to tools much faster and more securely; it can handle almost any language and allow the user to define their own; it can talk to MrC and other "alien" tools. Fantasm 6 (the actual assembler) again contains new code, but this time it's mainly replacement stuff; new memory management; updates to the AltiVec core etc. Nothing drastic; if it ain't broke don't fix it is my philosophy here. IMHO I think Fantasm 6 is great; it's where I want it to be. We still have a few small buggettes left to kill, but I've been using Fantasm 6 and LIDE 3 for over two years for both Assm and C with no problems.
I am thus a happy and content proggy.
Now that Fantasm 6 is nearing the end of development (I've had to do very little work on it in the last three months) our priorities have changed and we can plan out what happens next. I figure Fant 6 / LIDE 3 will go out in the New Year and will probably be the last 68K build we do (indeed we have no 68K Macs left so we can't actually test the 68K build).
OS X client will be out shortly and we'll evaluate it. If it looks like a "go-er" and is being adopted we will produce a version to run on it. That will obviously be a PPC build only.
So that is Fantasm's history and future. I've enjoyed it and look forward to extending/improving it in the future.
And talking of the future...
I have taken a nice programming job in Scotland and will be moving in the New Year. This means I no longer "do" Lightsoft full time and as such have to make it easier to manage. I expect Fantasm to be moving back to its shareware roots. If we can make it easier to administrate then we can drop the price.
I'd like as many people as possible to be able to afford it; LIDE 3 as well has handling Fantasm also allows one to build C/C++ projects and I know a lot of people moan at the price of other C environments (not that there's a great deal of choice on the Mac). So my aim is to make Fantasm 6 and LIDE 3 as affordable as possible; just enough so Lightsoft covers its own overheads. Our aim is to make Lightsoft as efficient as possible; any suggestions are more than welcome. LIDE 3 comes in at under a 10 Meg download with all installed which isn't bad, so I'm hoping we can do the whole lot without CD's or any of the other baggage.
I'd also like to help out where I can; I'm looking at some open source stuff albeit rather tentatively at the moment. Until we're settled in Scotland I don't know how much spare time I have and I'm already pretty committed work is rapidly approaching "crunch" time (what a time to join a project eh?). I'd like to get some more tools plugged into Anvil and like the GNU stuff; whether it's possible from a licensing point of view I don't know should be. We also have Zex in the works; indeed in the next StuChat I'll probably be covering basic OpenGL stuff as I have found it particularly difficult to actually get to work properly. Probably because Apple's implementation does not yet support things it should do on certain cards, and indeed certain cards drivers are not yet out of beta :)
Now moving ever onwards, some more on arctan.
Rupert Kapp-Rawnsley wrote me regarding the ArcTan item we covered in StuChat 36 and revisited in 37. Rupert put up a page at http://www.cs.cf.ac.uk/User/R.Kapp-Rawnsley/arctan/arctan.html.
I reproduce portions of the text here with Rupert's permission. Please go read the full article as Rupert makes some interesting observations and presents practical implementations; I'll merely comment on parts I feel need to be clarified on my part. Rupert's text is in italics.
In the StuChat implementations,
the angle is stored in degrees as an integer value. This raises
issues which are discussed in the next section.
This is purely
an implementation issue; the caller wanted its result in degrees
and so the fastest method is that the atan function returns its
result in degrees
Speed of lookup
versus rational approximation
It is stated
in StuChat #37 that the rational approximation method is quicker
than the lookup method. This seems very unlikely as the lookup
method requires two multiplication's, one to transform the tangent
into a bin number and the other to create a pointer to the correct
bin (array de-reference). The rational approximation method requires
two multiplication's, one addition and a division (for the simplest
approximation x/1+ax^2). It may be that compiler optimisations
(such as pipeline packing) may effect the relative speeds of
the two methods but this can not always be guaranteed.
It was this result
that surprised me so much. I would have fully expected as Rupert
states that the look up would be faster. However I feel I can
explain why the rational approximation method could be faster
if one considers the dynamics of the memory bus in an actual
application. The various implementations of arctan were timed
both in a game (where the memory bus bandwidth is a major bottleneck)
and also with Ranko's Arctan_speed_combined testing application
[download].
Given that the FPU in a PowerPC processor is an independent unit
running in parallel with the integer and branch units it may
well stand as a valid result. On other processor architectures
the results may be different.
Conclusion
If a fast
calculation of arctan is required then one of the two methods
outlined above may be employed. Once the required accuracy is
known, a calculation of the number of bins required by the lookup
approach will lead to a storage requirement. If the required
space is acceptable then lookup should be chosen, if the required
space is too large then the rational approximation method should
be employed.
In addition, I
would suggest that both implementations be timed for a given
target processor if this function is at all heavily used, and
the result of the timings should be the basis of the selection.
Ideally the timing would take place in the actual application
the function is called from to ensure various run time dynamics
are accounted for.
I passed Ruperts observations onto Ranko for comment; here is his [edited for space] observations:
|
Rupert writes... We have found already that rational approximation
x/(1+ax^2) with The evaluation of 1000000 random numbers in (0,1) produces on my Macs the following results:
[I would attribute the iMac look up time to its faster memory bus - Stu] The accuracy is however
much better with rational approximation. look_up(x) = arctan( [20*x]/20
) I have added to the enclosed
mini_plotter [download]
the graph of this function as the 14th graph. To see why we have
the accuracy |arctan(x) - look_up(x)| <= 0. 05 arctan( [20*x]/20 ) -
arctan(x) |
Late Night Conversations
Rob and I had a very interesting conversation the other night. It all started with a discussion of inventions of the twentieth century; what were the real innovations and how much was just evolutionary progression.
Invention is hard. Try it you have five minutes to invent something starting now.
How'd you get on then?
Invent anything? Nope? Well there's no surprise there. I tried
it myself and the best I could come up with was:
| Small fans to fit on aircraft wheels so when the aircraft lands it doesn't burn a ton of rubber off the wheel as it touches down. The fan would start the wheel spinning as the undercarriage is lowered into the air stream. |
To come up with that has taken me a good few hours and quite frankly only came about because I remember watching planes land and wondering if they really needed to wreck their tyres so dramatically! (Hey, if anybody actually implements that (if it isn't already) cut me in for say 20%, I don't have the time nor inclination). Unfortunately that is not an invention in my opinion; it takes the need to rotate something (the aircraft wheel and tyre) and finds the simplest and cheapest solution a plastic fan.
So given my criteria for what is and is not an invention, consider television. Was it just an evolution of radio? No, and the advancement to colour television using the PAL (Phase Alternating Line) or NTSC (National Television Standards Council or more correctly Never The Same Color?) system isn't either; each required specific design and invention. Is the internal combustion engine an evolution of the steam engine? In my opinion yes it is; a reciprocating design driven by expanding gas in the case of the internal combustion engine and gas under pressure (from the boiler) in the case of a steam engine.
Looking even further back, has anything major been invented? What if we look at electricity. Was this invented? No; it's always been present. Maybe the understanding of its nature helped develop the electric motor and similarly the generator; a motor running in reverse apply a mechanical input to produce an electric current output; no major invention required (asbestos suit donned already :)). Indeed if there is an invention there it is in the commutator in a DC motor.
Maybe we should look to other areas to find a more worthy invention; how about semiconductors; was the semiconducting diode and hence the transistor, an invention? Looks likely to me although I'm not sure it was planned that way; were they looking for a replacement to the thermionic valve? Was it a major invention? Oh yes. Was it the invention of the twentieth century? Maybe but it's not truly earth shattering in my opinion.
How about the computer then? Nope; just evolution upon evolution. There isn't a computer in the whole world that isn't basically the same as any other computer and the standard design was born out of previous calculating devices; it is impossible to say when or where the computer was invented; it simply wasn't. The idea of 'programming' a calculating machine was an invention but unfortunately so was the idea of programming weaving looms with punched cards (Hollerith), and as devices such as the humble abacus have been around since the year 'dot' I have discounted computers as being 'invented'. It is true that certain computing architectures, such as the Harvard architecture, were genuine innovations worthy of mention but in the truest sense of the word not an earth shattering invention. Most invention in the field of computer hardware was pretty much thrashed out by the early Seventies. Intel in particular are especially fond of taking an existing mainframe technique and applying it to their microprocessors for example pushing more current through the chip to reduce switching times and hence increasing the clock speed.So, what then in my opinion was the invention of the century? Answer: Genetic programming techniques. Surprised? Please read on
Genetic programming is the technique of using a pool of programs made from initially random instructions which are run and then scored depending on how well they achieved a specific task; those with high scores are allowed to breed (swap genes, or instructions) and those with low scores are culled (typically the lowest scoring 10 percent). The real hard bit is 'scoring' the programs; deciding which is a good sequence of code and which is bad. However, these so called 'genetic algorithms' or simply 'GA's', can achieve remarkable results in a relatively small amount of runs, or 'generations' as they are called.
Seeing this in action first hand through experiments has filled me with awe. In my opinion a good part of the future of computing can be found in genetic programming. Admittedly it's not really an invention, drawing more on nature than probably most 'inventions' but even so, it gets my vote. These techniques will allow complex code with zero bugs to be written; something that cannot be said of code written by humans with rates as high as 4.5 bugs per hundred lines of high level code being all too common. Imagine saying to your dev. environment "Give me a function that takes these inputs and has to produce this output." It chunters away for a short time and produces the perfect code for you; not canned code but written specifically according to the specification and as optimised as it gets. All possible today folks.
Now take that a generation down the line; and then another. Scary
huh? Maybe it's too abstract, right? Wrong; people are looking
at using these techniques in all kinds of applications; myself
included. As processors get faster it will be feasible to run
thousands of generations of 'solution' in an instant of time.
Have a problem? The computer has already generated the perfect
code to deal with it almost before you've finished defining the
problem and can then be refining the solution as it puts the
best first run of code into use. Consider our ongoing problem
of driving a car; could we not get away from the traditional
programming technique of hard wired code being designed to deal
with all eventualities and generate code on the fly to deal with
each situation as it arises?
I realise this sounds pretty far fetched but consider our 'bag on the road' scenario whereby the car is driving down the road and 'spots' a paper bag directly in its line of travel (see previous StuChat's and Random Robs). The car's sensors 'spot' it; the processor starts running a genetic pool of programs scoring on the "best" outcome of their execution and very shortly has the perfect solution to the problem. It may be 'swerve', 'run over it', 'stop' or whatever is deemed the 'best' course of action depending on certain driver input (I want to get to B safely; I want to get to B as fast as possible etc.)
That then is my nomination for Invention of the Century; Genetic Algorithms. Let me know if you disagree and why; I'll more than happily publish follow ups. But we're not done yet...
This discussion of inventions somehow led to a discussion of the definition of intelligence; as it sometimes does (and we were sober!!!); unfortunately we ran out of time and had to go to bed but I remember [we were] talking about Arthur C. Clarkes HAL in 2001. The basic premise was that of giving a machine enough 'intelligence' to cope with basic understanding and then teach the machine more as time went on. A beautifully simple concept. The problem we had was determining just how much basic information is needed and how would it be organised and maintained?
This dear reader is just about the Holy Grail of pretty much every computing discipline known to us. If we knew the answer to this I wouldn't be sitting in my fave comfy chair (tm) typing out this into a somewhat bloated word processor. No, I would be typing out this in some exotic location; indeed I wouldn't be typing it at all, I'd be dictating it to 'Son Of HAL'. However, it is an interesting question; just what exactly is needed; what is the basis of consciousness? What is the essential definition of intelligence? What, God Damn It, is the meaning of life? Anyone who's read any Douglas Adams will know the answer to be 42 as given by Deep Thought after many years deliberation, and indeed maybe it is that simple. Just as we have seen many modern inventions found their sometimes underlying but more often than not their primary principles in nature; maybe the secret of [perceived?] life is also so close at hand?
Or maybe not. We looked at what the primary goal of any living thing was. Answer: Survival. It dawned on us that there is this unconscious question always being asked whenever some conscious entity receives an input; "Is there any danger to me and if so what impact will it have on me making my pension?"
This one question is repeated almost ad nausium (to an observer) throughout an entities entire lifetime; and yet it [the entity] is probably completely unaware of it UNTIL the answer is 'Yes'. And then of course the fight or flee mechanism raises to the surface and the entity acts accordingly. Of course this may be an ongoing long term response, or a brief twist of steering wheel when a juggernaut comes ploughing towards us on the wrong side of the road. Either way, this repeating question is pretty important. If we go back to the first StuChat I surmised that knowledge of ones ultimate death drove sentient beings onwards; or may be not.
Going back to Arthur Clarke; he wrote that an intelligent person is never bored. Is this true? And if so what does it mean in our context? Does it have any impact at all on the problem of giving something that is not 'Flesh and Blood' enough brain power to pick up new stuff from interactions with real live things? Maybe. Maybe just the mere act of realising one is bored is enough to trigger a reaction to the boredom and hence stimulate 'thought' about something. Perhaps a little abstract but important nonetheless.
Another important aspect perhaps missing is the fact that most living things are always receiving a complete deluge of information from a variety of sensors. So much in fact that most of it is filtered out automagically before it gets anywhere near anything that may need to process it. For example the eyes pretty much act in two ways; firstly they examine the thing we are working on 'now', secondly they monitor for any change in the periphery of our view, especially fast changes. This change seems to be differentiated into some kind of priority input we can't help but examine. It's the old "Is it something that may hurt me" question being automatically and relentlessly processed.
Thus it may seem that a complete replica body might be advantages when it comes to producing some kind of intelligent device. But is it necessary? Not really, it's a help but doesn't answer the question of how to simulate or emulate demonstrable intelligence. What is needed is a 'basic' simulation of a baby; more specifically 'the mind of a baby'. We need to know how much pre-programming is present and why. How for example does a baby 'learn' what the word "Hello" means? We know we repeat it many times over and eventually the baby will repeat it, badly at first, and finally grasp its meaning. How?
I'd suggest that kind of thinking is at too high a level. It's the ultimate goal. The baby, even at birth, has a variety of mechanisms already fully functional that we can't even begin to replicate. For example it has the ability (and this is an important one) to differentiate patterns and store them away from the very first breath. We cannot simulate this behaviour yet; we have not devised the algorithms necessary. And is it necessary? I believe so. The ability to recognise patterns is fundamental to reproducing sentient behaviour. And we're not talking about patterns of a specific type either, we know the patterns need to be analysed in a multitude of forms; pictures (mummy's face), sounds (mummy's voice), physical feelings (mummy's hair), real feelings even (I like mummy). All patterns that need to be stored, retrieved, searched, analysed and linked in next to no time at all. Or is this really the case; does practice and 'possible' future context allow us to anticipate likely searches and perform them before the results are needed? Possibly combinations of anticipation and flexible data management are likely.
All living things also posses what we call emotions, or indicators roughly showing what mental 'state' the living thing is in at any given time. OK, so it's maybe stretching it a little to say "all living things" but for the purpose of our discussion let's assume that to be the case. Consider the question "How are you feeling today?". There are at least two ways to answer it; either the polite "Fine thank you" or the more truthful form of "A little annoyed" for example. When we are answering in the truthful form do we analyse ourselves 'on the spot', or do we continually analyse our state, possibly even subconsciously? Are then emotions important to sentient behaviour? My best guess is that they are the crux of the matter. If we could give write a program to maintain and process a given set of emotions it might be an interesting experiment. At least it should be able to answer at least one question.
Emotions and the way they are changed and interact may be an offshoot of the act of consciousness or they may be more intimately tied-in to the definition. "How many are there?" and "Can we classify them into major and minor classes?" may be crucial questions. And is it possible for new emotions to be created from existing by modification or even from scratch? If this is the case it may be possible to start with relatively few and let our program generate new ones as it sees fit.
Now I personally wouldn't have a clue as to where to start programming that little lot. I'm sure it would probably frustrate even the world's greatest programmers and thinkers. However, maybe with a sprinkling of genetic algorithms creating and refining these necessary algorithmical mechanisms along with generating and selecting the best data structures for any given input, who knows?
Consider a baby learning the word 'Hello'. Let's make it even simpler and reduce the problem to just saying the word 'Hello'. Previously I believed the 'sound' was memorised, now I think it more likely a program that can produce the sound algorithmically may have been previously generated, stored away and invoked whenever I need to say 'Hello'. From a storage point of view it makes sense; it would probably require less actual storage than any other form of representation. After all, code, is just that; a code used to regenerate a specific result.
Finally consider the act of 'reinforcement' used in most kinds of training. When our baby says 'Hello' even remotely correctly, its Mother will smile and provide a positive feedback to the baby. Is this not analogous to scoring as used in the GA algorithm?
See also Random Rob 3 and StuChat for 6 May 1996 for additional discussion along these lines.
Sign Off
I hope you have enjoyed this little chat. I'd like to thank Rupert, Ranko and Rob for their input. As always I'm on the look out for contributions for the next StuChat; I'm looking for more on the arctan debate - is it thrashed to death yet or is it possible to arctan even faster? Taking that further, which is better. a multi-cycle solution where the number of cycles to solution is dependent on the input or again a table look up; specific case in mind: setting a bit in a byte given a number in the range 0 to 7
Also anything you may have on OpenGL specifically on the Mac (yes I know all the good references but personal gotcha's you've discovered, implementation specific tips etc are all more than welcome).
I also welcome feedback on this (good and bad) and previous StuChats or indeed anything you think may interest the couple of hundred or so semi-literate Mac-heads who visit us every week.
Heck whilst we're on holidays why not bash out a complete article on anything that takes your fantasy? For example: Why do programmers seem to have a facination with Tolkein? (as was pointed out to me by another programmer last week when I told him our server's name was Frodo).
If you want to chat about writing an article just drop me an email. I'm all 'wired' again now after being pretty isolated for the last month or so.
Until the next time,
Have a very happy New Millennium,
Code on!
Stu.
©Lightsoft 1999
©Stuart Ball &Robert Probin 1999
Legal: All material on this site is copyright © Lightsoft Software 1999 excepting third party contributions where copyright is owned by the individual authors. Lightsoft acknowledges such copyright and or any tradmarks associated with such contributions. Reproduction of articles or content in whole or in part is prohibited unless specifically authorized.
Fantasm, PowerFantasm, and Anvil are trademarks of Lightsoft Software (Tools). All other trademarks acknowledged.