Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #57042 > unrolled thread

6502 anyone ?

Back to article view | Back to comp.lang.forth

Contents

  6502 anyone ? john <anon@example.com> - 2017-04-11 13:07 +0100
    Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-11 23:31 -0400
      Re: 6502 anyone ? Mark Wills <markwills1970@gmail.com> - 2017-04-12 01:27 -0700
        Re: 6502 anyone ? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-12 10:46 +0200
          Re: 6502 anyone ? Mark Wills <markwills1970@gmail.com> - 2017-04-12 01:57 -0700
            Re: 6502 anyone ? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-12 12:24 +0200
            Re: 6502 anyone ? hughaguilar96@gmail.com - 2017-04-12 14:37 -0700
              Re: 6502 anyone ? lehs <skydda.barnen@gmail.com> - 2017-04-12 17:16 -0700
                Re: 6502 anyone ? hughaguilar96@gmail.com - 2017-04-12 18:10 -0700
                  Re: 6502 anyone ? lehs <skydda.barnen@gmail.com> - 2017-04-12 23:46 -0700
                    Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-13 03:00 -0400
                      Re: 6502 anyone ? lehs <skydda.barnen@gmail.com> - 2017-04-13 00:37 -0700
                        Re: 6502 anyone ? lehs <skydda.barnen@gmail.com> - 2017-04-13 00:42 -0700
                          Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-13 12:57 -0400
                            Re: 6502 anyone ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-13 12:01 -0500
                              Re: 6502 anyone ? lehs <skydda.barnen@gmail.com> - 2017-04-13 10:42 -0700
                                Re: 6502 anyone ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-13 12:55 -0500
                                  Re: 6502 anyone ? lehs <skydda.barnen@gmail.com> - 2017-04-13 11:13 -0700
                                    Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-13 14:24 -0400
                                      Re: 6502 anyone ? lehs <skydda.barnen@gmail.com> - 2017-04-13 11:57 -0700
                                        Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-13 15:15 -0400
                                Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-13 14:23 -0400
          Re: 6502 anyone ? john <anon@example.com> - 2017-04-12 10:25 +0100
          Re: 6502 anyone ? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-12 12:27 +0200
            Re: 6502 anyone ? Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-12 12:53 +0200
              Re: 6502 anyone ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-12 12:55 +0000
                Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-12 12:20 -0400
            Re: 6502 anyone ? Mark Wills <markwills1970@gmail.com> - 2017-04-12 05:10 -0700
              Re: 6502 anyone ? Michael Barry <barrym95838@yahoo.com> - 2017-04-12 22:41 -0700
            Re: 6502 anyone ? Joel Rees <joel.rees@gmail.com> - 2017-04-13 02:14 -0700
              Re: 6502 anyone ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-13 11:01 +0000
                Re: 6502 anyone ? jim.brakefield@ieee.org - 2017-04-13 06:33 -0700
                  Re: 6502 anyone ? Mark Wills <markwills1970@gmail.com> - 2017-04-13 07:24 -0700
                    Re: 6502 anyone ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-13 09:51 -0500
                      Re: 6502 anyone ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-13 17:16 +0000
                        Re: 6502 anyone ? hughaguilar96@gmail.com - 2017-04-13 13:08 -0700
                Re: 6502 anyone ? Joel Rees <joel.rees@gmail.com> - 2017-04-14 08:06 -0700
              Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-13 13:00 -0400
        Re: 6502 anyone ? "HAA" <someone@microsoft.com> - 2017-04-13 10:42 +1000
          Re: 6502 anyone ? hughaguilar96@gmail.com - 2017-04-12 18:45 -0700
            Re: 6502 anyone ? "HAA" <someone@microsoft.com> - 2017-04-14 13:01 +1000
              Re: 6502 anyone ? rickman <gnuarm@gmail.com> - 2017-04-14 01:21 -0400
              Re: 6502 anyone ? hughaguilar96@gmail.com - 2017-04-13 23:23 -0700
      Re: 6502 anyone ? john <anon@example.com> - 2017-04-12 10:08 +0100

Page 1 of 3  [1] 2 3  Next page →

#57042 — 6502 anyone ?

Whilst poking around to shortcut my hardware development problems
I came across the following links.

Since I suspect most of use here are a bunch
of old fogeys I thought they might be of interest,

http://apple2.x10.mx/CHOCHI/
http://hackaday.com/2014/08/16/an-fpga-based-6502-computer/

So far I've seen one that claims to go up to 200Mhz.
Something a bit different anyway.

-- 

john

=========================
http://johntech.co.uk

"Bleeding Edge Forum"
http://johntech.co.uk/forum/ 

=========================

[toc] | [next] | [standalone]

#57091

On 4/11/2017 8:07 AM, john wrote:
>
> Whilst poking around to shortcut my hardware development problems
> I came across the following links.
>
> Since I suspect most of use here are a bunch
> of old fogeys I thought they might be of interest,
>
> http://apple2.x10.mx/CHOCHI/
> http://hackaday.com/2014/08/16/an-fpga-based-6502-computer/
>
> So far I've seen one that claims to go up to 200Mhz.
> Something a bit different anyway.

FPGA designs for old CPUs are a dime a dozen.  You can find everything 
from a PDP-11 to an 1802 to an IBM360 for FPGAs.  Nearly all of them run 
way faster than the original.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#57122

On Wednesday, 12 April 2017 04:31:30 UTC+1, rickman  wrote:
> On 4/11/2017 8:07 AM, john wrote:
> >
> > Whilst poking around to shortcut my hardware development problems
> > I came across the following links.
> >
> > Since I suspect most of use here are a bunch
> > of old fogeys I thought they might be of interest,
> >
> > http://apple2.x10.mx/CHOCHI/
> > http://hackaday.com/2014/08/16/an-fpga-based-6502-computer/
> >
> > So far I've seen one that claims to go up to 200Mhz.
> > Something a bit different anyway.
> 
> FPGA designs for old CPUs are a dime a dozen.  You can find everything 
> from a PDP-11 to an 1802 to an IBM360 for FPGAs.  Nearly all of them run 
> way faster than the original.
> 
> -- 
> 
> Rick C

Also, the 6502, whilst a very simple device and quite fast, has a 
crap instruction set and no registers.

Yack. Just yack.

Thanks for reminding me of writing assembly (in hex) on my Commodore 64
and Atari 800XL computers. I would have been better off being outside
with my friends trying to get my hands up girls' bras. As it happens,
that came a little later :-)

[toc] | [prev] | [next] | [standalone]

#57126

Mark Wills wrote:
> Also, the 6502, whilst a very simple device and quite fast, has a 
> crap instruction set and no registers.

I haven't done any serious 6502 programming, so I wouldn't know.
Certainly, handling anything beyond 8 bits is going to be awkward, since
it's very insistent on being an 8-bitter.

But at least the instruction set *encoding* is quite regular and
pleasant.  I wrote my own Forth assembler for it, and it turned out to
be very simple.

[toc] | [prev] | [next] | [standalone]

#57129

On Wednesday, 12 April 2017 09:46:15 UTC+1, Lars Brinkhoff  wrote:
> Mark Wills wrote:
> > Also, the 6502, whilst a very simple device and quite fast, has a 
> > crap instruction set and no registers.
> 
> I haven't done any serious 6502 programming, so I wouldn't know.
> Certainly, handling anything beyond 8 bits is going to be awkward, since
> it's very insistent on being an 8-bitter.
> 
> But at least the instruction set *encoding* is quite regular and
> pleasant.  I wrote my own Forth assembler for it, and it turned out to
> be very simple.

I found the Z80 *much* nicer to code for, because it had proper 16 bit
instructions, BC, DE, HL registers etc, and some nice macro instructions
(LDIR etc.)

However, I never looked back once I got to work on the 68K and the 9900's.
The TMS9900 family has my all time favourite instruction set, followed
by the 68K family. I've looked at x86 but that too looks vile so I always
stayed away from it. I'll just use Forth or something else instead!

[toc] | [prev] | [next] | [standalone]

#57139

Mark Wills wrote:
> The TMS9900 family has my all time favourite instruction set, followed
> by the 68K family. I've looked at x86 but that too looks vile so I
> always stayed away from it.

I was almost born and raised with the 68000.  The x86 instruction set
looks obnoxious and the encoding is even worse!  However, my assemblers
for those two turned out to be almost the same in size, which felt like
a dissapointment.

Of course, "size of assembler written by random dude" isn't a good
metric for instruction set complexity.

[toc] | [prev] | [next] | [standalone]

#57180

On Wednesday, April 12, 2017 at 1:57:21 AM UTC-7, Mark Wills wrote:
> On Wednesday, 12 April 2017 09:46:15 UTC+1, Lars Brinkhoff  wrote:
> > Mark Wills wrote:
> > > Also, the 6502, whilst a very simple device and quite fast, has a 
> > > crap instruction set and no registers.
> > 
> > I haven't done any serious 6502 programming, so I wouldn't know.
> > Certainly, handling anything beyond 8 bits is going to be awkward, since
> > it's very insistent on being an 8-bitter.
> > 
> > But at least the instruction set *encoding* is quite regular and
> > pleasant.  I wrote my own Forth assembler for it, and it turned out to
> > be very simple.
> 
> I found the Z80 *much* nicer to code for, because it had proper 16 bit
> instructions, BC, DE, HL registers etc, and some nice macro instructions
> (LDIR etc.)

I thought the 65c02 was great! It had a very powerful well-designed instruction set. A 1 Mhz. 6502 was comparable in speed to a 2 Mhz. Z80, and the 65c02 used in the Apple-IIc was 3.6 Mhz --- the 65c02 was available up to 8 Mhz..

The major problem with the 65c02 was that the JMP indirect instruction used the X register. It should have used the Y register because X was already being used as the Forth data-stack pointer. If I could build a time-machine and go back to the 1970s, I would fix this flaw in the 65c02, as well as the problem of being limited to 64KB --- a 65c02 with 128KB of memory (64KB for code and data each) with the JMP indirect flaw fixed would be great --- this would really change the course of history, as the 65c02 computers would out-perform MS-DOS so well as to kill MS-DOS before it lumbered out of the gate.

Anyway, the best Forth system available was ISYS Forth for the Apple-IIc --- this was STC and did code-optimization. It had a lot of support for floating-point. I wrote a cross-compiler in 16-bit UR/Forth that allowed me to develop Forth code on an MS-DOS machine and cross-compile into the Apple-IIc. I used this to write a program that did symbolic math. I got all the way through being able to do derivatives, and simplifying the equations down fully. I was able to display math equations with Greek characters and various math symbols. I didn't do integrals though because I was already at the limit of what the Apple-IIc was capable of (integrals are pretty difficult to program; I would be hard-pressed to do that even today).

I also programmed the 6809 in assembly-language on the Radio Shack Color Computer. I never got into Z80, although I have studied it --- I wasn't impressed with its design --- it has major design flaws!

[toc] | [prev] | [next] | [standalone]

#57194

How did you do the simplifications? How was it organized?

[toc] | [prev] | [next] | [standalone]

#57201

On Wednesday, April 12, 2017 at 5:16:38 PM UTC-7, lehs wrote:
> How did you do the simplifications? How was it organized?

Um, it has been over 25 years, so my memory on how it was organized is foggy. IIRC, I had these kinds of nodes:
1.) dinary operator (such as + etc.) and two pointers to other nodes which were the parameters.
2.) unary operator (such as LN etc.) and one pointer to another node which was the parameter.
3.) symbol 
4.) number 

ISYS didn't have a heap. IIRC, I wrote this in a simple manner. I had two heaps, both of which just did an ALLOCATE by appending onto the pile of existing nodes. I would build the equation in one heap, then I would process the equation and move the new nodes to the other heap which was empty. Then I would empty the heap I had been working from. So, my equation just went back and forth between the two heaps. Each time I processed the equation, it would get smaller or stay the same size, so I only needed to make sure the initial heap was large enough to hold the derivative and then there was no danger of overflow. There was no FREE for freeing individual nodes --- I was only able to empty the entire heap of all nodes.

Processing the equation was pretty simple. I would just do a pass over the equation looking for a particular pattern. Every time that I found the pattern, I would modify the equation. Sometimes I had to do a modification and then try again with patterns I had already tried. For example:

+
   5
   +
      x
      6

I do the pass that looks for constants added to each other, but I don't find anything. Then I do a pass that rearranges same operators, so I get this:

+
   x
   +
      5 
      6
Then I try again looking for constants added to each other, and I find this pattern. So I get this:
+
   x
   11

When I did all my pattern tests and found nothing, and I had already tried every permutation of modifications, I knew that I was done. This seems inefficient, but it worked reasonably well. On my Laser-128 that had a 3.6 Mhz. 65c02, pretty big and complicated equations could get converted into a derivative and get fully simplified in no more than 15 seconds (IIRC). The Apple-IIc had a 2 Mhz. 65c02, but I didn't own that because it was too expensive.

Getting the derivatives was pretty easy. There are only a few rules. This produced bloated equations though. A lot of the simplifications are done by a person without even thinking of them as simplifications, because they are so obvious. My program just did a dumb application of the rules though, so the resulting equation was quite bloated and didn't look like anything that a person would write. After it was simplified though, it looked the same as what a person would write.

It wasn't a useful program. With a little bit of practice, a person using pencil-and-paper could beat it in speed. Also, integrals are much more difficult for a program --- but with a little bit of practice a person can do those pretty fast with pencil-and-paper --- a program that can do this would be considered AI though (really beyond what could be accomplished with an Apple-IIc).

The Apple IIc had 128KB of memory. I used one 48KB bank for the part of the program that processed equations (this took a lot of memory because of the two heaps). I used the other 48KB bank for the part of the program that displayed equations on the screen (this took a lot of memory because I had my own character set with Greek letters and math symbols, and I used the high-res graphics screen rather than the character screen for the display). I had a 16KB common area at the top that contained all the Forth primitives and other code that was used by both sub-programs.

[toc] | [prev] | [next] | [standalone]

#57214

Den torsdag 13 april 2017 kl. 03:10:01 UTC+2 skrev hughag...@gmail.com:
> On Wednesday, April 12, 2017 at 5:16:38 PM UTC-7, lehs wrote:
> > How did you do the simplifications? How was it organized?
> 
> Um, it has been over 25 years, so my memory on how it was organized is foggy. IIRC, I had these kinds of nodes:
> 1.) dinary operator (such as + etc.) and two pointers to other nodes which were the parameters.
> 2.) unary operator (such as LN etc.) and one pointer to another node which was the parameter.
> 3.) symbol 
> 4.) number 
> 
> ISYS didn't have a heap. IIRC, I wrote this in a simple manner. I had two heaps, both of which just did an ALLOCATE by appending onto the pile of existing nodes. I would build the equation in one heap, then I would process the equation and move the new nodes to the other heap which was empty. Then I would empty the heap I had been working from. So, my equation just went back and forth between the two heaps. Each time I processed the equation, it would get smaller or stay the same size, so I only needed to make sure the initial heap was large enough to hold the derivative and then there was no danger of overflow. There was no FREE for freeing individual nodes --- I was only able to empty the entire heap of all nodes.
> 
> Processing the equation was pretty simple. I would just do a pass over the equation looking for a particular pattern. Every time that I found the pattern, I would modify the equation. Sometimes I had to do a modification and then try again with patterns I had already tried. For example:
> 
> +
>    5
>    +
>       x
>       6
> 
> I do the pass that looks for constants added to each other, but I don't find anything. Then I do a pass that rearranges same operators, so I get this:
> 
> +
>    x
>    +
>       5 
>       6
> Then I try again looking for constants added to each other, and I find this pattern. So I get this:
> +
>    x
>    11
> 
> When I did all my pattern tests and found nothing, and I had already tried every permutation of modifications, I knew that I was done. This seems inefficient, but it worked reasonably well. On my Laser-128 that had a 3.6 Mhz. 65c02, pretty big and complicated equations could get converted into a derivative and get fully simplified in no more than 15 seconds (IIRC). The Apple-IIc had a 2 Mhz. 65c02, but I didn't own that because it was too expensive.
> 
> Getting the derivatives was pretty easy. There are only a few rules. This produced bloated equations though. A lot of the simplifications are done by a person without even thinking of them as simplifications, because they are so obvious. My program just did a dumb application of the rules though, so the resulting equation was quite bloated and didn't look like anything that a person would write. After it was simplified though, it looked the same as what a person would write.
> 
> It wasn't a useful program. With a little bit of practice, a person using pencil-and-paper could beat it in speed. Also, integrals are much more difficult for a program --- but with a little bit of practice a person can do those pretty fast with pencil-and-paper --- a program that can do this would be considered AI though (really beyond what could be accomplished with an Apple-IIc).
> 
> The Apple IIc had 128KB of memory. I used one 48KB bank for the part of the program that processed equations (this took a lot of memory because of the two heaps). I used the other 48KB bank for the part of the program that displayed equations on the screen (this took a lot of memory because I had my own character set with Greek letters and math symbols, and I used the high-res graphics screen rather than the character screen for the display). I had a 16KB common area at the top that contained all the Forth primitives and other code that was used by both sub-programs.

Artificial Intelligence is just like this - smart programming to extend the limits of what is possible for a computer to do. Some people believe that computers or their programs sometime in the future are going to become alive, think and experience as humans. But since a computer program never can experience to be a human being it will never be able to experience human reality and make use of human language the way humans (is forced to) do.

Lars-Erik Svahn
https://forthmath.blogspot.se
https://github.com/Lehs/ANS-Forth-libraries

[toc] | [prev] | [next] | [standalone]

#57216

On 4/13/2017 2:46 AM, lehs wrote:
>
> Artificial Intelligence is just like this - smart programming to
> extend the limits of what is possible for a computer to do. Some
> people believe that computers or their programs sometime in the
> future are going to become alive, think and experience as humans. But
> since a computer program never can experience to be a human being it
> will never be able to experience human reality and make use of human
> language the way humans (is forced to) do.

What part of existence is unique to humans?  If you mean a machine will 
never be perfectly like a human, that may be true in the say way all 
animals have different existences.  A dog can't experience existence 
like a bird can.  But that doesn't mean both aren't alive, thinking and 
experiencing life.

In the same way a machine can in theory become self aware and have an 
intelligence that experiences its own existence.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#57218

Not in theory, but in the imagination. 

I restrict to the situation with classical computers and human beings, because else the question is totally mind blowing. Human beings are very different from each other but we have in common that we are born under human circumstances and is shaped by those. Our relation to human language is shaped by our situation and we recognice thousands of words, billions of formulations of situations in trivial reality such as fashion, friendship, threats, duties, mobbing, happiness, plannings, drugs... Our relation to those and more important things is reflected in human language. A computer speaking human language is a fake, formulating sentences created by humans about a context experienced by humans. 

Chess is one form of human communication. The players communicate by moving pieces on a board according to a few strict rules. Nowadays the best programs can beat the best human players, but doing it by searching possible states far beyond what humans are able to. Yet, the number of states are much larger than the number of particles in universe. Imaging programs trying to overview all human situations by engage multiple cpu-operations. As far as I know, there are no other AI programming technics than those who result in this ALU-operations. And sinceince p

[toc] | [prev] | [next] | [standalone]

#57219

Cont.  
Since computer programs can't experience growing up as humans there is no way for it to have all this knowledge. And the ALU will never be aware of it self.

[toc] | [prev] | [next] | [standalone]

#57239

On 4/13/2017 3:42 AM, lehs wrote:
> Cont.
> Since computer programs can't experience growing up as humans there is no way for it to have all this knowledge. And the ALU will never be aware of it self.

Nothing you have said precludes a machine becoming self aware.  In 
particular the above statement is false.  Computers can and *do* learn. 
There have been a number of computer programs that learn from experience.

http://bfy.tw/BDB2

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#57241

rickman <gnuarm@gmail.com> wrote:
> On 4/13/2017 3:42 AM, lehs wrote:
>> Cont.
>> Since computer programs can't experience growing up as humans there is no way for it to have all this knowledge. And the ALU will never be aware of it self.
> 
> Nothing you have said precludes a machine becoming self aware.  In 
> particular the above statement is false.  Computers can and *do* learn. 
> There have been a number of computer programs that learn from experience.
> 
> http://bfy.tw/BDB2

:-)

I'm surprised that anybody can repeat the computers only do what
they're told and can't invent anything", given the recent work at
DeepMind with AlphaGo.  This really wasn't a brute-force tree search
of the kind used by chess porgrams.

Andrew.

[toc] | [prev] | [next] | [standalone]

#57246

Den torsdag 13 april 2017 kl. 19:02:01 UTC+2 skrev Andrew Haley:
> rickman <gnuarm@gmail.com> wrote:
> > On 4/13/2017 3:42 AM, lehs wrote:
> >> Cont.
> >> Since computer programs can't experience growing up as humans there is no way for it to have all this knowledge. And the ALU will never be aware of it self.
> > 
> > Nothing you have said precludes a machine becoming self aware.  In 
> > particular the above statement is false.  Computers can and *do* learn. 
> > There have been a number of computer programs that learn from experience.
> > 
> > http://bfy.tw/BDB2
> 
> :-)
> 
> I'm surprised that anybody can repeat the computers only do what
> they're told and can't invent anything", given the recent work at
> DeepMind with AlphaGo.  This really wasn't a brute-force tree search
> of the kind used by chess porgrams.
> 
> Andrew.

That's a straw-man. I agree with that computers could learn, of course. But they can never experience to be humans or express human thoughts as a result of a mind.

I don't know what AI is, but AI programming is technique.

[toc] | [prev] | [next] | [standalone]

#57247

lehs <skydda.barnen@gmail.com> wrote:
> 
> That's a straw-man.

It's your straw man, if so.  You made the foolish "chess computer"
argument.

> I agree with that computers could learn, of course. But they can
> never experience to be humans or express human thoughts as a result
> of a mind.

Of course not, because humans are by definition us, the species that
evolved, made out of meat.  But that tells us nothing about whether
machgines not made out of meat can have thoughts or minds.

Andrew.

[toc] | [prev] | [next] | [standalone]

#57248

Den torsdag 13 april 2017 kl. 19:56:00 UTC+2 skrev Andrew Haley:
> lehs <skydda.barnen@gmail.com> wrote:
> > 
> > That's a straw-man.
> 
> It's your straw man, if so.  You made the foolish "chess computer"
> argument.
> 
> > I agree with that computers could learn, of course. But they can
> > never experience to be humans or express human thoughts as a result
> > of a mind.
> 
> Of course not, because humans are by definition us, the species that
> evolved, made out of meat.  But that tells us nothing about whether
> machgines not made out of meat can have thoughts or minds.
> 
> Andrew.

Mind has nothing to do with AI programming, unlike chess programming.

[toc] | [prev] | [next] | [standalone]

#57250

On 4/13/2017 2:13 PM, lehs wrote:
> Den torsdag 13 april 2017 kl. 19:56:00 UTC+2 skrev Andrew Haley:
>> lehs <skydda.barnen@gmail.com> wrote:
>>>
>>> That's a straw-man.
>>
>> It's your straw man, if so.  You made the foolish "chess computer"
>> argument.
>>
>>> I agree with that computers could learn, of course. But they can
>>> never experience to be humans or express human thoughts as a result
>>> of a mind.
>>
>> Of course not, because humans are by definition us, the species that
>> evolved, made out of meat.  But that tells us nothing about whether
>> machgines not made out of meat can have thoughts or minds.
>>
>> Andrew.
>
> Mind has nothing to do with AI programming, unlike chess programming.

If a mind is different from a program, what is it?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#57251

I was discussing programming and wrote that AI-programming is a technique. It's not alchemistry or something, just smart technique build upon scientific results - often with astounding results. There is no computer science dealing with the mind. 

What is mind? I ask you what is space? Time? What is anything? You can't answer such questions with descriptions of models. Models are models.

Human thinking and language is about human living. You can't expect a robot experience waking up with the hed in an ashtray after been intoxicated with alcoholic the night before. Of course robots will communicate, and already does, and of course they will be able to communicate with humans in human language. But that communication would be a kind of interface communication thru some kind of protocoll.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web