John's Emails	strip links 7
To: frank@bio.vu.nl Hi Frank, >> Please clarify. > > In a sense my idea looks a bit like your web axons. I'm still thinking about > links in webneurons. > >>> Now this is just normal programming, I want to seperate the flow controle >>> from operators. >> >> Perhaps a few examples would help me to understand how you do this. > > First I think to include if in webneurons and for/while/untill not > is a bit strange because they are the same only specialised for > different situations: > > say whe have some subroutine (CODE) and use: > > FOR-LOOP > > for (int i=0; i<10; i++) { > CODE(); > } > > is the same as > WHILE LOOP > > i=0; > while (i<10) { > CODE(); > i++; > } > > is the same as > IF THEN LOOP > > i=0; > LOOP: > if (i<10) { > CODE(); > goto LOOP; > } > > As you can see, you can do the same with IF, WHILE and IF (with goto), > in this case for is the shortest. If you look again there is one important > step all take and this is using the < operator. > > To make the new programming languages self-similar I think we have to go > to the basics and this are data and operators. The operators are webneurons > (or hups). > > Can we agree on getting rid of all flowcontrol statements (if, for, while > etc.)? If someone whishes to keep on using then he/she can model them using > hups. I think that's "hubs" not "hups". One meaning of hub is "a central point of interest". I'm sort of glad you're talking in terms of general software neurons now rather than specific extended HTML based ones. To answer your question I would say yes, give this a try, keep the hubs as simple as possible. Many neurons are very simple in operation. Some just fire if the sum of all the inputs exceeds a threshold. However I hear that some real neurons can have thousands of links. This fits with the idea that it is the links which are more important than the hubs. I believe the key is the links. In the assembler version there are no IF statements etc, just a list of JSR (subroutine) calls that are executed one after the other. This is the "script". We can impose a limit of only one JSR per hub and see how it goes. I like the fact that this is a simplification of the basic building block, and appears to have no drawbacks. Building blocks should be as simple as possible. What about the data. Do we allow strings, pictures, Email, or just numbers. We could build a string from a series of hubs, each hub perhaps having only one letter in a "hubstore". This would make it easier to use the links for string analysis. If we take the analogy to speech recognition then each hubstore could represent one phoneme and we might be close to speech recognition! > The difference between my and your idea then comes down where to store the > the links. I think the should be stored seperately, and the possibility > to store them inside a hup in special cases. If the links are stored separately, then how will the interpreter know where to find them when it is running a particular hub. Also, what's left inside a hub if you store the links separately and there is only a single line script? The hub is nearly empty. How will the program run? >>> (when flow controle is >>> stripped you still can model a brain, not only this you can model many >>> brains!) > >> You can model as many brains as you like with standard weblets too, >> because the number of webneurons and links can be countless. > > It would be more work because you have to write new webneurons. > If coded seperatly you can use the same webneurons with different kinds > of link data. Surely what you seem to be saying is that we should use a webneuron library. But I have already introduced this in my Email of 21 June (webfuns & websubs (Re: webneurons part 2)). >> You can model a brain in a thousand programming ways, in many different >> languages. But most of these are tangled, and might take us a thousand > > yes, lets untangle the webneurons! :) the messy part of programming > are the links. I still don't think you have clearly stated your alternative. You have only given a few features, not the actual theory itself and how it works. What about the data. How does the program run? >> years to get to an intelligent computer. The question is - which way >> has the correct and most compact building blocks for the model, >> so that we may achieve machine intelligence in our lifetime. > > We can discuse the idea for millenia and still not agree on it. > I propose to agree to disagree on this point. What are we disagreeing about. I still don't know exactly what your alternative is so how can I disagree with it? >>>> We have to carefully think what properties a more correct programming >>>> method should have. >>>I'll start: >>> >>>- all properties of OOP >> >> Why? > > correction some properties of OOP Which and why? >>>- plus: a stronger seperation of data/flow controle/operators >> >> I don't really understand how (or why) you mean to separate them. > > I think the problem you (and a lot of people) have with programming > is the those concepts of programming are not seperated enough. > The real reason is a bit difficult to explain in a few sentences. > I hope from what I've written above (on seperating links > from webneurons) clearifies the seperation of data and flow controle > a bit. I would really like to hear the real reason. >>>- plus: self-similarity >> This sounds good, but what is it? > > You can zoom in and out of your maps. (the programming is the same > if you are writing very lowlevel (basic) 'programs' or more complex > 'programs', the whole trouble with other languages is the problem of > abstraction, in OOP they solved this with abstract class which forces > you tho think out the 'program' in advance which is rather odd.) I have not used OOP so I'm a little handicapped here. What you seem to be saying sounds similar to the concept of nestable webfuns, where you could keep zooming through nest levels but at each level the same method and structure (hubs and links) is used to program. By zooming to the next level you are zooming into another map. It is my guess that without knowing it, all programming languages are trying to copy the brain. Some get closer than others. Neural networks are the best yet, and can do some things much better than other languages. All software was invented in brains and it is somewhat illogical to think that the invention could surpass the inventor. >>>> I can't see how you can disagree that "mappability" must be one of them. >>>> Structured programming is not mappable, weblets are. >> >>I think structured or oop programs are mappable too, >> >>Impossible. To map you must be able to visit every part of the system >>starting from any point. If you start from a subroutine in a structured >>language you can only trace downwards to lower level subroutines. >>It is impossible to go upwards because there is no list of callers! > > And the reason you can call library subs. I agree that the facility to call library subs appears good, a reusable unit that does a standard job. But it could be useful information to have a list of all the places that called a library sub. If we can keep this information AND still use the library sub then we have only gained. >>This is why structured languages have been the most costly mistake >>in the history of computing (in my opinion). >>>but what I want is not drawing maps (the computer should do this) but draw >>>routes (=flow >control) on the maps. >> >>You mean like the arrows on the weblet diagram http://brain.eu.org/weblet.htm)? >> > Yep, The computer (or user or both) should select the hups which can help perform the task > you want to program. Standard hubs could be used from a library in this way as I already Emailed. This would be an obvious development rather than write out scripts all the time. But are you actually saying that the script itself should be replaced by a weblet? In other words hubs are much smaller than I have previously allowed for. In fact each library hub would only have a one line script? Perhaps in the library:- Hub 1 - set all outputs to max if any input is above a certain level Hub 2 - set all outputs to max if all inputs are zero Hub 3 - set output 1 to max if input 1 > input 2 Hub 3 - create another hub So you wouldn't write scripts, instead you would just select from the library and draw links. You wouldn't see operators anymore - they would still exist but be hidden in the library hubs. If so, then I like the sound of it (with reservations). How do you write a new library hub? > You draw the arrows. The computer stores the map data. > You can use the same webneuron in different 'programs'. Where does the computer store the map data and how does the interpreter find it when running a program? >>In weblets (so far) the flow control is handled in the scripts within webneurons AND by the map. > > How do you want to put the flow control in a map or why not put all flow control > in a map? > >>The FIRE command will cause other (linked) webneurons to activate. You can easily >>build a cascade (chain reaction) in this way. This sort of thing IS flow control. > >>If you have a cascade of webneurons and each webneuron fires all its targets using:- >>FIRE ALL >>in the script, then the flow is almost completely controlled by the map alone. > > I thought the order in which cascading hups get fired is important. > >>>> I really don't know what to say to convince you except what I have >>>> already said in previous Emails. I don't think you will be convinced >>>> except by trial and error on a live weblet system. By the way I have >>>> never had a fully live system yet, in any form. >>> >>>I think the rough idea should be clear and then it gets polished by trail >>>and error >> >> Yes. However, sometimes trial and error causes you even to change >> the original idea, often a major alteration. > > I'm a bit lazy :) I like to think out the basics before I make it. Probably very sensible. I'm more impulsive - pick up the pieces later. Your way is better but the wait is longer. >>>One more point about mappability: >>>The question, 'is something mappable?' depends on the position of the >>>observer and the information he/she has, in other words is relative. > >>When talking about mappability I am assuming that the observer is of the >>same approximate "size" as the things being mapped, and can be positioned >>at first on any one of those things. He/she does not have any information, >>just the ability to wander from one thing to another thing by following links. >>For example a man might explore a maze, or a car might map out a road network by driving round. > >> In software you have to imagine yourself the size of a line of a subroutine. >> It will not be possible for you to wander back to any callers of the subroutine >> you are in, because there is no link to take you there. However, you can take >> any links (calls) to lower level subroutines. Therefore structured programming >> is downwardly mappable only. This is a restriction that severely restricts >> required freedom. > > It would be easy to write a program (or subroutine) that identifies all > subroutines that called a specific subroutine. Call this progam "X", and imagine that A, B and C called Q. It is still impossible for Q to know about A, B and C using the information in Q alone. Even though X may know, Q still doesn't, because Q doesn't know about X either. >> Something is mappable if it is possible for a suitably sized observer >> to get to all parts of it, starting from any part. I think this is a >> simple and fairly absolute definition. > > This is always possible if the observer can travel all components and > note all relationships. So this is possible in the brain, in old programming > languages, in my system the observer hasn't got to travel, just read the > relationships (=flow control) > >> It is incredible that many things in the world are mappable but that >> conventional programming languages are not! In other words, structured >> programming is not only unmappable, it is also not based on reality. > > This depends on your view of reality (don't get mad) If you're a programmer > a large part of your reality may well be structured programming. How sad for them.