On Tue, Feb 10, 2015 at 6:57 PM, Mike Archbold via AGI <[email protected]> wrote: > My point was just that code and data is usually the way most people > look at problems. You've got your program and your input/output data. > But, looking at thought, true we can think of a procedure, for > example, but it is not always easy to think of the procedure in some > kind of perfect abstraction from its "data"... eg., how to do laundry > as a procedure WHILE NOT thinking of any time you did the laundry, a > particular. Try it. Just think of doing the laundry with no > instance of laundry (ie., "data").
That is what I am saying. It is difficult to think of 'doing laundry,' without some instance of 'laundry'. The distinctions between 'code' and 'data' are something that you are adding on. They are both 'instances'. The difference between an action and the static data is a distinction that you are aware of. For instance, is the laundry tumbling in a front loader really just an 'object' or just a 'procedure'? Jim Bromer On Tue, Feb 10, 2015 at 6:57 PM, Mike Archbold via AGI <[email protected]> wrote: > Well, I should have said difficult for most people to not think code > vs. data, not everybody, I guess... > > My point was just that code and data is usually the way most people > look at problems. You've got your program and your input/output data. > But, looking at thought, true we can think of a procedure, for > example, but it is not always easy to think of the procedure in some > kind of perfect abstraction from its "data"... eg., how to do laundry > as a procedure WHILE NOT thinking of any time you did the laundry, a > particular. Try it. Just think of doing the laundry with no > instance of laundry (ie., "data"). Looking around physical reality, > there is no procedural code at all. I mean, you've just got eg., a > laundry machine and a pile of clothing. > > So, I was trying to point out to Jim that it seemed to me that he was > thinking in code vs. data terms. That is fine if it works, but I'm > just pointing it out. These are my opinions. I've programmed in Lisp > but not for 20 year or so, prolog more recently. > > Mike > > > > On 2/10/15, Samantha Atkins via AGI <[email protected]> wrote: >> >> On 1/30/15 2:44 PM, Jim Bromer via AGI wrote: >>> On Thu, Jan 29, 2015 at 7:08 PM, Mike Archbold <[email protected]> >>> wrote: >>>> I kind of see what you are talking about here, but admittedly I'm a >>>> bit lost. I think one of the points you make is that an computer >>>> instruction could be as general as a language word. To some extent >>>> that is a theme in object-oriented program, with class inheritance. >>>> >>>> The point I was trying to make was only that the code and data >>>> dichotomy is not supported in reality. I mean look around you. Where >>>> is the code? Where is the data? OO programming comes to mind as an >>>> attempt to unify. But it is still difficult for anybody who has ever >>>> written a line of code to think in terms not consistent with the code >>>> vs. data model. >>>> >>>> Mike >> >> No, it is not. This piece of data happens to be a function. This one >> happens to be a homogenous list of int. It is really quite easy. The >> first can execute instructions of some type in some runtime environment >> and may act on other data of various types. So? >> >> I am a Lisper. I am not bound by some syntax forcing me to think a >> limited number of ways. Lisp is not ambiguous. >> >> A function can be generic, dispatching to a specific function on one or >> more of its parameters. Classic OO only dispatches on the first >> parameter. Multimethods can use all of them. >> >> - samantha >>> It is difficult for a programmer not to think about the distinctions >>> of code vs data. Even when the methods are combined in a way that >>> hides those distinctions he can find them. OOPs, for example, hides >>> the fundamentals but it does not eliminate the need for some >>> programmer to design the program using data types and functions (or >>> procedures) and so on. Now if I tried to use the method I described >>> the 'programming keywords' might hide the distinctions but in order >>> for the computer to process them appropriately it has to 'interpret' >>> them as code and data. I think that is sort of what you are getting >>> at. So really, even though the programming method I described would be >>> quite different than an OOP, an experienced programmer could keep the >>> level of the distinctions (between the instruction and data) in mind >>> in order to use the programming method. I think that is what Mike is >>> getting at. >>> >>> And that is interesting. In order to make my point hold against Mike's >>> criticism the language would have to be ambiguous. So it would almost >>> be a Tintner unprogrammed programming language. Or in more historic >>> terms it would be a non-deterministic programming language. Any >>> programming language could be designed to be ambiguous but only an AGI >>> program could learn to disambiguate the language (at least) somewhat >>> effectively. >>> >>> While the instruction-data grammatical word programming language like >>> the one that I started to describe could be designed to be a discreet and >>> consistently deterministic programming language (like most >>> contemporary programming languages), in order to avoid (my >>> interpretation of) Mike's criticisms the programming language would have >>> to be designed so that it was not completely deterministic. >>> >>> So thanks for helping me recognize this. >>> >>> Jim Bromer >>> >>> >>> On Fri, Jan 30, 2015 at 5:41 PM, Jim Bromer <[email protected]> wrote: >>>> It is difficult for a programmer not to think about the distinctions >>>> of code vs data. Even when the methods are combined in a way that >>>> hides those distinctions he can find them. OOPs, for example, hides >>>> the fundamentals but it does not eliminate the need for some >>>> programmer to design the program using data types and functions (or >>>> procedures) and so on. Now if I tried to use the method I described >>>> the 'programming keywords' might hide the distinctions but in order >>>> for the computer to process them appropriately it has to 'interpret' >>>> them as code and data. I think that is sort of what you are getting >>>> at. So really, even though the programming method I described would be >>>> quite different than an OOP, an experienced programmer could keep the >>>> level of the distinctions (between the instruction and data) in mind >>>> in order to use the programming method. I think that is what you are >>>> getting at. >>>> >>>> And that is interesting. In order to make my point hold against your >>>> criticism the language would have to be ambiguous. So it would almost >>>> be a Tintner unprogrammed programming language. Or in more historic >>>> terms it would be a non-deterministic programming language. Any >>>> programming language could be designed to be ambiguous but only an AGI >>>> program could learn to disambiguate the language effectively. >>>> >>>> While the instruction-data grammatical word programming language like >>>> the one that I started to describe could be a discreet and >>>> consistently deterministic programming language (like most >>>> contemporary programming languages), in order to avoid (my >>>> interpretation of) your criticisms the programming language would have >>>> to be designed so that it was not completely deterministic. >>>> >>>> So thanks for helping me recognize this. >>>> Jim Bromer >>>> >>>> >>>> On Thu, Jan 29, 2015 at 7:08 PM, Mike Archbold <[email protected]> >>>> wrote: >>>>> I kind of see what you are talking about here, but admittedly I'm a >>>>> bit lost. I think one of the points you make is that an computer >>>>> instruction could be as general as a language word. To some extent >>>>> that is a theme in object-oriented program, with class inheritance. >>>>> >>>>> The point I was trying to make was only that the code and data >>>>> dichotomy is not supported in reality. I mean look around you. Where >>>>> is the code? Where is the data? OO programming comes to mind as an >>>>> attempt to unify. But it is still difficult for anybody who has ever >>>>> written a line of code to think in terms not consistent with the code >>>>> vs. data model. >>>>> >>>>> Mike >>>>> >>>>> On 1/28/15, Jim Bromer <[email protected]> wrote: >>>>>> Mike, >>>>>> I am not really sure what you mean. Of course an AI or AGI program is >>>>>> dealing with some kind of situation and this means that the data >>>>>> representations of the objects and relations of those situations >>>>>> (which will be represented in the IO Data Environment) have to be >>>>>> associated in some way with the program variables and relations. >>>>>> >>>>>> I was just trying to point out that one can conceive of a computer >>>>>> programming language which (I think) has much in common with human >>>>>> language. The words have a potential range of meaning and a potential >>>>>> range of representing processes that might partially describe how that >>>>>> meaning can be combined and organized with other meaningful words. I >>>>>> think this is more evidence that the processes of mind -natural or >>>>>> artificial- should be seen as a kind of conceptual relativism. >>>>>> >>>>>> I did say that we typically use IO in a mundane way. Maybe that was >>>>>> wrong for an AGI group. My real point is that for an AGI project we >>>>>> should use or think of IO in a way that would correspond to this >>>>>> conceptual relativism but I don't think programmers fully get it. The >>>>>> relativism is not just something that we are going to end up with but >>>>>> it is something that an AGI program has to deal with from the start. >>>>>> >>>>>> If everything is relative then, perhaps you are asking, do I think >>>>>> that the AGI programming is all about the abstract relations? And if >>>>>> it is then could it all be preprogrammed?? An AGI program has to be >>>>>> preprogrammed but one of the implications of my messages is that the >>>>>> program has to effectively learn to program itself to learn to >>>>>> effectively adapt with new kinds of situations. I am not just saying >>>>>> that everything is relative I am saying that everything is >>>>>> relativistic. That means that stock logic-based solutions are not >>>>>> going to always work and we are going to need to rely on some >>>>>> coherence. Ideas seem to stick together and work effectively. But in >>>>>> order to get a computer program to use this strategy I believe that >>>>>> you cannot just rely on some elementary -form- of derivation. You need >>>>>> to use trial and error methods on new ideas first of all. But even >>>>>> that is not enough. Why not? Because the belief that there is an >>>>>> underlying reality that can be depended on to verify every new idea >>>>>> has never been shown to be reliable and it is not a reasonable belief. >>>>>> I am not making a straw man argument, I am just pointing this out >>>>>> because it is part of my claim that there have to be other ways to >>>>>> verify new ideas. One of the ways is to rely on key conceptual >>>>>> structures, which if true, would seem to explain many things. >>>>>> >>>>>> >>>>>> Jim Bromer >>>>>> >>>>>> >>>>>> On Tue, Jan 27, 2015 at 12:47 AM, Mike Archbold <[email protected]> >>>>>> wrote: >>>>>>> Reading this, I am thinking that reality does not present as "code >>>>>>> and >>>>>>> data," there is always just some integrated something -- thought, >>>>>>> object, >>>>>>> etc. Where does the code stop and the data start in commonsense >>>>>>> reality. >>>>>>> >>>>>>> >>>>>>> On Saturday, January 24, 2015, Jim Bromer via AGI <[email protected]> >>>>>>> wrote: >>>>>>>> I lost track of what I was saying in my first post but I do recall >>>>>>>> the >>>>>>>> more important point that I was coming to. >>>>>>>> Suppose you were designing the central processor code for a very >>>>>>>> simple computer (that you might, for example, use to study >>>>>>>> fundamental >>>>>>>> questions). Could you combine an instruction word for the processor >>>>>>>> with a value parameter (or a parameter that was a reference to a >>>>>>>> value)? Of course you could just make one part of a word the >>>>>>>> instruction code and the other part the value. But could you combine >>>>>>>> them so that it wasn't obvious that one part was an instruction and >>>>>>>> the other part was a value or a reference to a value? You could use >>>>>>>> something that acted like an encryption to make the two >>>>>>>> superficially >>>>>>>> indistinguishable but I started wondering how I might design a >>>>>>>> computer language in which an input word might contain both an >>>>>>>> instruction value and a data value (or reference) and both of them >>>>>>>> would be indistinguishable and yet readable. It took me a while to >>>>>>>> figure that one out. You would need to frame the code to read more >>>>>>>> than one 'instruction' word at a time and then use grammar with it. >>>>>>>> This is an interesting insight. It answers an interesting question, >>>>>>>> I >>>>>>>> think it represents a potential for a somewhat novel programming >>>>>>>> language and it describes something that looks a lot like human >>>>>>>> language. Now, this post might be dismissed by a knowledgeable >>>>>>>> reader >>>>>>>> because computer programs already use grammatical rules to read >>>>>>>> instruction code and we already write code that can refer to the >>>>>>>> "language" of input. But most of our code reads input in pretty >>>>>>>> mundane ways. My thought here is that this represents a thought >>>>>>>> experiment which shows a strong relationship between a fundamental >>>>>>>> computational method and the methods of human language. Most >>>>>>>> computer >>>>>>>> instructions are written in a way to make each instruction simple >>>>>>>> and >>>>>>>> unambiguous. Of course if you just started writing a language that >>>>>>>> acted more like a human language the potential for creating >>>>>>>> ambiguities could be great. But that is just the reason why most >>>>>>>> programmers haven't actually seen a computer language like the one I >>>>>>>> am suggesting might actually be used as a novel programming >>>>>>>> language. >>>>>>>> Although you could write a computer language in which values or >>>>>>>> references to values and instructions could be combined, the more >>>>>>>> reasonable approach would be to use simpler data values and >>>>>>>> instructions. But after you take the step of considering more >>>>>>>> powerful >>>>>>>> data words that also contain or represent hints on how they might be >>>>>>>> used then the next step is to realize that the program should have >>>>>>>> the >>>>>>>> capability to learn new data and instruction words. Again, the >>>>>>>> simplest approach would be to start with a carefully predefined way >>>>>>>> that new instructions could be input. But another way to go would be >>>>>>>> to make the program so that it had the potential to accept new >>>>>>>> instruction strings but make it figure out when it made sense to >>>>>>>> read >>>>>>>> some input as an activation of that potential. This is intended to >>>>>>>> suggest how the fundamental nature of a computer is closely related >>>>>>>> to >>>>>>>> conceptual relativism. >>>>>>>> This computer programming language, an example of which you have >>>>>>>> never >>>>>>>> seen, describes a fundamental relativism like that you might see in >>>>>>>> human language and I think it should make an impression on an >>>>>>>> experienced programmer. >>>>>>>> Jim Bromer >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jan 22, 2015 at 6:59 PM, Jim Bromer <[email protected]> >>>>>>>> wrote: >>>>>>>>> I meant to say: >>>>>>>>> Now the thing is that instruction code is a kind of enumeration (as >>>>>>>>> are most of the referential codes) but the value data may - in many >>>>>>>>> cases - be something more. >>>>>>>>> >>>>>>>>> But I am both right and wrong about that. >>>>>>>>> >>>>>>>>> I wanted to ask the rhetorical question: Can an instruction code be >>>>>>>>> something more than an enumeration just like I said that a value >>>>>>>>> can >>>>>>>>> be? >>>>>>>>> >>>>>>>>> However, after I formed this question I realized that value data >>>>>>>>> can >>>>>>>>> be something more than an enumeration just because it can refer to >>>>>>>>> a >>>>>>>>> dynamic system that can be superimposed on it and that system can >>>>>>>>> be >>>>>>>>> encoded somewhere else in the instructions or in the program. So if >>>>>>>>> the data is typed, for example, then the extra power of the values >>>>>>>>> are >>>>>>>>> due to the algorithms that are used with the that type of data so >>>>>>>>> data >>>>>>>>> can be "something more," as I said, only because it can refer to >>>>>>>>> other >>>>>>>>> dynamic or multiple step instructions. >>>>>>>>> >>>>>>>>> However, with thought those systems may exist in other minds even >>>>>>>>> if >>>>>>>>> they are not explicitly described in a particular mind. So I can >>>>>>>>> say >>>>>>>>> something about the compressor in a jet engine with a jet >>>>>>>>> propulsion >>>>>>>>> engineer even though I don't know most of the details about a jet >>>>>>>>> engine or about the compressors of jet engines. >>>>>>>>> >>>>>>>>> So in one sense I was wrong. The value data is not something more >>>>>>>>> glorious than an enumeration. Technically I was right. The fact >>>>>>>>> that >>>>>>>>> certain data can be used in special ways does not mean that it is >>>>>>>>> just >>>>>>>>> an enumeration. And I am still right in the spirit of the idea, >>>>>>>>> that >>>>>>>>> some static data can implicitly refer to a set of instructions on >>>>>>>>> how >>>>>>>>> to use it. >>>>>>>>> >>>>>>>>> So then value data can also refer to more than one set of >>>>>>>>> instructions. >>>>>>>>> Jim Bromer >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jan 22, 2015 at 6:29 PM, Jim Bromer <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> Look at the code for a computer program. Certain values represent >>>>>>>>>> instructions and others represent data and others represent >>>>>>>>>> various >>>>>>>>>> references to data. Suppose you had a computer that was nearly as >>>>>>>>>> primitive as a Turing Machine. Could you convert all the program >>>>>>>>>> so >>>>>>>>>> that the static data were all replaced by instruction values and >>>>>>>>>> the >>>>>>>>>> programming instructions were replaced by value and reference data. >>>>>>>>>> I >>>>>>>>>> mean could this be virtually accomplished with something like a >>>>>>>>>> universal turing machine so none of the original data was >>>>>>>>>> preserved >>>>>>>>>> in >>>>>>>>>> its original forms? Is there a way to make the instruction code do >>>>>>>>>> the >>>>>>>>>> stuff that the parameters do and a way to make the parameters do >>>>>>>>>> the >>>>>>>>>> stuff the instructions do - for that program? >>>>>>>>>> >>>>>>>>>> The point is that the distinction between instruction code and >>>>>>>>>> parameter code is not set in stone. Now the thing is that >>>>>>>>>> instruction >>>>>>>>>> code is a kind of enumeration (as are most of the references) but >>>>>>>>>> the >>>>>>>>>> value code in the instruction data may - in many cases - be >>>>>>>>>> something >>>>>>>>>> more. >>>>>>>>>> >>>>>>>>>> Is this off topic? >>>>>>>>>> >>>>>>>>>> Jim Bromer >>>>>>>> >>>>>>>> ------------------------------------------- >>>>>>>> AGI >>>>>>>> Archives: https://www.listbox.com/member/archive/303/=now >>>>>>>> RSS Feed: >>>>>>>> https://www.listbox.com/member/archive/rss/303/11943661-d9279dae >>>>>>>> Modify Your Subscription: >>>>>>>> https://www.listbox.com/member/?&; >>>>>>>> Powered by Listbox: http://www.listbox.com >>> >>> ------------------------------------------- >>> AGI >>> Archives: https://www.listbox.com/member/archive/303/=now >>> RSS Feed: https://www.listbox.com/member/archive/rss/303/2997756-fc0b9b09 >>> Modify Your Subscription: https://www.listbox.com/member/?&; >>> Powered by Listbox: http://www.listbox.com >> >> >> >> ------------------------------------------- >> AGI >> Archives: https://www.listbox.com/member/archive/303/=now >> RSS Feed: https://www.listbox.com/member/archive/rss/303/11943661-d9279dae >> Modify Your Subscription: >> https://www.listbox.com/member/?&; >> Powered by Listbox: http://www.listbox.com >> > > > ------------------------------------------- > AGI > Archives: https://www.listbox.com/member/archive/303/=now > RSS Feed: https://www.listbox.com/member/archive/rss/303/24379807-653794b5 > Modify Your Subscription: https://www.listbox.com/member/?&; > Powered by Listbox: http://www.listbox.com ------------------------------------------- AGI Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-f452e424 Modify Your Subscription: https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-58d57657 Powered by Listbox: http://www.listbox.com
